Sunday, July 01, 2007

How to Ruin a SOA Program and Bankrupt IT

I spent the first half of last week in New York city at the SOAWorld 2007 conference, where I had the privilege of presenting my thoughts on the ROI of SOA. It was a fun session with a very inquisitive audience. I have received a lot of valuable feedback on the presentation and the supplemental article in SOAWorld magazine and would like to address one topic that has come up frequently, and that is whether simply choosing SOA over point-to-point (P2P) integration is enough to achieve agility.

I explained in my article that a fundamental characteristic of SOA is its linear cost curve and contrasted it with P2P's non-linear cost curve. The "bottom line" is that SOA inherently keeps costs linear, predictable, and scalable over the long haul while the cost of P2P accelerates uncontrollably. The net effect is that service-oriented networks are enterprise assets that appreciate in value as they grow, while P2P networks are depreciating liabilities. SOA, by its nature, produces positive ROI. P2P, by its nature, produces negative ROI. Therefore, if you embrace SOA and forsake P2P you should be set, right? Wrong.

To be sure, taking a stand against traditional P2P integration is a big leap in the right direction. However, it is one thing to say you are service-oriented and quite another to be service-oriented. And if you're talking the talk but not walking the walk you can end up in worse shape than if you had opted against SOA in the first place.

SOA often requires a paradigm shift -- a shift in attitudes and thinking away from project-based, short-term objectives toward enterprise-based, long-term objectives. When the people doing the talking are not the ones doing the walking, the mental shift may not occur everywhere it needs to. This can produce a situation where an organization has obtained sponsorship and funding for an SOA program but lacks the discipline to adhere to its core principles during implementation. When SOA has been promised but the implementers are only comfortable with P2P, the result is often point-based SOA.

From a financial standpoint, point-based SOA combines the short-term cost hikes of SOA with the long-term, accelerating cost accumulation of P2P. What is left is an overly complex network of tightly-coupled services linked together through physical connections and proprietary interfaces. (Imagine a network of web services in which each service can be used by only one consumer.)

Relating this phenomenon back to the Bottom Line analysis, the resulting cost curve (P-SOA) resembles the P2P cost curve. The only difference is that it has been shifted upward by a coefficient that represents the extra infrastructure costs of SOA. In the end, point-based SOA costs more than traditional P2P integration and yields no gain in IT flexibility or agility.

IT organizations that are adept at selling SOA at the podium need to also have the tactical ability to execute on SOA missions. This requires shared vision, passion, and deep commitment to the fundamental principles of SOA at all levels of the IT ranks. Companies that have difficulty producing this cultural unity are at a distinct disadvantage in ever realizing the benefits of SOA. In fact, they may be better off just ignoring the hype and walking away.


At 7/5/07, 11:00 PM, Blogger niraj said...

While I kinda get the notion of Point based SOA. It might serve well to illustrate with a few examples.

The way I am reading this is that you are referring to XML Services but with no Service Registry Or service lookup. So essentially the consumer have knowledge of the producer.

Is that what you had intended.

On a seperate note: I have been struggling with the notion of Dependency Injection in an SOA world. Is there a spring counterpart in the SOA world.

At 7/6/07, 10:04 AM, Blogger Marc Rix said...

I characterize point-based SOA as an environment in which data and functions have been abstracted from their native containers and exposed using "standard" technologies (such as XML), but where the interfaces to those services are designed on a one-off basis. Each service interface, therefore, serves only one consumer, producing tight coupling throughout the network.

This situation can arise with or without SOA middleware, such as ESBs and XML gateways, since either way a service is bound to a single consumer. The bottom line is that implementing SOA without careful attention to service interface design can lead to rampant tight coupling. This inflexibility coupled with the added investment in SOA technology and skills can end up costing more over the long haul than a traditional P2P approach.


Post a Comment

Links to this post:

Create a Link

<< Home