By Sean O’Shaughnessey
In many older integration environments reside hundreds, if not thousands, of point-to-point integrations. System A is integrated to system B with special code using the APIs of the two systems. If System A needs to talk to system C, a separate integration scheme is created using the APIs of those systems. Quickly, an integration map starts to look like spaghetti or a cobweb with multiple integration links sprouting from each enterprise system to any or all of the other enterprise systems.
Bundled-Up Integration
Some major enterprise application vendors—such as ERP, CRM, and supply chain and retail management software companies—have begun to “bundle” integration capabilities into their products. These are “plug-and-play” integrations between two applications that are available from the same vendor and tuned to the needs of those specific systems. Even though the heart of these bundled integration capabilities is essentially an ESB, the resulting integrations are not a Services Oriented Architecture (SOA). In most cases, this is simply “spaghetti in a box.” The integrations look like an SOA implementation, in that the various enterprise applications are all integrated to an ESB, but the resulting integrations are still essentially point-to-point. Just like when a bird quacks, you know it is not a goose —when you are using point-to-point interfaces with relatively modern tools, you are not implementing an SOA environment.
It is not unusual for a company’s CIO, who uses these “bundled” integration tools, to complain that the company gets little value from SOA. This is unfortunate. However, the fault lies not with the concept of SOA, but rather with the lack of flexibility and capability of SOA tools. If your integration tool only supports a spaghetti-like infrastructure, then you simply get a better tool to make spaghetti—and not a tool to make lasagna (a closer food approximation of an ESB).
False Implications
SOA implies that you are using an ESB, but just because you are does not mean you are implementing SOA. A proper services-oriented architecture reuses the service provided by any given system. A proper ESB solution will transform the data from a common services call so that it can be fed appropriately to any resulting system. By using the same call to any resulting system, and transforming the data in flight to the intended system, you begin to reduce the complexity of the environment. This simplification allows for a significantly reduced cost structure that can more nimbly respond to business requirements. By responding to the needs of the business, the CIO can see true ROI gains from SOA.
If your integration patterns are coming from the vendors of those applications, be careful that you don’t end up with spaghetti in a box in place of the lasagna you ordered. For more info, explore this whitepaper: Four Clues Your Organization Suffers from Inefficient Integration, ERP Integration Part 1.
