Nobody needs reminding that systems integration has long been a black hole for IT projects. Software history has been larded with ill-fated attempts to standardize the way programs integrate, from proprietary technologies like IBM's Systems Application Architecture (SAA) to SQL relational databases and Rube Goldberg-like CORBA component architectures. Yet, integration continues to be the costliest part of any software project.

More recently, middleware has become the most popular integration approach, with most tools using proprietary technology-based hubs to direct interactions between applications, messaging systems, and data sources.

All of these approaches failed because of their rigidity. That's not surprising. Conventional software programs were monolithic -- they combined lots of functions in lockstep, running every transaction against preset targets. So if you changed the data or business logic of a given transaction, those changes had to cascade back to every process, message, and data source they touched. When enterprise application integration (EAI) middleware emerged, it worked the same way.

Now a reinvention of an old idea, the Services-Oriented Architecture (SOA), threatens to replace hard-wired connections with a service request model that could prove far more pliable. Unlike conventional systems, SOAs simply specify information or service requests, they don't specify which system must respond. In the long run, that has huge implications for making integration easier.

XML Web Services are a new set of standards for 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 haven't agreed on the higher-level stuff verging on business logic, like describing or choreographing business process workflows.

Every tech fad needs some cold water, so here's it. SOAs might simplify integration, but they won't make it simple or commodity. As we learned with ERP, customization remains necessary because every company runs itself differently. SOAs won't replace monolithic software, but complement it, providing ways of standardizing how existing systems talk to each other. And don't confuse SOA 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 3 - 5 years off. In the meantime, we still have lots to learn about SOAs. Many first steps will be false steps, like using SOAP messages to connect the same old monolithic software in the same old monolithic ways. These days, you can't ask for quicker progress, and you wouldn't want to.

Tony Baer is principal of onStrategies and a well-published IT analyst with over 15 years background studying implementation issues in enterprise systems, application development, data management, and business intelligence. The author of books covering .NET and J2EE, Baer's writings also appear in Application Development Trends, Computerworld, Computergram, and Manufacturing Business Technology. Baer's commentaries and rants on the state of the IT market are available here.