Looking at SOA through ESB-colored glasses
In his latest analysis published in Application Development Trends, Steve Swoyer discusses a challenge that's often overlooked in SOA discussions: the way members of different parts of the organization view the world. Everyone may be aboard the SOA concept, Steve says, but have different ideas and support different technology approaches to make it happen.
How 'technology prejudice' clouds SOA decisions
For example, Steve notes that there are transaction-oriented people and EAI people (many of whom are now ESB people), who tend to see the world in from a transaction -oriented and business process-oriented point of view. Then there are data management types, who take a bigger-picture view of data sets. Then there are the Web 2.0 people, who are typically developers who don't have a stake in either the enterprise application integration or enterprise data management worlds.
What's wrong with this diversity of viewpoints? Steve relates the story of a data warehouse architect who attempted to set out on an SOA project with an application architect who was a "staunch ESBer:"
The application architect... saw the project through ESB-colored glasses and -- not surprisingly -- devised a scheme to use an enterprise service bus (ESB) as the backbone of this company's SOA effort. That's hardly an unorthodox view... except for one thing: in this company's case, an ESB-centric viewpoint complicated what could have been a fairly simple integration project. In other words... this organization could have accomplished what it wanted without going the full-blown ESB route (which required purchasing and implementing a brand-name ESB from a recently-acquired software vendor)."
The ESB-versus-data architecture point of view is but one example of "technology prejudice." Ideally, SOA should rise above that, offering business value not connected to any particular technology approach. But that's not the way it happens in the real world.
Steve quotes consultant Mark Madsen, who makes a living out of going in and cleaning up enterprise technology messes. The problem, Madsen said, is people go into projects with their own pre-conceived notion of what technology works. "These projects go awry because their implementers, either inside IT personnel or (more frequently) outside integrators, are enamored of particular technologies or solutions -- to the detriment of more functional alternatives."