Is SOA 'Snake Oil Architecture'?

Grady Booch, IBM's resident software architecture guru, warns that the market is being overrun by what he calls "Snake Oil-oriented Architecture."  In a recent post, he reaffirms that he believes SOA will deliver value to organizations, but that Snake Oil-oriented Architecture "showmen" are selling too much of the sizzle, while neglecting to tell customers about the multitude of hard technical and process decisions that go into long-term SOA.

"SOA's value proposition begins with the A in its acronym: architecture. There is sound, proven value in governing and growing a system's architecture; there are also hard decisions that must be made, many decisions of which cannot be known a priori (which is why a process shaped around the rhythmic incremental and iterative release of executables is so important). Stripped away of all the hype, a Service-Oriented Architecture is essentially a variant of well-proven message-passing architectural patterns. The variance comes in the form that services are cleverly designed to take advantage of the Web-centric infrastructure that pervades many organizations: services allow you to send and receive semantically rich messages through firewalls."

Booch observes that once solutions are purchased and brought back to the real world, enterprises "quickly find that instituting some of these new-fangled ideas is not as easy as they were led to believe, and that these elixirs are not so far-reaching as promised them."

A lot of questions will be left unanswered, such as:

• What distinguishes a good service from a bad one?
• What should the granularity of a service be?
• When should I offer up a stateless service versus a stateful one?
• How do I expose some services to some clients and hide them from others?
• How do I best expose services in a legacy system?
• Who should own/maintain these services?

Booch continues that in a short time, many customers "will get an uneasy feeling that maybe - just maybe - there are some simple fundamentals on which their organization is not executing well, and that the whole elixir exercise was worse than useless, because it actually diverted them from their real problems while creating new ones."

I agree with Grady Booch's assessment, and there indeed are too many solutions out there being marketed as SOA in a Box, when such a thing cannot exist. SOA is a methodology, a process, a new way of thinking, and not a product or even group of products.

It didn't start with SOA, of course -- the IT market has seen plenty of snake-oil hype over the years: "client/server computing" and "object-oriented technology" in the early 1990s, "E-commerce" and "enterprise portals" in the late 1990s, and drilling down to offerings such as "CRM," "sales force automation," and... let's not leave out "ERP." 

SOA is the first time, however, that a "solution" has not come out of a single class of software that is being packaged and sold. It can be applied to every type of software -- development tools, middleware, enterprise applications, productivity applications, collaboration tools, everything, everywhere. That ambiguity makes it very easy to sell the elixir without pinning it down to curing a specific disease.