Can ERP Serve as My SOA?


With the growing popularity of the service-oriented architecture (SOA) concept over the past few years, the major ERP vendors have all announced strategies to rebuild their ERP applications as a set of services (see the ABCs of SOA for a deeper explanation) that are connected together using Web services standards. Instead of tightly integrating all the different business processes expressed within the ERP system into a single, monolithic system that is difficult to change and integrate with other systems in the company, an SOA approach will take those processes and split them up into independent chunks that can be more easily changed independently of the other processes and linked with other systems through the use of integration language that all the vendors agree to adopt in their software—the software integration equivalent of everyone agreeing to adopt HTTP and HTML as the standard ways to communicate over the Web and display their websites.

But beware the kumbaya approach to integration. The Web happened because it reached incredible scale before vendors could intervene to push their own, proprietary ways to display webpages or communicate over the Web. SOA and Web services standards haven't been so lucky.

Indeed, integration standards interfere with ERP vendors' traditional ways of gaining and keeping customers and market share. Before the Web came along, your integration strategy was simple: Buy as many preintegrated applications from a single vendor as possible. That worked for you, and it worked extremely well for the vendor; integrated application suites fetched a high price and required long-term maintenance and support contracts that promised a steady, predictable stream of revenue from customers.

Even better, CIOs' fear of integration pain gave vendors a built-in sales advantage whenever a company wanted to add a new application to its stack. It was easier for the CIO to pick a preintegrated application from the dominant vendor than to take a risk on a best-of-breed newcomer—even if its application had better functionality—because expensive integration disasters had become the much-publicized bane of the industry. Better to have disappointed users, CIOs reasoned, than headlines in The Wall Street Journal. Even those CIOs who risked a best-of-breed strategy had to pick a vendor to hook the different systems together. The purveyors of integration software, traditionally known as middleware, all had their own ways of doing things that required you to use their software—you couldn't suddenly swap your vendor out for a new one.

But the rise of service-oriented architecture has produced a shift in integration strategy. SOA makes the radical assertion that the enterprise application infrastructure is irrelevant. Technology is constructed according to services specified by the business, not by processes contained within an enterprise application vendor's software box. In this scenario, packaged software is a piece of the service, just another component in a larger business process—such as an insurance claims process that links a jumble of functions and data inside ERP, CRM and old mainframe legacy systems. The application's vendor doesn't matter anymore; the linkages between the applications are the important thing.

As a result, the vendors' integration strategies have become more important than the features of their software. (Both dominant enterprise software vendors, Oracle and SAP, have begun offering integration middleware to go along with their software suites, although both are sticking with the big, integrated software suite vision.)

In the brave new world of SOA, the big software vendors have decided to take a page from Microsoft's playbook and duplicate the Windows strategy. With the Windows operating system running on 95 percent of PCs, software developers are eager to create software that works with Windows because it means they can reach the most customers and make the most money. As a result, the thousands of applications available for Windows today ensure its dominance in the operating system market tomorrow. Similarly, the big enterprise software vendors are trying to ensure their futures in an SOA world by assembling ecosystems around their core applications.

For example, the most startling change in strategy comes from SAP, long the dominant player in ERP. For years, SAP resisted alliances with other software vendors and insisted on building its own applications. But post-SOA, SAP is busy service-enabling its applications and using its new middleware software, NetWeaver, to entice companies to build software to run on the NetWeaver platform (which incorporates Web services standards). Online CRM software provider Salesforce.com has created AppExchange, where developers can download free software to integrate their software add-ons with Salesforce's core software. Oracle, meanwhile, has been busy building its platform through acquisitions, including middleware software that is the linchpin for its SOA pitch.

Although the middleware companies have much more experience with the foundational elements of SOA, such as integration and messaging between dissimilar systems, both they and the ERP providers are still looking for ways to keep their customers. Consequently, despite the abundance of Web services standards embedded in their products to ease integration headaches, everybody has a proprietary hook somewhere. For example, Oracle's Fusion applications will work only with Oracle's database. SAP's new applications require the use of NetWeaver middleware, according to Gartner and Forrester Research. Even the middleware companies still have enough proprietary elements to make it difficult to swap out their integration software.

The bottom line for CIOs? Beware ERP vendors—or any vendor—pledging to build your SOA for you. Unless you're not worried about continued dependence on your vendor.

But CIOs on the whole fear dependency, especially in the current wave of consolidation in the software industry, according to a 2005 Accenture survey. While 65 percent of CIOs said vendor consolidation makes for a more integrated software infrastructure, and 61 percent believe it will reduce their vendor management burden, 87 percent said vendor consolidation will lead to lock-in, 61 percent believe it will decrease price competition, and 57 percent said they believe it will reduce pressures for vendors to innovate. Only 35 percent saw vendor consolidation as a good thing.

For true SOA believers, an SOA built as much as possible using Web standards (sadly, those standards remain very incomplete) and controlled by the CIO—not the vendors—is one of the best protections against lock-in. Though mixing and matching chunks of ERP from different vendors and linking them together in an SOA world will be easier, even with the solutions offered by the ERP vendors, remember that no one vendor can be all things to everyone. Companies that have the flexibility to integrate a new business capability into their software infrastructure as soon as it is available—rather than whenever their preferred vendor gets around to building it—will have an advantage over their competitors.

Christopher Koch