If Integration Feels So Right, How Can It Be Wrong for SOA?

Loraine Lawson

Officially, integration isn't a good enough reason to do SOA. Just ask the experts.


David Linthicum says vendors are hyping the integration aspects of SOA, which is really only one small component of service-oriented architecture. Further, he thinks this puts SOA at risk, because it encourages tactical, not strategic, thinking.


Ronald Schmelzer of ZapThink contends most SOA integration projects aren't actually SOA at all. He contends most companies are really buying repackaged enterprise application integration (EAI) solutions.


More recently, enterprise architect and blogger Todd Biske seemed to support this SOA-subsumes (or should I say, consumes?) integration in a recent post. Responding to my interview with Forrester analyst Ken Vollmer, who advocated for Integration Competency Centers, Biske wrote:

"The real issue I had with some of the justifications for having an ICC was an underlying assumption that integration is a specialized discipline. While this was the case 8-10 years ago, I think we've made significant progress. I actually think there is a specific detriment that an ICC can have to an SOA effort. When an ICC exists, integration is now someone else's problem. ... It's this type of thinking that will doom an SOA effort, because everyone's first concern is themselves, not everyone else. To do SOA right, your service teams should be consumer-focused first."

All of this grumbling over integration and SOA makes you wonder: Is integration somehow bad for SOA?


I don't know the answer. But I do know this: Most of you don't care. You're building something you consider SOA, and you're doing it because you believe it will make integration easier.


Don't kill the messenger, guys, but that's what John Burke, a principal research analyst with Nemertes Research, found when he interviewed executives from 50 companies, ranging in size from 30 to 300,000 employees, about their experience with SOA. He shared some of the details of the resulting report, "Service-Oriented Architecture and Applications," with me during an interview published this week.


I asked Burke point blank what he discovered about he relationship between integration and SOA. His answer:

"We found that was the most prominent of the reasons people gave for having put a SOA in place, any kind of a SOA, whether it was meant to embrace all of their systems or just a few. The main reason that they had brought the architecture in was to integrate applications from a variety of sources."

The runner-up reasons, in case you're curious, where:

  • Companies want to use SOA "as a development framework and methodology for people who build applications for themselves," and
  • Because SOA comes in when they buy new tools -- whether they want it to or not.

You may find reasons to disagree with what the companies categorized as SOA, particularly the companies that said it was coming in because they acquired SOA-based tools.


But as for the number-one reason -- integration -- that's hard to rationalize away, particularly since it's not the first time a study found integration was driving SOA adoption. Remember earlier this year, when AmberPoint polled architects, operations staff and developers about SOA adoption? Seventy-five percent of companies surveyed earlier this year by AmberPoint cited integration as the "issue SOA best addresses."


It seems to be working for those companies. While most companies still couldn't quantify SOA's benefits, most companies reported it had definitely helped them solve integration and other problems, according to Burke:

"We found the majority of them felt if they had one in production that it was delivering real benefits to them in terms of reducing the cost of integration of applications, or reducing the time that it took them to bring new applications online, or otherwise reducing the cost of bringing those applications online."

In the second portion of the interview (to be published next week), Burke goes so far as to suggest integration could help companies quantify that elusive SOA ROI. But more on that later...


Like I said, I'm not defending or advocating the focus on the integration and SOA. However, with so many reporting that it works for them, I can't help but wonder, like the late great Elvis Presley, if it feels so right, how can it be wrong?

Subscribe to our Newsletters

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


Add Comment      Leave a comment on this blog post
Jun 27, 2008 11:01 AM Robere Eve Robere Eve  says:
SOA is not Integration and Integration is not SOA. Integration remains a specialized discipline, especially when one considers the range of toolsets (EII, EAI, ETL, BPM), use cases (Composite Applications, BI, Portals, etc.) and architectures (CS, Web, SOA, Legacy) involved. Further, ICCs can be implemented across a range of centralized and distributed models, coaching vs. doing, provisioning vs. developing vs. operating, and more.Bob Eve. Reply
Jun 27, 2008 6:31 PM Mark Griffin Mark Griffin  says:
I think a lot of the confusion on this topic is because a lot of folks never really understood Enterprise Application Integration in the first place. EAI is not about tying applications together in fact it's just the opposite. It's about how to make you applications communicate and exchange events without the applications knowing that they are communicating and exchanging events. A lot folks don't understand that and it showed in their EAI deployments. They ended up with a bigger mess but in centralized location.The concepts behind the pattens of EAI are very similar to SOA. Abstraction, reuse, composability, fine grain, coarse grain are all there in EAI just like SOA. Integrations are in effect services if done correctly not just moving data around which is a common EAI misnomer. It's not the latest and greatest buzz word so a lot of analyst are glossing over the actual details of what EAI was and is. Sure they are lots of folks who wired two apps together and called it EAI. There are also a lot of folks who are doing RPC calls via Web Services and calling it SOA.The comment saying EAI is tactical is not accurate. I not sure how anyone who has worked in business IT shop could come up with that statement. Reply
Jul 10, 2008 6:49 PM Todd Biske Todd Biske  says:
Integration can be done via services, there's no doubt about that. I'm not surprised at all that the vast majority of survey respondents also indicated that ease of integration was a driving force for their SOA efforts.There was recently a discussion around integration on the Yahoo SOA list and some debate on whether integration always required a third party or not. I fell into the camp of saying that making two systems talk to each other, with or without a third party, is an integration exercise. Where I'd like to see things go is where integration with other systems becomes a primary concern, rather than something done when we need it. If we design integration points (which not surprisingly, should be services) from the beginning, rather than bolting them on when needed, we'll be taking the right step forward. If this is the case, then all developers should be thinking about integration, not just the integration technology specialists. Reply
Jul 11, 2008 8:10 AM reamon reamon  says:
@Mark: +1@Todd: +1 Reply
Jul 11, 2008 7:57 PM reamon reamon  says:
@bob eve"SOA is not Integration and Integration is not SOA"That's correct. But an integration architecture might be service oriented (which, strictly speaking, makes that IA an SOA).SO principles borrow many notions from common integration practices. It is no surprise then that many associate SOA with integration.To get a little abstract here, SO is about service consumers interacting with service providers. Typically, the consumers are in different ownership domains from the providers. That, almost by definition, is integration.SO can be viewed in a manner such that integration is effectively the core value. Components are designed from the outset to be integrated with other (possibly unknown at present) components. Instead of an afterthought, integration aspects are considered right away. Reply

Post a comment





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




Subscribe Daily Edge Newsletters

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

Subscribe Daily Edge Newsletters

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