January 25, 2007
What Is SOA Anyway? Part II, Hype
I am sure many of you have seen this happen before: You are working on v0.9 version of project, making nice progress. Then out of nowhere, out steps this marketing whizz-kid or wonder salesperson who meets a client and tells him all about the wonderful features of the product (you were planning for v3.5), signs a deal, and leaves you pick up the pieces and somehow try make all that work. Hype is like the power of thousand such whizz marketers working against all of us -- making it almost impossible to live up to these "common truths" which are actually hollow promises. Let's just take a quick look at few of the more common hype-originated myths surrounding SOA.
The claims that SOA will increase reuse and/or will make it easy are common -- so much so that it has been adopted by serious technical people. For example, the article SOA: Separating Myth From Reality by Mark Potts (who is a CTO in one of HP's divisions) says:
One of the major benefits of the set of architectural principles that define an SOA drives organizations towards a greater level of reuse and consistency. The amount of achievable reuse increases over time once newer services are designed using existing services in an organization....
Well, as object orientation taught us reuse is harder the larger the components we want to use. Since larger components have more context, they are hard to reuse elsewhere. SOA is no different. Services should encompass a meaningful business capability -- if you build it right you can use it to solve your business needs and you can integrate it to fulfill your business processes. The chances are, however, that you will not be able to reuse elsewhere. SOA is more about business agility and the ability to change rather than reusing services out of their original context.
There is some substance to the reuse claim, if we take a broader definition of the term "reuse." As an organization moves to SOA, it can make the transition an evolutionary process -- and still use existing assets in the transition phase. This evolutionary process approach contradicts another SOA hype generated myth which states that SOA requires an all or nothing approach.
Consultants and technology vendors would have you believe that you either have to fully embrace SOA or it just won't work. I don't think so. I agree with Sohel Aziz that it is actually the other way around -- if you want to succeed with SOA you need a pragmatic step-by-step approach.
When you think about it, a Full Enterprise SOA initiative would mean replacing all the enterprise's systems. Do you really think the business will just freeze or halt while the SOA initiative is underway? Not quite. Rather, a comprehensive SOA initiative is like building a new interchange on a highway. You need to provide ways for the traffic to continue to flow (business to continue to operate) while work is underway. More so, you will make as much progress as you can without disturbing traffic.
Also SOA characteristics (which I'll expand more about later) can even allow you to take an incremental way for removing legacy systems by exposing existing functionality using new SOA interfaces before you actually replace the underlying system.
Another SOA myth is that it will make integration easy. SOA puts a lot of emphasis on the interface , which makes it a "easy" to just make services talk to each other. On top of that SOA is (usually) based on standard protocols like XML, WS*, http and the like, so it is easy to just tie services together and integrate them.
Fred Brooks told us ages ago:
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
SOA does not change these basic rules. To properly integrate services you need to model their contracts in a way that will make them usable for multiple business processes -- this is not a small feat and that is where you'd spend most of the time -- this is still hard and SOA does not solve it. Once you solve that, SOA does help you lift some of the burden of doing the actual integration - but that's just making integration easier and not making it easy.
Yep, it seems SOA is indeed in dire straits. In fact, I've almost managed to convinces myself that Fowler is right and SOA is beyond saving. Luckily it does seem that over the past year or two businesses are starting to actually build SOAs and we are starting to see some more consensus on what SOA is and isn't. It seems that today there are two prevalent ways to look at SOA -- from a business point of view and from a technical one.
Posted by Arnon Rotem-Gal-Oz at 02:08 PM Permalink
|
