Newsletters Welcome, Guest Log In | Register

Integration

Begin with business processes and then progress into leading-edge technologies

About this Blogger RSS

Subscribe

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

  • Daily Edge
  • CTO Edge Update
  • Business Tools & Templates
  • Aligning IT & Business Goals
  • Maximizing IT Investments

5

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

Posted by Loraine Lawson Jun 26, 2008 12:58:22 PM

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?

Add a comment Leave a comment on this blog post.
Jun 27, 2008 11:31 AM Guest 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.

Jun 27, 2008 4:01 PM Guest 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.

Jul 10, 2008 11:49 AM Guest 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.

Jul 11, 2008 12:57 PM Guest 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.

Jul 11, 2008 1:10 PM Guest reamon  says:

@Mark: +1

@Todd: +1

SOA for Dummies: IBM® Limited Edition Mini eBook

This eBook introduces you to the basics of SOA in context with the real-life experiences of seven companies, demonstrating that SOA allows you to work smarter and optimize costs for more significant business success.

Driving Business Agility Through SOA Connectivity and Integration

This white paper shows how a service oriented architecture (SOA) helps align the infrastructure with business needs in order to achieve maximum flexibility.

Social Media Policies Toolkit

Define the rules at your company for the proper use of social media platforms such as Blogs, Twitter, Facebook and Youtube. Ensure your users are spending their time productively and company resources are being used for the business.

Learn more >

The Complete IT Policy Kit

Download a comprehensive bundle containing over 40 IT policy templates. Each can be modified to align with your specific business requirements. Complete instructions are included.

Learn more >