News

SOA: It's the People, Process and Orientation

• By Stephen Swoyer
• May 26, 2008

Such talk is common with any business process consultant, or software engineering consultant, or -- for that matter -- with an increasing number of data management or data warehousing gurus, and they'll tell you the same thing: clients have service-enablement and SOAs on the brain.

The results of a recent SOA survey sponsored by SHARE (the independent mainframe users group) support this: one in four companies have now embarked on SOA efforts, while another one-third are considering or are in the process of planning SOA deployments.

The irony, many experts say, is that comparatively few adopters anticipate how conflicts between SOA principals could sabotage their projects before they leave the starting gate. Such conflict isn't just an issue of people and process inertia -- although both remain redoubtable bulwarks to SOA adoption -- but resides in the differences in orientation.

Consider the experience of veteran data warehouse architect Mark Madsen, a principal with consultancy Third Nature.

One of Madsen's clients recently embarked on a mostly straightforward SOA implementation effort. The application architect overseeing this effort was a staunch ESB-er: he 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, Madsen concedes, 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, Madsen says, 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).

Implementing the ESB introduced another layer of abstraction (i.e., wrapping already wrapped services in still another container that the ESB itself could consume) and also required that the organization implement a brand name application server, in addition to its existing application server investment. In addition, it introduced a substantial degree of latency: instead of calls directly between service end points, traffic had to be routed over the ESB, which acted (according to its purpose) as a conduit for service communications.

This is just one example among several, says Madsen, who recently delved into BEA's AquaLogic ESB and the Mule open source ESB, among others.

Nevertheless, he's not rejecting SOA and ESB adherents out of hand. "In this case, [the use of an ESB] significantly complicated something that really shouldn't have been all that complicated," he concludes, adding that SOA-over-ESB reminds him of another end-all-be-all object reuse technology: CORBA.

So what's the problem? Bob Eve, vice-president of marketing with data federation specialist Composite Software, thinks it boils down to differences in orientation -- if not ideology: ESB advocates are from Mars, data management gurus are from Venus. Or vice-versa. The salient point, Eve argues, is that neither thinks alike.

"In the SOA world, there's transaction[-oriented] people, the old EAI people, and now they're the ESB people. They're transaction oriented, business process oriented. When it comes to data, they're single-row-reads, single-row-writes. The paradigm that those developers use is very much one of process logic," Eve suggests.

Data management types tend to take a bigger-picture view, according to Eve. "Data folks are used to thinking in terms of data sets. They don't write code, they draw lines between tables to create joins. That's how they think. They're 98 percent read people," he points out. "What I think happens in the SOA world is that it's really dominated initially by those trying to composite together applications. [These are] the EAI people. What's starting to happen now is that those who are data oriented are having their voices heard. That's going to shake things up."

The irony, he argues, is that it's the Web 2.0 types -- i.e., developers who don't necessarily have a stake in either the enterprise application integration or enterprise data management worlds -- who "get it."

"Web 2.0 guys view it [the problem] as just these big sets of data they want to join," Eve argues. "They approach it [the issue] with a fresh perspective. They really aren't bogged down by thinking [solely in terms of transactions] or data sets. They aren't committed to this idea that they must have an ESB. They're just looking for the neatest, most efficient way to do it [integrate these resources]."

The foundational divide between ESB acolytes and data management gurus is just one of the potential pratfalls customers tend to encounter when they're pursuing SOA strategies. The salient point, says Brad Marshall, a project director with IT services firm TekSouth, is that customers shouldn't take on major projects like SOA just to do SOA -- nor, for example, should they take the ESB route simply because everyone else (or, more narrowly, their competitors) is doing it. Companies should embrace SOA when and where it makes sense -- e.g., if they need to update or replace existing assets or services, if they plan to introduce new business processes (or reengineer existing processes), and so on.

In other words, companies should take on big projects such as SOA when there's a clear requirement for change -- or when the TCO benefits of making a change are demonstrable. Even then, Marshall stresses, companies need to critically evaluate technology solutions: just as you don't need a full-blown data integration platform, à la Informatica, to build a functional data warehouse, you don't necessarily need a full-blown ESB -- with all of the requisite trimmings -- to do SOA. Marshall should know: his company has been called in to clean up arrant projects at many U.S. firms, he says. In a number of cases, he stresses, 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.

"At TekSouth, we get called in to clean up a lot of messes. We have a reputation in the industry as 'fix-it' guys," Marshall explains. "Much of time we're called in to 'fix' things that never should have needed fixing in the first place," he continues. "Companies get sold on this idea of changing stuff up to be more competitive. There are clearly cases where that works -- and there are clearly a lot of cases where it doesn't." What clearly doesn't work is going into a particular project scenario with a technology prejudice already in mind, he concludes.