One of the most interesting aspects of being a consultant is that I get exposed to any number of different facets of system design in the course of an assignment. While I tend to focus more on application and integration work, I find it fascinating to deal with the concepts of services in the context of infrastructure.

In the past, I've been called upon to design Service-Oriented Infrastructures (SOI) - the hardware and platform software, along with customizations for the needs of the actual deployment environment - instead of creating an application architecture. SOI is really a different way of looking at the concept of services - from the viewpoint of the operational staff.

Most of the time, we tend to view services from a line of business or at the very least an application development perspective. There's nothing wrong with viewing SOA this way - it's very important to break down the artificial walls created by applications into discrete services, and it provides great flexibility to the line of business, allowing for swift creation of composite applications. In SOA World Magazine, we give a great deal of attention to these questions.

We also look at the concept of "support services" on a fairly regular basis. Even when a business doesn't have a great deal of redundant applications, you can be fairly certain that the set of "support services" available will still be significant. These can be things such as security, auditing, logging as well as business intelligence and business activity monitoring that transcend a single application and become common services in support of line of business operations.

These support services quickly become ubiquitous, and we find that in reality, although they do not support direct business activity (i.e., they are not front-of-the-house operational services that directly produce revenue), they are in many ways just as important, if only from a risk avoidance and mitigation standpoint. Fail to have this house in order and you can be in a world of pain during an audit.

Infrastructure is what's on my mind this month, as far as services go. We're looking at SOA testing and the concepts of grid computing as they relate to SOA in this issue. And that got me thinking. Testing itself can be considered a service, at least for organizations that treat it with respect and rigor. The wealth of information that testing provides can be set up as a service to corporate dashboards and reporting systems that monitor the efficiency and effectiveness of a large IT organization. Obviously, this is mainly for large IT shops, but we can see that the principles of service orientation can be applied even to areas that are seen as supporting processes, not just to main-line business processes.

Grid computing, with the ability to bring capacity on line and to bear on a problem as needed provides another stunning opportunity to move from traditional means of operation to a service platform. Bringing CPUs to bear on a problem in a dynamic fashion, assigning additional network capacity to deal with peak loads, and allocating private connections on the fly in response to security needs are just a few of the capabilities that infrastructure vendors are building into their hardware and operating software.

Even more interesting is the concept of virtualization applied to a farm of CPUs and storage devices. Imagine a world where there are no discrete servers at all - instead, you ask for and receive a server image, complete with virtualized storage. Environments can be switched on the fly, so you no longer need three or more testing environments in order to do all your development and testing. Or even a world where you can lease out your excess capacity dynamically and recover it according to a set of SLAs that are also managed and monitored by the same management software that watches your SOA line of business services. It's here already, waiting for you to use it. Welcome to SOI..