Columns

On track for integration

• By Tony Baer
• October 30, 2003

Systems integration has long been the kiss of death for IT projects. Software history is loaded with ill-fated attempts to standardize the way programs integrate, from proprietary technologies like IBM’s SAA to SQL relational databases and Rube Goldberg-like CORBA component architectures. Yet integration remains the costliest part of a software project.

Not surprisingly, all these approaches fell short because of their rigidity.

Conventional software programs were monolithic. They combined functions in lockstep, running every transaction against pre-set targets. If you changed the data or business logic of a transaction, the changes had to cascade back to every process, message and data source they touched. When EAI middleware emerged, it worked the same way.

Now a re-invention of an old idea, the Services-Oriented Architecture (SOA), threatens to replace hard-wired connections with a service request model that could be far more pliable. Unlike conventional systems, SOAs specify information or service requests, but not which system must respond.

By not having to specify targets, a service can be provided by a new app or fed from a new data source without changing the service request or any systems that depend on it. Integration links can evolve with a company’s business or application portfolio. And, as businesses increasingly share processes, connections can evolve with business relationships.

Web services emerged with the idea of providing a standardized way of applying SOAs. So far, the industry has coalesced around the basic building blocks: how to build service requests (SOAP); how to declare services (WSDL); how to list them in a directory (UDDI); and how to specify security and digital signatures. Not surprisingly, vendors are debating the higher-level stuff verging on business logic, like describing or choreographing business process workflows.

SOAs may simplify integration, but they won’t make it simple. They will standardize the way existing systems talk to each other, but custom development will still be needed. SAP project veterans know that businesses have unique processes, workflows and data structures that can’t always be force-fit into standard software. The same goes for integration. Even with tools that provide visual data mapping or automated parsing of legacy logic, there will always be some system that has undocumented code or data structures. And for packages like SAP, there will always be customizations that require special treatment when designing services-oriented interfaces.

In the end, SOAs won’t replace existing monolithic apps, but will instead put a prettier face on them. Don’t confuse SOAs with Web services. You can implement SOAs without XML Web services, and vice versa.

In the long run, XML Web services will become the primary means for implementing SOAs. But that’s at least three to five years off. In the meantime, we have lots to learn about SOAs. Many first steps will be false steps, like using SOAP messages to connect the same old software in the same old ways, ending up with hard-wired point-to-point connections written using current industry standards. And, because of all the vendor support, generating SOAP messages will be easy. The result could mean even more hard-wired app-to-app connections to maintain than in the past.