SOA is typically championed by technologists. That makes it easy to view SOA as merely a technology for which new tools can be bought — a premise vendors are all too happy to support. “But it doesn’t matter what technology you use to do SOA,” advises analyst Manes. After all, a key premise of SOA is that services are designed to work together regardless of the specific technologies they are based on.

That’s why it’s a mistake to buy SOA infrastructure, governance, or development tools until you have your enterprise architecture in place, along with the operational architecture -- that is, the design for how you will actually run your services. From those architectures, you’ll understand how many services you are likely to have, how they are likely to interact with other services, and what their performance, security, and other requirements are. Only then can you build the right infrastructure for them and know what tools you may need. Yet Manes estimates that nearly all enterprises adopting SOA start with the tools rather than the underlying business processes.

And keep in mind you may already have many of the tools in place, such as a messaging system and a testing suite. “You could use the latest technology, or you could use legacy technology for your services,” says GM’s Zhang. SOA per se does not require new tools, though you may discover that having new tools can make the effort easier.

For example, an ESB can consolidate messaging, logging, metrics, application management, and alerting functions into a common engine, simplifying the infrastructure, says Pete Conner, CTO of Primitive Logic. But you may have these functions already in the forms of messaging middleware, XML managers, and EAI systems. And you can’t assume that any specific ESB will do the job you need, as there is no standard definition of what an ESB should do, Conner says.

“Often, an ESB is very much an extension of EAI; it’s about integration, not about reuse or contracts,” he warns.

Back to intro | Next: Addressing the data problem