One Technology Does Not Fit All SOAs

Loraine Lawson

Monday, I shared an article in which Accenture CTO Donald Rippert outlined four phases of implementing service-oriented architecture:

  1. Using XML as an interface.
  2. Making legacy systems available as Web services.
  3. Using an ESB (enterprise service bus) to connect Web services and use composite processes.
  4. Using BPEL (Business Process Execution Language), which he notes will make it possible to change a business application by changing the process model rather than the code.

I know that not all SOAs use Web services, that there are alternatives to an ESB and that BPEL -- well, that's a whole Pandora's box of disagreement. But I read these as sort of typical evolutionary stages most people go through. As in, it's typical for companies to try at one point to do it all with Web services, then add the ESB.


But Rippert's use of those particular technologies to describe the phases really bothered SOA consultant and ZapThink managing partner David Linthicum. In fact, this week, Linthicum used his weekly InfoWorld podcast to outline exactly why he's bothered by this list.


He begins by agreeing with Rippert's initial point that people are doing the first couple of steps for SOA -- primarily, building out Web services, and then not driving it to the next level. But he heartily disagreed that it's necessary to use Web services, ESBs or BPEL at any phase of your SOA.


He started with the Web services phase. No doubt about it -- Web services can play a key role in a SOA. It's the enabling standard for externalizing services out of existing systems, Linthicum said. But sometimes, it just doesn't fit the bill and you need to use J2EE or even a proprietary system.


SOA's layers shouldn't be defined by specific technologies or standards, he counters. You can't buy an ESB or decide to use a standard and then make it work no matter what.

That's just completely silly and you'll end up building something that ultimately is not going to be effective or efficient for the architectural issues you're looking to solve.

Instead, you need to look at your requirements first and then choose a technology that will address those needs. If you're not sure what some of those alternatives might be, listen to the podcast -- Linthicum offers several alternatives for each phase.

At the end of the day this is architecture. Architecture is going to take some analysis and understanding before you figure out what technology and standards and patterns you need to toss at the solution.

This may not be easy to do -- you may need to hire additional help, either by finding a consultant or creating a staff enterprise architecture position, if you don't have one.


In November, I asked Linthicum how companies can find qualified SOA consultants. He suggested you find a qualified architect who can guide your SOA implementation. He recommended you look for an experienced architect with a non-vendor certification -- ZapThink offers such as a program, as does The Open Group.


But, as Linthicum warned in his podcast, the costs of choosing the wrong technologies and standards are high.

... At the end of the day if you don't make correct decisions, you're going to end up with an architecture that's not as efficient as it could be and therefore it's not able to perform as well, it's not going to be as changeable, it's not going to be agile and it's going to fall short based on the investment dollars you put into it. And you don't want to be that guy.

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

Post a comment





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




Subscribe to our Newsletters

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

Subscribe to our Newsletters

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