The Case Against Using SOA for Integration

Loraine Lawson

Last week, after spying on Yahoo's SOA Group, I wrote a piece questioning why so many SOA experts hate the SOA/integration connection. Basically, I couldn't grasp why it was such a big deal-why not let people use SOA for integration as a first step to using SOA more broadly, I argued.

 

After all, that's what most companies are doing anyway.

 

I've been spying on Yahoo's SOA group some more, and the debate is still raging. There's even some noise that the original Gartner analyst quote about "SOA is integration" may have been a misquote-something meant to be sarcastic, but taken as straight in the original article.

 

You may be wondering whether this sort of pedantry is worth your time. But the fact is, there are important arguments against using SOA for integration-or, at the very least, building SOA with integration as the end game. If these arguments are right, it could mean your SOA investments won't payoff. And nobody wants that.

 

I'm not going to synthesize a bunch of different posts (yawn!) when you can read the whole thread for yourself. And, frankly, there's no need to, because Burton Group Vice President and Research Director Anne Thomas Manes wrote an excellent blog response that covers the most important arguments against SOA as a means to integration.


 

When heated discussions like this start, people tend to get distracted on tangents. Eventually, their arguments get fleshed out, but it can take awhile.

 

Manes, whose work is focused on research, tends to write like a researcher: She thinks the issue through calmly and thoroughly and her writing reflects this. Her research background also gives breadth to her insights. As a result, her response-to me - represented the best of the arguments raised against SOA and integration.

 

Her first point is that just because companies are reporting success with using SOA for integration does not mean those cases are, in fact, SOA. In fact, her research shows they aren't really service-oriented architecture, but rather examples of service-oriented integration:

"... they are examples of projects that used service oriented protocols (e.g., WS-*) and middleware (e.g., ESB) to integrate two or more application systems. But from an architectural perspective, you still have monolithic systems bridged by integration middleware."

Now, as Manes points out, there's nothing wrong with this approach, but you shouldn't expect big-picture SOA results if all you're really doing is integration:

"It's fine to use service oriented middleware to implement integration projects, but then you need to readjust your expectations. Most organizations that I speak with say that the goals of their SOA initiative are to reduce costs and increase agility. Unfortunately, these organizations aren't likely to achieve these goals if their projects only focus on integration."

Manes also offers a response on the newsgroup that addressed, albeit indirectly, my suggestion that analysts encourage companies to start with integration and then build up:

"I always recommend a 'think big, take small steps' methodology. So I concur with the take one small step at a time' advice. But I find that many organizations forget the 'think big' part of the equation."

Her post discusses the success companies have found when they did focus on architecture. Alas, so far, she's found only four such companies.

 

It's important to note that there are many people who agreed with Manes and Michael Poulin, who started the thread with his plea to "to slow down spreading such Integration SOA madness?" (BTW: Poulin wrote a response to the original IT Business Edge post as well.)

 

There are also a lot of people who think SOA can be used for integration, but that the value proposition shouldn't stop there.

 

And then there are people like Gartner analyst Nick Gall, who raised this biting question:

"Doesn't the suspicion that SOA is vacuous grow stronger when you see that we can't even agree about the relationship of SOA and integration?"

So, where does this leave those of you who don't care about SOA philosophy, but do want to know what SOA can do for you?

 

Well, let's assume you don't care whether you're living up to someone's ideal of SOA. If you're solving your problems-even integration problems-and you're using service-oriented principles and you want to call it SOA-that's your business. Sure, analysts and others may find it annoying, because then it's hard to quantify if "SOA" is succeeding or not, but that's really not your problem, is it?

 

You might even want to download this vendor-written white paper I stumbled across recently called-Manes, look away now! - "Worst Practices in SOA Implementation," which focuses on the top-four worst practices for SOA integration. That'll show 'em.

 

On the other hand, if you want to make sure that you achieve the big-picture results that SOA promises and you're planning to spend (or already have spent) a lot of money service-enabling your systems ... well, then, you might want to pay attention to the nuances of this debate, particularly since some say starting out with integration can mess up your efforts from the get-go.

 

Unfortunately, the experts can't seem to agree on the 'right' answer to the SOA/integration question. And even when they do agree, there are nuances to where they stand on the issue.

 

So, stay informed but beware: This issue may boil down to a judgment call - and it's ultimately yours to make.



More from Our Network
Add Comment      Leave a comment on this blog post
Dec 23, 2008 12:19 PM Francis Carden Francis Carden  says:
Great thought provoking - on many angles - piece. How about another take, for the sake of another take!IT have had 25+ years to do SOA. I haven't found anyone in IT who can tell me why they hadn't done SOA until now! How strange!Simplifying this just a little bit. Lets assume I have 2 legacy subroutines (I wrote subroutines 20 years ago so I could re-use them). I need code to integrate them so do I expose that new code as a subroutine? Sure, why not. The next group comes along and needs one of the first subroutines but needs a slight change. Since the risk of that change may break one of the other callers (I don't have time/resources to test), I copy one of the first subroutines and make the change... and so on and so on and so on.SOA is a great concept, a great idea. It is a great goal for a great architecture BUT BUT BUT it ALWAYS has bee a great goal. We've been trying this for 25+ years! It's not new and you still need integration (the services and the integration will all be legacy tomorrow morning).Same problems, potentially worse because the more consumers you have of the same service means once that service is built, it's legacy will live on! Reply
Dec 30, 2008 5:05 AM Jeff Mommsen Jeff Mommsen  says:
In my opinion, this highlights the need for managment of services. Of course there will be requirments for "specialisations" and you will end up with as many as you agree to glue together through integration. Integration + SOA is like OO with multiple inheritence. It can be really powerfull but makes it easy to end up with an administration nightmare.I'm new at this (first exposure to SOA was 18 months ago), so from my simplistic (not scarred from lots of experience yet) point of view, I would think that keeping it simple needs to be applied in big doses.Decide on where you want to put the effort in terms of time and money. Be pragmatic about implementing to enable business agility but maybe more purist about alignment with your own strategy and longer term goals. I'm also looking to rely heavily on established industry standards for guidance on what we should be providing as business functions.If I don't bleed out in the next 6 months trying to stick to an SOA long term vision but putting in formalised integration as a platform (in an environment where we already have lots of integration :-) ), I will see how the pain alters my opinion. 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.