dcsimg

Five SOA Problems Advocates Need to Resolve

SHARE
Share it on Twitter  
Share it on Facebook  
Share it on Linked in  
Email  

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.

NewsletterITBUSINESSEDGE DAILY NEWSLETTER

SUBSCRIBE TO OUR DAILY EDGE NEWSLETTERS