SOA defined by what it is not

Once in a while a new concept comes along which is so important that everyone has heard of it, and almost no one in the industry can really afford not to have an opinion on it. This concept is a buzzword ringing out so loud that entire IT department directions have been carved out on its promise, and entire companies are founded to live and die by it.

Yet this concept does not lend itself easily to a sound-bite which, when you hear it, you know you don't have to read the book. No, it was not something invented in a flash, and no one jumped out of the bath in a Eureka moment having "discovered" it. Rather legions of thinkers "developed" the fullness of its dimensions through an evolutionary process based on "best practices" and perceptive insight.

In short it was wisdom of experience, not a law of physics. (No it is not just biologists who have Physics Envy - a hungry longing for an elegant fundamental law that describes a spectrum of natural phenomena which is true for all time).

All the more harder to define when this concept is an abstract Architectural pattern composed of finer-grained Design patterns. Especially hard when some of its goals seems congurent with an older Architectural pattern making it ripe for confusion; and when many old timers are affronted by each trend in the Hype Cycle in the industry feel they have seen it all before and that this latest new wave is simply “old wine in new bottles” or the best - “we are already doing this”.

I am talking about SOA.

At such times, it is often more helpful to illustrated this concept by what it is not.

Attached is a composite definition of the wisdom of IT sages - SOA. But I think more importantly - for those like me who understand faster and better by having something difficult explained to them what it is not - I have listed SOA Anti-patterns with the intention of illustrating “what as explained by what it should not be”.

What is Not SOA