Pete Lacey started an interesting discussion a few days ago when he reopened the debate over the use of the term “SOA” in his blog post “What is SOA?”. He certainly dove in to attack the idea of SOA, but did not come to any useful conclusions.
He starts by offering a humorous anecdote to explain, to himself apparently, why we need SOA. The most interesting line is this, when describing how CORBA was a huge innovation:
“CORBA. Look, see. Interoperable remote procedure calls.”
Interoperable remote procedure calls. Yep. That was CORBA. Jump down a little…
Worse, CORBA wasn’t quite as easy to use as it seemed. It was complex, nothing interoperated, it didn’t work through firewalls, and a bewildering number of specs were coming out of the OMG.
“Well, how about this new SOAP thing,” said the new new guy…
OK… so here comes SOAP to replace CORBA for what… interoperable remote procedure calls. See where this is going? Fast forward again.
We just need to give this idea a name.”
“I’ve heard it called service-oriented architecture,
So, according to Pete, SOA is a name for a technology, based on SOAP, used to give us interoperable remote procedure calls. I shudder at the thought.
From there, Pete goes on to criticize SOA because it isn’t an architecture and the term ‘service’ doesn’t suit his mindset. Heck, with that definition, he’d be right.
Give me a break! Service Oriented Architecture is not RPC. People who write RPC code to integrate applications have created a ball of rubber bands in their infrastructure… I don’t care if they used CORBA, or DCOM, or RPC, or Stored Procedures, or synchronous pixie dust! When you follow an antipattern in your architecture, the technology cannot save you.
The moment you criticize SOA on the basis of the technology, you’ve missed the point. SOA is an architecture… a technology agnostic architecture. It requires the basic things that are so difficult that folks are afraid to do them, and therefore the technical implementation fails and people blame the technologist… what are these so-important things that people are afraid to do?
Common Information Model
Common Business Event Model
Common Solution Model
Common Technology Model
I dare you to make any form of simplified, integrated, agile infrastructure work without these things.
What is going to become of the ‘beloved SOA’ for those geeks who live and breathe the term? Oh, who cares? We will rename it and it will keep coming back, just as it has always done. Pete even suggests a new name, “Network Oriented Computing.”
Oh… right… we renamed it. THAT will make it work!
The concept is sound. The concept works. (Every implementation of SAP is based on the above elements. SAP integrates extremely divergent systems into a single scalable platform. There’s your proof of concept).
So stop arguing about the name, for goodness sakes. Attacking the name of something you don’t understand is a tactic best reserved for pundits and political candidates. If you don’t like the politics of your opponent, attack his (or her) clothing, hairstyle, automobile, whatever… something that has nothing to do with the point.
Just as Pete did.