SOA needs manifestation….not manifesto

I’ll bet that it felt like a momentous achievement to get a group of very well-known bloggers, analysts and technologists to agree on a “manifesto” for services-oriented architecture (SOA).

Imagine the group-think of it all: a bunch of people with widely-varying views came together and produced….yet another statement. I imagine the camaraderie and group hugs that must have accompanied this effort resulted in repeated choruses of Kumbaya…or at least a serious drinking party to celebrate the achievement. (Guess which we like better.)

OK, OK…I know there’s no reason to be snide. And, yes, I realize that the manifesto is unobjectionable..that criticizing it is the equivalent of dissing motherhood or sunshine or quarks.

But the big problem for SOA — which is “dead” one moment and “strategic” the next — is that it doesn’t need yet another descriptive manifesto…it needs manifestation. Consider the definitions of manifesto and manifestation. Manifesto is about intention. Manifestation is about materialization. One is talk. The other is about something real.

And high-faultin’ talk has been SOA’s problem for…well…forever. While it’s good fun to have an ole-time, intellectual techno-debate about this aspect of implementing SOA versus that technique for doing it, the consistent response to SOA from legions of developers has been, “We just don’t care. And, not only don’t we care…since you are making this so hard, we’re gonna stay right where we are doing things as we have always done them. Good luck with your SOA thing.”

What happens when industry thought-leaders run smack into the biggest wall of them all: developer resistance? They talk some more. Consultants build big engagements to explain to management how to get around developer resistance. Vendors who bought one of everything and lumped it all together as “SOA” have made implementing their stacks so expensive and complicated they advocate “centers of excellence” — that is, internal lobbying groups — who try to explain it all to the average development team using…guess what…still more words.

In short, SOA needs fewer words and more products mere mortals can use.

How about we manifest SOA in products so that it’s invisible? So that you can do the right thing without knowing the first thing about SOA? Do civil engineers demand that we understand the properties of asphalt before we drive on it? Must you ascertain the precise chemical composition of your dinner before you eat it? No, we just drive home at night and stick a fork into the main course. We don’t think twice about it.

That’s what SOA needs to be (and what we think ActiveVOS achieves). As an industry, we need to take what we know, stop talking about it and scaring people off — and build it into shrinkwrap-like product that have people doing the right things automatically.