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

Leave a response