SOA, cuts the Gordian Knot --NOT.
Posted by Uncle Bob on 10/03/2007
In 333 B.C. Alexander the Great cut the Gordian Knot with his sword, breaking that symbol of ancient power and ushering in a new empire. Some IT managers feel that SOA will finally cut the great Gordian Knot of their tangled and tumultuous software systems. Will it?
No.
Let me restate that more clearly for those of you who may still have doubt.
No frickin way Jose!
Most software systems are a mess. SOA is not the cure for that mess. Indeed, SOA doesn’t even start to be feasible until the mess has been cleaned up.
Again, let me restate that.
SOA does not help you clean up the mess that your software is in. In order to adopt SOA you must first clean up the mess you have made. Once the mess is clean, then you can start to think about SOA.
Right now, at this very moment, some IT manager is reading about how the next release of some Enterprise Service Bus is going to solve all his woes. All he has to do is install this wonderful piece of software, tie it into the new whippy-diddle business process modeling tool. Get some clerks to write the XML files that describe their business processes, get some other clerks to write the message translators that drive that great interoperability Babel Fish in the sky. Get some business process modelers to draw pretty pictures of all the interconnections between the systems. Feed that all into the ESB, and shake vigorously with deadlines and threats. This will cause fuzzy bunnies to hop happily over the green fields of his IT systems.
Right.
The reality is that the first letter of SOA, namely “S”, stands for “Service”. Not to put to fine a point on it, SOA means an Architecture Oriented around Services. What is a service? A Service is a piece of software with the characteristics of a service? What are those characteristics? They are: Low coupling, independently deployability, stable interface, etc.
Most software professionals (if that term is not oxymoronic) will recognize this set of attributes as being identical with that of the “Components” of the 90s. Indeed, Services are the new Components. The words are synonyms.
This means that SOA is just as hard to do as COA. (Component Oriented Architecture for those of you who are acronym challenged). Indeed, SOA is COA!
Now, I know it’s been a long time. But does anybody remember what it took to do COA? No? Then let me tell you a little story to jog your memory.
In the mid ‘90s I had a client who had a 250MB executable written in C++. (Yes, I know this seems like a hello world program today, but back then 250MB was a big program). This client was vexed because every time he changed even a single line of code, he had to rebuild the entire executable, burn it onto a CD, and ship the CDs to his installed base. This was costing him lots of time and money.
What he wanted was a way to break his application into components and then ship only those components that changed. His hope was that he could ship them over the internet because they’d all be small enough to email or FTP. (This was back when people did not regularly download 4GB movies, or backup 100GB disks over the internet every night).
So he adopted COA, and the popular implementation platform of for COA, COM+ (Otherwise known as void**: Nothing to the power of nothing.) He slaved away for months breaking his application up into components that could be dynamically loaded in DLLs. And in the end, he succeeded. His application was completely—componentized.
However, there was one little snag. He forgot to decouple the components from one another. Each component depended on several others. There were cycles in the dependency graph of components. (Aside to the architecturally challenged: “That’s bad.”) So in the end, when he changed a line of code in one component, he had to rebuild and redeploy all the components. He had to burn all those components onto a CD.
In short, nothing had changed.
Long long ago, I watched a software developer write complicated macro in his highly powerful text editor. It converted all tabs to spaces. I remember watching him start it. The code he was transforming was on the screen. He ran the macro, which took several minutes to run. It displayed a series of dots running across the screen. It was very impressive, and looked like it was doing something significant. And then when it finished, the code was redisplayed on the screen. I laughed, because after all that work of translating tabs into spaces, and putting dots on the screen, the displayed code looked exactly the same as when he started. It was as if nothing had happened.
My client’s reaction to his inability to independently deploy his components had nothing to do with laughter.
The point? SOA will not cut the Gordian Knot. Indeed, it will pull that Knot even tighter. The Knot can’t be cut. There is no magic that will make the mess go away, or make the mess less of an issue. If you want the flexibility of SOA, then you must clean up the mess you have and then slowly and gradually build services from those cleaned up systems.
The real point? TANSTAASB. (There ain’t no such thing as a Silver Bullet).
Comments
Germán about 18 hours later:
Let me see if I get you right.. You mean that you don’t get any benefit from SOA if you have interdependencies that AREN’T resolved through service calls only? And, would this mean that you would have functionality that “resides” in one service but is compiled into several services because they use it directly—-i.e. coupled?
Scott Carlson about 23 hours later:
I consulted at a company where they tried to push ESB (specificially IBM’s tragically terrible doodleware product WBI). As part of this some of the ivory-tower residents in the company made the claim that “everything is a service.” Yep, the people at the level that could say what the real business services were in a company, punted in the worst possible way.
Anthony Bailey 1 day later:
The main point of the article is very true.
But however unsophisticated their motivation, I do think it’s a good thing when big companies buy into SOA.
I have come to believe that an SOA-friendly environment makes it a bit easier for little islands of excellence to evolve, survive and even thrive within the enterprise mud.
Sebastian Kübeck 5 days later:
As I read IBM and WBI: Can anybody of you help me find arguments to get those sales people off my customer’s boss? Recently, he gave me some sales stuff about a SOA appliance and told me: “It’s easy. Even I could configure it!”. I asked what he intended to use it for. He replied “It’s great! They gave me a three day training course for free!”.
About Silver Bullets: They are neither IT-specific nor new. Here is an introduction to Silver Bullets & friends from a scientific (and humorous) standpoint:
http://www.amazon.com/Ultra-Solutions-How-Fail-Most-Successfully/dp/0393025144
Tenant Screening over 3 years later:
It was very impressive, and looked like it was doing something significant. And then when it finished, the code was redisplayed on the screen.
Criminal Records over 3 years later:
I laughed, because after all that work of translating tabs into spaces, and putting dots on the screen, the displayed code looked exactly the same as when he started. It was as if nothing had happened.