SOA - service-oriented architecture - seems to be on everyone's radar. It's rare to walk into an IT meeting where someone hasn't bombarded the audience with the current buzzwords, and where someone isn't extolling the virtues of an SOA. Somehow, even though it's not really about a single application, even application designers are "building SOA in."

The funny thing though is, as with sex, everyone is talking about it but no one is doing it. Well, maybe not no one, but there's an awful lot of fence-sitting going on. In part, I can see it as very similar to the Internet. When it first came out, everyone had to be on it, but not that many were, and when they did get there, it took them a while to figure out what to do. Similarly, SOA is being paraded as the latest, greatest cure for the common cold. It slices, dices, changes your oil, and rotates your tires.

Now, SOA really DOES do a lot for an organization. In fact, it's such a good idea that once you have it explained to you, your first reaction is likely to be "well, yeah, of course." SOA is a natural idea for organizing systems and maximizing the return on investment in IT. However, that same obvious perspective hides another SOA truism - measuring the return on investment is very difficult.

It may seem intuitively obvious to reorganize systems so that they can communicate with one another without barriers or without needing specialized software adapters. However, putting a price tag on interoperability can be very difficult. In the end, have you returned a significant business value if you invest millions to reorganize, but don't gain any functionality in the process? Maybe, especially if you can reduce your operating and maintenance costs, but those are typically soft numbers, ones that don't have the same emotional impact on a corporation as increasing sales by 10 percent, or lowering production costs by a factor of two. One of the most significant challenges in achieving SOA is finding the business value that you can bring to the table during the process, which is why many SOA projects are funded by using SOA as the underpinning to achieve a business goal, such as consolidating redundant systems, while adding new functionality.

Another aspect of SOA that holds back adoption is the question of who will go first. SOA often adds cost to the first few projects; instead, it's the later projects that reap the benefits of SOA architecture. In large companies this can add to the delay in moving to SOA, as different departments play a game of musical chairs to see who will foot the bill for additional infrastructure and retooling of the development group for an SOA approach. Much as the children trying to get Mikey to eat Life cereal, departments say, "Not me, let Mikey do it."

A third problem in the adoption of SOA is that a services approach really asks a company to look at the way they do business. There's a governance issue, as well as the greater issue of who owns what. Obviously, this is heavy political territory, and it's not easy to get someone to give up their "turf" just because it may be in the best interests of the company. In the end, many organizations will need to redefine the ways they incent people in order to adopt an SOA approach, even if it appears straightforward and obvious on the surface.

Slowly though, the technologies that support SOA, namely Web services, are making their way, finally, into the corporate mainstream. Thankfully, there is enough of a vendor groundswell beneath Web services that the eventual, obvious move to SOA will ultimately take place for most organizations.