SOA: "Failure by obscurity"

Fellow ZDNet blogger Joe McKendrick poses the question, "How do we really know when SOA ‘fails’?"

Here are a few choice quotes:

What does SOA failure look like? Lots of money spent on development with no return to date? No or little reuse or sharing of services, so they end up sitting as virtual shelfware? (Failure by obscurity.) What happens then? Does the SOA get ripped out of the infrastructure and everyone starts over?

SOA success or failure is probably harder to pinpoint than other types of projects. Here is a brief summary of some SOA points of failure. Note that these are not fatal career-terminating failures. No major ripping and replacing required; simply a change in direction.

• Lack of a true SOA. An organization may only think it has SOA. Worse yet, it ends up as a “service-averse architecture,” which is an architecture that is built without having first consulted the people who will use it, or is so secure and complex that it discourages people from using it comfortably.
• Lack of reuse or sharing by multiple business units. Such services may languish until a more effective governance strategy can bring them into the light of day. Or, sharing may actually be happening, but the business is not tracking these metrics.
• More money spent than gained — over the long run. Increased costs are to be expected in the early phases of SOA. The other issue may be that the business may not be adequately tracking where gains, if any, are taking place. So SOA proponents may not even know if the SOA is delivering, beyond anecdotal evidence.
• More, not less, vendor lock-in. The purpose of SOA is independence from vendors, so components or services can be swapped out as needed. If you still have to wait for a vendor to improve upon a particular part of an application, or are forced to upgrade, then SOA is not doing what it’s supposed to be doing.

Putting aside SOA-specific issues, such as component reuse, this list could describe causes of failure in traditional IT software implementations. Lack of user adoption, ROI questions, and vendor lock-in, for example, are all time-tested elements of what we might call "failed-project syndrome." It may not be pretty, but that's the way it is.

Update: a perfect example of "failure by obscurity" is the FBI Virtual Case File program, in which the FBI wasted $170 million because the agency didn't ask users what they needed.