Web services certainly have the potential to improve and simplify the process of enterprise application integration (EAI). By establishing a nonproprietary, universally accepted standard of communication between applications, Web services can succeed where other approaches have struggled. With Web services, organizations can integrate key applications without relying on costly, time-consuming, proprietary, and maintenance-intensive solutions. That said, Web services alone are not in and of themselves a complete integration platform, but rather merely the enabling standards. As a result, Web services cannot serve as a complete substitute for an EAI platform in many cases. With robust management solutions, however, Web services are evolving to complement and strengthen traditional EAI methodologies, making integration projects less time consuming, inflexible, and costly.

Problems with Integration Projects Persist
Most integration projects fail. A recent Forrester Research report stated that almost 65% of EAI projects run behind schedule and are significantly over budget. On average, the cost is approximately $6.4 million per project by the time the smoke clears. In general, application integration is a far longer and more expensive proposition than the outcome seems to justify.

Change management is perhaps the greatest source of pain with EAI initiatives. With conflicts in data message definitions or mismatches in proprietary components, a change to either side of a set of integrated systems necessitates a cumbersome and often costly change implementation process. The unintended result of this situation is the creation of a "job for life" for a developer with specialized EAI package skills. When combined with the obligation to pay recurring maintenance fees on proprietary packages and buy add-on EAI components as systems grow and change, an EAI project can create a long-term maintenance overhead that is untenable.

Long development and implementation timeframes are other factors that mitigate the effectiveness of EAI. The average project life cycle is 20 months. The time required to sort out political issues in the organization (a factor that can kill the integration project before it even begins), select the vendors, gather requirements, and then implement the solution, may take so long that the early goals of the program are obsolete by the time it is completed.

Whether the integration is done by a proprietary EAI package or through a custom development program, the result is usually an "island" of integration between two applications that will then be difficult or expensive to connect with other applications. When integration is then extended beyond the firewall, the issues become even more complex.

Figure 1 shows an example of poor EAI performance and high cost. With three "islands of integration," integrating between unconnected systems would be prohibitively expensive - and the cost of maintaining the islands is very high. Change management is complex, time-consuming, and costly. Bottom line: this EAI initiative is a costly trap with limited extensibility.

 

Figure 2 illustrates the missed opportunities for integration. Including systems outside the firewall and other internal systems, there are 12 potential connections that cannot be realized in this configuration.

 

The Immediate Impact of Web Services on EAI
Using the example in Figures 1 and 2, Web services can enable integration of the "islands" without any further proprietary or custom development. As shown in Figure 3, by exposing the key features of each application as a Web service, it becomes possible for the applications to exchange data and functions freely without the need for a proprietary or custom interface. The applications exchange messages in SOAP using Internet protocols that already exist in the enterprise infrastructure. Developers responsible for the integration can locate the required functionality using WSDL found in the UDDI. The Web services act as EDI-like components to extend EAI solutions outside the enterprise and into collaborative customer domains.

 

The Web services-based EAI system is extensible without requiring additional software licenses from a proprietary system. Change management is greatly simplified. Data integrity issues become easier to solve through the universality of the XML data exchange. And of course, it becomes easier to extend beyond the firewall because there is no longer an issue of communication or procedure call standards.

Ultimately, Web services act as building blocks for a "virtual application" built using orchestrated Web service components. This is a departure from the old way of building distributed or monolithic applications in that it explicitly allows for reuse while maintaining a distributed, scalable architecture and standardized components.

Solving Some Problems, but Causing Others
Web services are easier to design, implement, and deploy than any other traditional distributed technology. Web services can span their influence by easily exposing and integrating the services on the Web. The rationale behind Web services is to divide and conquer large business problems into small services. Each service addresses a specific business need; therefore, the integration of these small services solves the larger business problems at hand.

There is no need to own the implementation of a service purchased through only one solution provider, as you may discover services and orchestrate them into agile business processes regardless of the underlying platform.

Promising as they are, however, Web services are no panacea for integration challenges. Making Web services serve the complex needs of EAI in a real-world enterprise requires solving a number of challenges (see Figure 4):

 

1.   Security is a significant problem in Web services if not managed correctly.
2.   Without management and monitoring, it is impossible to know how the Web services EAI infrastructure is operating, or in fact if it is operating at all.
3.   Web services must be able to travel across multiple messaging protocols such as HTTP and JMS.
4.   Enterprises that scale EAI projects using Web services will result in large networks of Web services. Those networks will have to be managed in terms of routing, fail-over, and load balancing. Furthermore, a deep UDDI will be required to keep track of all the critical metadata attached to each service in the network.
5.   EAI platforms remain important for transactionality and reliable transport.

Enterprises that intend to rely on Web services as a method for implementing critical business processes must prepare to manage those Web services by building, buying, or subscribing to a suitable Web Services Management (WSM) solution. Over time, WSM will become a critical part of any Web services strategy. Organizations will incorporate WSM into their enterprise architecture to take advantage of service orientation without losing reliability, scalability, and measurability. Although Web services technology provides the promise of seamless interoperability of disparate systems, just exposing business functionality as services is not only insufficient, but also dangerous. Only with comprehensive management can the full benefits of Web services in application integration be realized, and the risks mitigated.

The Future Impact
As standards become more stable and robust, and WSM solutions more common, Web services should move up the integration "value chain" to encompass more than just message transport and interconnect. In short order we will see the influence of Web services technology on higher-value business process management and business analytics applications (e.g., making it easier to share and incorporate business processes from outside trading partners and bringing the concept of the real-time enterprise closer to reality). Eventually, Web services also have the potential to mature and grow into a ubiquitous platform for core application development itself. We could see it breaking out of the integration box entirely, becoming as useful for constructing new applications as for integrating existing ones. Consider the following three types of Web services usage:

Type 1: Interoperability
Early use of deployed Web services was seen primarily as a form of middleware to integrate various applications across different platforms and development languages. During this phase of Web services experimentation, developers are "service-orienting" legacy business processes or transactions into components. These types of legacy processes, such as order processing, shipping status, or inventory queries, are natural targets for initial Web services deployments. The early focus on creating Web services from legacy systems shouldn't be surprising as legacy systems support most fundamental business processes in the world's largest organizations. Across the Fortune 500, somewhere around 70% of strategic applications still reside on legacy applications.

Type 2: Moving Up and Out:
B2B Integration
A major driver behind the Web services trend is that it facilitates integration beyond enterprise boundaries in situations where you lack control of the development platforms, languages, and middleware. This will highlight the expense and constraints of today's EDI, and usher in a new era of standards-based B2B transaction exchange.

Type 3: Enterprise Agility and Awareness: Application Orchestration and Cross-Process Analytics
Web services evolved to enable a hyper-efficient platform for application development via the orchestration of modular, loosely coupled pieces. Web services component assembly processes will begin to transform the way we design and build software, affecting programmatic and user interfaces. By using Web services-enabling tools, developers can increase their productivity by gaining integration-free, component-based access to distributed business functions. The clean separation of business logic from the user interface results in explosive value, freeing the business from the constraints of entrenched IT infrastructure while leveraging legacy investment. In this model, older applications are exposed via standards as "black boxes," the underlying platform is rendered irrelevant, and new applications roll out in a manner suited for seamless interoperability. These disparate services are orchestrated into virtual applications, each piece used and reused by different processes depending on the context.

Most important, the shift to a service-oriented architecture will enable true visibility and agility in the enterprise on a level that is unimagined today. The prohibitive cost of attaining true enterprise awareness has left most organizations running blind, making decisions based on incomplete or inaccurate views of their environment. Web services will soon become a competitive differentiator, allowing agile organizations to make better decisions faster, and change their processes in real time in response to an ever-shifting market opportunity.

Summary
In the future, a consultant helping a company implement a CRM system will be able to develop application user interfaces by applying workflows to a rich collection of preexisting Web services. This could be done at the speed of prototyping. In their purest form, Web services may not come to full fruition until late 2003 or 2004, but their influence is already being felt in IT shops across the globe. Today virtually 100% of organizations with $1 billion dollars in revenue or more have declared a loosely coupled, standards-based architecture their goal. Of that group, more than 70% have started to prepare for the transition to a distributed architectural framework and roll out initial Web services pilots. Within a few years, Web services will radically change the way we think about, design, build, deploy, and integrate business applications.

• Figure 1
• Figure 2
• Figure 3
• Figure 4