Five SOA Problems Advocates Need to Resolve

Loraine Lawson

Boy, is SOA ever in the trough of disillusionment.

 

Criticisms of SOA are popping up left and right. Of course, regular readers may remember my own freak-out a few weeks ago when I'd just had it up to here with the inconsistencies and "fuzziness" of SOA. (Thank you, Mr. Carden, for advising me to have a cup of tea; it helped a great deal.)

 

This week, CIO.com has a telling column by Robert Frank, CIO of Countrywide Capital Markets, in which he calls out SOA as a plagiarized reincarnation of the subroutine. It's a pretty amusing read, actually. Of course, inevitably he compares SOA to object-oriented programming, which did become standard practice, but he also points out it wasn't an easy road:

"Systems were built that were excruciating slow where the programmer tried to combine objects that did not reside in memory. Operations that should have taken nano seconds if built conventionally now took physical seconds while programs attempted to execute objects that may not resided outside of the program space. Programmers would die in vain trying to debug code that inherited their functionality from a plethora of sub-classes."

The quirks were worked out in the end but then -- as Frank points out -- vendors need to sell new coffee makers, and so SOA came along.

 

The criticisms of SOA are well-earned. After all, if you promise people the moon, it's a safe bet there's a bit of hype going on. And let's face it, there are some issues SOA practitioners need to work on.

 


This is just me guessing, but it seems SOA would be more palatable for everyone and perhaps even more reliably successful if SOA advocates could:

 

1. Identify what technologies are essential for SOA. Or, at least, identify some standard practices and patterns for building SOA. I get that SOA should be flexible and not technology-dependent, but I still think it would cut down on the confusion if we could at least identify some types of SOAs. For instance, most SOAs rely on Web services, but over and over, you'll see an admonishment that "SOA is not JBOWS (Just a bunch of Web Services)." OK, that may be true. But often, Web services ARE a key component for specific SOAs. Likewise, ESBs are widely used for SOA messaging. But there are alternatives. It'd be nice if we could have a sort of cataloging of the SOA options.

 

I should point out that there's already an effort under way to identify SOA patterns, by people like Google software engineer and architect Gregory Hohpe and Arnon Rotem-Gal-Oz, author of "SOA Patterns" and the Architecture & Design blogger at Dr. Dobb's Journal. Perhaps SOA advocates should spend more time discussing this type of work.

 

2. Decide on an accepted -- dare I say "standard" -- definition of a service. When people who build SOAs can't agree on what a service is, you have to wonder how, exactly, they're building a service-oriented architecture. I think a standard definition would go a long way to establish credibility and stability for SOA.

 

3. Identify SOA metrics. I know, I know -- it's hard to define SOA metrics. Big deal. Complaining about IT metrics is a national pastime. At the end of the day, you still have to define and monitor them. So, let's put together some SOA brains and figure it out.

 

4. Find a way to explain SOA to the business. I get that many of you feel this is unnecessary. Alas, SOA is going to require money for many, and guess who controls the purse strings? Also, if you read business publications, you'll see that SOA has already made headlines there. Here's an excellent example. A good starting point would be reading Joe McKendrick's post on nine places where SOA made a difference.

 

5. Don't be pedantic. This is ALWAYS a problem in IT and, really, geekdom in general. But, it's even more of a problem for SOA, because SOA is pretty fuzzy already. For instance, you might want to consider whether it's really worthwhile to argue about things like whether integration projects are SOA or EAI 2.0. Most companies seem to think they're using SOA for integration -- and they're happy about it.

 

Why on earth the SOA crowd shoots itself in the foot by arguing with them that their successful integration project was not a "real" SOA is beyond me. I suspect some of the arguments over "real" SOAs are the same form of geek snobbery we saw when people would say a Mac wasn't a "real" computer. It probably makes sense to you, but really -- you're not helping yourself.

 

Bottom line: Don't let the backlash dissuade you from the importance of service-oriented architecture. It is a real approach to designing IT systems, with implications beyond IT. There are success stories, and integration is a big component of those successes. After following it for a year, I do believe that, in the end, it will emerge from the trough of disillusionment.

 

What's brilliant about Gartner's hype cycle is it's actually quite good at predicting popularity. But if you follow it to its end, you'll see the cycle ends with the technology du jour emerging from the Trough of Disillusionment to reach a point of general acceptance and established usefulness -- albeit at a status much shorter than the original, over-hyped promise. I do believe SOA will reach that status quo point.

 

But not without a few criticisms and a bit of tweaking along the way.



Add Comment      Leave a comment on this blog post
Apr 14, 2008 9:33 AM Julian M.N. Bourne Julian M.N. Bourne  says:
SOA, if interpreted broadly as an integration framework for enterprise server applications using Web Services as the protocol layer and exchange format, does have some useful potential if combined with Representational State Transfer principles and a data-centric approach (rather than business logic approach).The main problem is that at the moment the major software vendors and software services vendors (without naming names) are continuing to attempt to embrace it as a kind of CORBA++. This is great for them - it allows them to maintain their proprietary data models that limit the scope and reliability of interoperability solutions by forcing everyone to interop. through arcane APIs with thousands of special cases and unknown side effects.So SOA is not really the problem - it can be adapted to more data-centric interoperability solutions: its just that most of its proposed use to-date reiterates the same old pattern of protecting proprietary interests that limits serious interoperability.Customers have to be savvy enough to demand something better before this will change. The organizations I'm involved in are taking a very serious look at RDF & SPARQL backed Web Services as an interoperability baseline for this very reason: data-centric, yet you can call it SOA and apply ReSTful principles to it. Reply

Post a comment

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

null
null

 

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.