The SOA Manifesto (aka Snake Oil Agreement, or SOA) has been published, attempting to set out a value system for SOA deployments modeled on the famous (and useful) Agile manifesto. Like the Agile manifesto, the SOA version was written by a team of people some of whom are luminaries and personally people I respect hugely. Unlike the Agile manifesto however, the SOA manifesto is nothing more than snake oil to give the vendor community a thin veneer of respectability atop their increasing bureaucracy, deteriorating levels of innovation, and increasingly painful pricing models.
But don’t take my word for it, let’s walk through what the Snake Oil Association wants us to believe. Let’s start with a definition of SOA:
“Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.”
Wow, that’s profound. Sitting in my study looking out of the window, I can’t help but see the similarities to my own immediate environment. For example, “Comfortable office chairs are a paradigm that frames what I do (or in this case simply frames my butt). Chair oriented architecture is a type of architecture that results from applying chair-ness to seating situations.”
What a crock. Those bon mots are nothing but recursive dribble which say nothing about SOA, and much about the validity of the manifesto. But it continues:
“We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.”
In what sense? I don’t think I see too many signatories of the Snake Oil Agreement that work with organisations (though there are one or two, I’ll call these “the good, but chronically optimistic, guys”). I see a lot of people who sell to organisations, but that’s helping in much the same way that if you suffered an injury, I kicked you in the general direction of a hospital. I don’t see much in the way empirical evidence to support this claim, whereas there was a lot of train-wreck data to support the Agile manifesto.
Then the fun really starts, where the undersigned state concoct a bunch of values which embody the goodness that is SOA.
1. Business value over technical strategy
Whose business value? The customers, or the middleware vendors? And does this mean technical strategy has less merit? I find that hard to believe when several of the signatories are prominent luminaries in technical strategy for SOA (for example ESBs).
Let’s chalk that one up to typical industry newspeak, run it up the flagpole, and move on.
2. Strategic goals over project-specific benefits
That is, don’t think about getting this piece of software into production and realising business value, instead chain yourself to an improbable strategic vision. This contradicts the first assertion. It’s also disingenuous, because it implies that projects cannot add to a strategic vision, which is pretty dumb really. It’s really saying: we don’t trust IT staff with anything important which is rude and narrow-minded beyond belief.
3. Intrinsic interoperability over custom integration
Another disingenuous point I believe. This is telling you to buy kit for “intrinsic” interoperability rather than doing it yourself with anarchic(!) technology like the Web. If you really believe in this value, then bin your ESB and embrace a platform which has intrinsic interoperability by dint of a few commonly accepted formats and protocols. If you’re unsure: see RFC2616 and friends.
Furthermore it’s ironic that “intrinsically interoperable” systems like ESBs need development effort to get them installed and running and plumbed into their victims, which seems to me a lot like custom integration between system and ESB anyway. Whoops!
4. Shared services over specific-purpose implementations
Premature optimisation, pure and simple. Re-use is great, but I’ll start with use and move on from there. The fallacy of services is that they’re designed to be shared – they’re not. It’s the business capabilities which services implement that may or may not be shared. It’s tail-wagging-dog to think that service architects should design for sharing, when its the business capabilities and processes which dictate that particular outcome.
5. Flexibility over optimization
This is one I happen to agree with. Unfortunately I don’t see how the Snake Oil Association has reached this conclusion, unless the signatories honestly believe that their wares support flexibility (ha!) or fail to deliver optimally (more likely). An ESB isn’t flexible, nor is it optimal.
6. Evolutionary refinement over pursuit of initial perfection
Again I agree with this principle, in fact it’s the very embodiment of Guerrilla SOA. However it conflicts with the second assertion that the Snake Oil Association values strategic goals over project-specific benefits. Those project-specific benefits are the vehicle for those evolutionary refinements that we want to pursue.
Over the last year I thought I’m come to terms with dangerous SOA sentiments, I had even started to shelve some of my thoughts on ESBs thinking the world had progressed passed 20th century network topologies and sales models. The Snake Oil Agreement and the Snake Oil Association have demonstrated that my hope was premature, and that my own moral relativism has lead me to mistakenly believe that I should live and let live alongside what is plainly a retrograde model for large systems engineering.
I have now dismissed my moral relativism. No longer will I hold try to see things from the Snake Oil Association’s point of view: that view is simply commercially and morally wrong. The Snake Oil Agreement has distilled everything that is wrong with enterprise software delivery, with vendor politics, and with golf-course decision makers. I say it is not a rallying cry to repeat the manifest mistakes of the past, but a focal point for a revolution in the way systems are built and evolved.
La lucha continua!