In recent weeks, several of the IT industry's biggest application vendors have made significant announcements about how they will help their customers migrate to service-oriented architectures (SOAs). As these vendors execute their strategies, their SOA platforms will compete for market share in much the same way that application development platforms compete for developers today. Such competition will present customers of these vendors with critical decisions over the next three to four years.
Among these vendors, none is larger than enterprise application provider SAP. As I explained in an article two months ago, SAP is transforming its NetWeaver middleware suite into a platform for integrating business processes. Just as importantly, SAP intends to make NetWeaver the basis for its own SOA. This was made clear last month by SAP executives at the company's SAPPHIRE user conference. At the conference, SAP announced that it is making key elements of NetWeaver available as component-based services that developers and customers can invoke through Web Services interfaces. These services will comprise what SAP calls its Enterprise Services Architecture (ESA). Over the next two years, SAP intends to expose growing amounts of NetWeaver functionality as ESA components. By 2007, the vendor intends to have all of its current application suites running on an ESA version of NetWeaver.
During the next two years, SAP will aggressively recruit other IT vendors to develop versions of their products that are customized for ESA. To demonstrate its commitment to the effort, SAP used SAPPHIRE to announce ESA partnerships with 10 IT vendors. Among them was Computer Associates, which is developing management products for SAP environments that will take advantage of ESA components. Another vendor, EMC Corporation, is incorporating ESA into an SAP version of its information lifecycle management products. Through such partnerships, SAP hopes to build more functionality into its SOA platform than those of its competitors.
SOAs as Migration Paths: The Oracle and Microsoft Strategies
In a subtle way, SAP's announcements last month were a response to statements that Oracle Corporation made a few weeks earlier about its SOA strategy. As I explained in an article last month, Oracle will transform its middleware products into a platform--known as Fusion Middleware--for creating SOAs. The platform will not only let Oracle customers integrate applications from multiple vendors, but also enable them to integrate applications from the vendors that Oracle has acquired. Through Fusion Middleware, Oracle intends to make it easier for J.D. Edwards, PeopleSoft, and Retek users to integrate their existing applications seamlessly with each other and with new applications. Oracle hopes that many of these new applications will be the upcoming releases of its enterprise software suite that combine functions from the applications of all the acquired companies. This means that Oracle's SOA strategy and its Fusion Middleware are meant not only to help customers become more agile businesses, but also to help them migrate to Fusion applications.
Like Oracle, Microsoft has an SOA strategy that is meant to integrate multiple enterprise application suites. Over the last several years, Microsoft has acquired four distinct application suites: Great Plains, Navision, Axapta, and Solomon. Through a strategy known as Project Green, the company plans to incorporate a single SOA into all four suites. This will make it easier to migrate the applications to a unified code base.
Project Green will involve at least two and perhaps three waves of product releases. In the first wave, which begins this year and is scheduled for completion in 2007, Microsoft will spend much of its time developing SOA components that give its applications a common look and feel. These components will let users of all four suites access their applications through Microsoft Office and SharePoint Portal Server. The suites will also gain a common report generation and business intelligence facility based on SQL Server Reporting Services.
In a second development wave that is scheduled to start in 2008, Microsoft will provide SOA components that give all four suites a consistent programming environment and a common way to model business processes. The SOA will also provide services through which all applications can invoke technologies in the next major release of the Windows operating system known as Longhorn. Once these tasks are close to completion, Microsoft will focus on creating a single application code base to which users of all four suites can eventually migrate.
Let the SOA Games Begin
According to the marketing materials of SAP, Oracle, and Microsoft (not to mention IBM), their SOAs will usher in an era in which applications from multiple vendors can easily and seamlessly interoperate with each other. That may often be the case in the future. However, it is still likely that SOAs will differ somewhat in the standards they support, the programming models they incorporate, and the tools that enterprises use to manage them. They will also gain the support of different vendors of infrastructure products and development tools. As a result, companies will continue to experience interoperability problems with SOA-enabled applications, though the problems should become less burdensome.
Several years from now, I believe that lingering differences between SOAs will lead most medium-size companies to standardize on a single suite of SOA-enabled applications from a single vendor. Just as these companies standardize on a single enterprise application suite today, they will standardize on a single SOA provider tomorrow. Most providers would prefer customers to make this choice anyway and will likely design their SOAs to encourage standardization. This means that SOAs will become platforms that compete with each other in much the same way that the J2EE and .NET development platforms compete today. This may be frustrating to large firms that want SOAs to liberate them from vendor lock-in. For the many mid-market firms that are used to standardizing on a single vendor, it will probably be business as usual. They will choose, though they may not choose the SOA platform of their current vendor.
It is precisely because customers may switch vendors that SOAs represent a critical inflection point for IT vendors and their customers. Knowing this, IT vendors are working hard to determine how they can make the transition to their SOA-enabled applications as effortless as possible for their customers. Which vendors are likely to win the SOA wars, and what will their victories mean for customers? I will seek to answer those questions in a future article.