It's sometimes funny to write about service-oriented architecture. One of the things I say often and believe is that you can't buy a service-oriented architecture. SOA is not just technology, it's philosophy, organizational change, and business transformation. There's no place to buy that kind of dramatic, deeply impacting change.

The funny part, at least to me, is that you can, however, buy or acquire a good deal of infrastructure to set this up from a single source. In the industry, we call that a platform. And that's what this month's issue is about - SOA platforms.

Service-oriented architecture is a powerful concept - at its base, it replaces the concept of an application with the concept of a service. This isn't trivial. For 40 or more years, we've dealt with computers in the context of applications (I've left a few years off my count to account for the years before operating systems when we were really talking about programs, or code). We have the context of an application firmly established - people go to their computers, interact with applications, and do work.

SOA is about the next phase of computing - enabling computers to do some of the work unaided (computer-to-computer interaction), and freeing the user from having to interact with application after application to get work done. Anyone who's ever dealt with a call center and had to wait on the phone while the call center representative said, "Now give me just a minute, I have to bring up another application to do that," knows how frustrating, time-consuming, and challenging the traditional application-centric approach can be. Services (and the composite applications that no longer require the user to switch between applications to do a single business process) are the way we plan to break the tyranny of the application and take back control of the computer.

Services don't exist in a vacuum. Part of the chicken and egg problem we have in moving from applications to services is that services make only a limited amount of sense in the context of a single application, so there's not a strong impetus for application developers to use a service-based approach toward design when creating applications. Similarly, when you take a holistic view of the enterprise, you don't necessarily see the catalog of services you'd like to have to really establish a true architecture, and derive the highest value from composing processes from services.

That's where a platform becomes the middle ground and the way out of the chicken and egg problem. By establishing a platform for the enterprise, you can start to drive applications toward becoming services. A platform should provide discovery, registration, an ESB at the minimum, with most platforms also including security and management services as well. When you start to build your applications (or buy them specifically for the platform in many cases) to take advantage of the service orientation of the platform, you start to realize the advantage of the platform, and move past the challenge of service-enabling applications.

It also underscores the importance of getting a strong platform, one where the parts all work together well. You may not want to get everything from a single source or, depending upon your enterprise needs, you may not be able to do so. A soup-to-nuts infrastructure out of the box from a single vendor is not necessarily nirvana anyway, as those of you who've had the best-of-breed discussions over the years can attest. What is important is establishing an SOA infrastructure, or platform, on which an enterprise can leverage its application portfolio. The platform enables the portfolio transformation that must occur in order to move from an application orientation to a service orientation.

So it's funny, even though I don't think you can buy an SOA, I definitely think you can acquire a platform, and you're much better off with one then without.