Prior to the development of Web services, many enterprises were faced with very complex and expensive integration projects that were intended to tie a variety of enterprise business applications together with the goal of providing a seamless integrated business application platform inside the enterprise. Today, enterprises are rethinking their approach to integration strategies now that they are seeing numerous successful cases where companies are moving forward with the use of Web services.

Although Web services are well on their way to success, enterprises continue to leverage the combined capabilities of enterprise application integration suites, message brokers, and data integration platforms to achieve everything from connecting the disparate applications together to building data warehouses in order to apply analytics and reporting to better understand the data collected in the various applications, whether they were packaged applications or custom built. Successes point to having teams of professionals with deep experiences and expertise on the technical side of integration technologies. The failures are primarily due to lack of expertise and unrealistic goals associated with integration projects. More important, the failures were due to the time-consuming and difficult processes in developing scalable and reliable integration projects that connected enterprise applications together.

Today, the new enterprise architecture is a real-time, service-oriented architecture that leverages open and widely adopted standards such as XML, SOAP, Java, and JCA. Nothing says that services should always be "Web services" based on common components, including XML, SOAP, and UDDI. Services can also be exposed as Java, JavaBeans, JSP, and .NET services.

The development and deployment of a service-oriented architecture is seen by many, including major research organizations like Gartner, as the next big thing. We are already experiencing the "early adopter" phase of the move toward this architecture, especially when it comes to integration. In fact, a recent industry survey indicated that integrating systems and processes is enterprises' most strategic IT priority. As standards mature and IT organizations gain experience with these new standards, we will move into the mainstream. This is not some overnight phenomenon; it will take time, as did the adoption of client/server computing. We will likely see this approach really accelerate over the course of the next year based on the number of early adopters seeing success with their efforts around Web services.

Standards
With Web services standards quickly maturing, enterprises are seeing early signs of a much simpler means for being able to orchestrate business processes across both operational and decision support systems. With interfaces in enterprise business applications exposed as Web services, the norm will be to orchestrate and integrate services exposed in both operational and decision support systems using enterprise business process managers. Enterprises will need a "service-oriented integration platform" that simplifies the process of integrating the services deployed within service-oriented architectures to achieve this goal.

The vision of many enterprise integration vendors is to be the standard service-oriented integration platform provider for the enterprise. In fact, it is a large opportunity for many of these vendors to extend their leadership in the integration market. A recent ZapThink survey indicates that the market opportunity will be about $6.2 billion by 2006. Already most of the major integration vendors have made strong progress in adapting standards like XML, SOAP, Java, and JCA to their platforms. This approach enables them to extend their platforms to achieve a service-oriented integration platform. Enterprises pursuing service-oriented architectures must now steer clear of any integration offering that lacks support for Web services as it is considered required functionality in an integration vendor's offering.

Beyond helping with integration, how can you justify building a service-oriented architecture? One of the key motivations for leveraging a Web services-based, service-oriented IT architecture is to help the enterprise reduce latency in their business operations in order to become what many call a real-time enterprise. Pursuing this strategy will enable the enterprise to build better relationships with customers and business partners, eliminate process bottlenecks, streamline business processes, and leverage real-time critical data to better predict and optimize the key metrics in their business.

An Example for the Future
What business would not like to achieve these goals? One of my favorite examples of a company that will benefit from a service-oriented approach is Kinko's. In a recent announcement, Kinko's said that in the future it will expose a Kinko's printing service as a Web service to Microsoft Word users. With the Kinko's service enabled, it is envisioned that Word users, choosing the print command, would get the standard print dialog, but in addition to seeing all the printers the user would also see a "Print at Kinko's" option. Selecting the service would then allow users to pick the Kinko's closest to their physical location to have the job printed. I'm sure that a message would travel back to the user indicating that the print job was complete and ready to be picked up. Who knows, may be even a map from MapQuest will be displayed showing the exact Kinko's location. Imagine how, by taking this approach, Kinko's could expand their business model by making it convenient for their customers to use this service.

Expanding the concept further, imagine Kinko's interacting with Federal Express when the user simply sends a list of mail addresses to the Kinko's service to request that the final print jobs be sent to Federal Express for delivery to the specific addresses. This is quite visionary on behalf of Kinko's. With success and good user adoption, this service could serve as a "poster child" to demonstrate how, by taking a service-oriented approach to their business, Kinko's can better service their customers and further expand their business visibility.

Spurred by such visions, many enterprises are now moving their business IT infrastructure to a service-oriented architecture to help achieve these goals. That's the good news. The bad news is that it will take time and effort and an investment to retrofit existing systems with services-oriented interfaces. One obstacle preventing some from moving forward is a concern for where standards are going. Other enterprises have overcome these concerns as they actively monitor standards efforts, even to the point of participating in the standards bodies.

Both business and industry are encouraged by the progress of these standards as they become more mature. This is showcased by the efforts of the Web Services Interoperability Organization (WS-I), which describes itself as an open industry effort chartered to promote Web services interoperability across platforms, applications, and programming languages. It brings together a diverse community of Web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable Web services. Most of the major enterprise application vendors now actively participate in this effort. These efforts will go far in helping enterprises achieve a service-oriented architecture leveraging Web services as the primary vehicle for integration of enterprise business applications. With this in mind, another strategy on the path to a service-oriented architecture is to become actively engaged in organizations like WS-I. At this writing, the WS-I is underrepresented by the Global 3000 enterprises. Strategically, enterprises should consider joining organizations like the WS-I. This will go far in helping architects inside the enterprise to gain considerable insight and develop a great network of very smart technologists and strategists who will be invaluable when it comes to pursuing a service-oriented architecture using Web services.

Industry Leaders
Actively engaged in standards efforts and moving forward with service-oriented architectures are the industry-leading packaged business application vendors, including Siebel, SAP, Microsoft, and PeopleSoft. These companies are moving in this direction to help enterprises achieve the benefits of the service-oriented architecture. In addition, many vendors are promoting strategies and solutions to help enterprises integrate their offerings with other packaged and custom applications through the use of Web services as a primary enabling technology in their offerings.

Siebel Systems
One of the most highly visible efforts by an enterprise application vendor today is Siebel Systems. Siebel is investing over $100 million in a project called Siebel Universal Application Network (UAN). By taking a very services-oriented approach to UAN, Siebel can provide a model for how enterprises can rapidly connect both Siebel and non-Siebel business applications. Siebel UAN takes a process-centric approach to integrating applications. In fact, Siebel provides a library of prepackaged cross-industry and industry-specific business processes, such as quote to cash, campaign to lead, and others, that form the heart of Siebel UAN.

Siebel is unique in their approach as they are providing a framework (process, common objects, and transformations) that can be used by any integration vendor that supports UAN. Other application vendors will either work independently of the integration vendors or build their own integration stack. SAP is one vendor that has built their service-oriented integration stack but also works with integration vendors.

Siebel does not provide a native integration server as part of UAN. Instead, they defined all of the business processes using the BPEL4WS (Business Process Execution Language for Web Services) standard. With the processes defined in BPEL4WS, Siebel is promoting an "integration server-neutral model" for its business processes and has teamed up with integration vendors including SeeBeyond, TIBCO, Vitria, IBM, and Microsoft to help ensure that enterprises that have adopted these integration brokers can leverage the capabilities of UAN.

Although UAN has a strong vision, Siebel is just getting started. Enterprises that use Siebel will want to investigate the capabilities of UAN and determine how it might fit into their service-oriented architecture. Integration brokers supporting UAN are also in the early phases of adoption. For example, many of the integration brokers don't have native support for BPEL4WS and will probably resort to importers and exporters to bring the defined processes into their integration broker business process environment. (Part of the reason for this approach is that some believe that BPEL4WS may go through further changes or be incorporated as part of a superset standard. It is hard to predict where the BPEL4WS standard will go.) Because Siebel is in its early stages with UAN, they offer only a limited number of predefined processes. With this limited number, many enterprises might want to take a wait-and-see approach until UAN matures further.

One other obstacle Siebel is likely to encounter is the wide range of custom scenarios required by the enterprises adopting Siebel. We live in a world of heterogeneous systems and customized packaged applications. This will require enterprises to adopt UAN to take a path of customizing UAN. Although Siebel has done a good job in defining common business objects like customer, employee, product, and order, not all enterprises will be able to directly align with these objects and in fact will likely have to customize these base objects to more directly align to their business requirements. The good news is that Siebel does provide an object base to get started. They also support customization of these objects, which gives us a sense that Siebel understands the issues of customization required in an enterprise.

Due to the highly competitive nature of the packaged enterprise application space, Siebel will face challenges when selling UAN in a world of heterogeneous applications, including SAP and PeopleSoft. Both companies have competitive solutions and a battle has already begun for enterprise mind share. Certainly SAP and PeopleSoft will be pushing their UAN-like approach over Siebel.

SAP
Competing directly with Siebel UAN is SAP's NetWeaver platform. According to SAP, "SAP NetWeaver is the foundation of SAP xApps and mySAP Business Suite solutions. It's also the enabler of SAP Enterprise Services Architecture, which combines the enterprise applications experience of SAP with the flexibility of Web services and open technologies - for complete and services-based business solutions." When you peer into NetWeaver you unveil a very comprehensive service-oriented architecture that leverages the capabilities of open standards and Web services. NetWeaver claims to "provide all the capabilities that an integration and applications platform requires to develop, integrate, and run solutions following SAP Enterprise Services Architecture."

Part of the SAP NetWeaver offering is the SAP Exchange Infrastructure, which includes an integration broker that enables XML/SOAP interactions between services exposed by various vendors' source systems. The SAP Exchange Infrastructure also supports a business process manager, which enables an enterprise to model and execute business processes within a service-oriented architecture.

Although deep in its functionality, SAP also understands that organizations will have existing integration solutions in place. With this in mind, SAP exposes services in NetWeaver that are accessible for other integration broker solutions. Enterprises, however, may adopt NetWeaver components alongside these integration brokers with the assumption that they will avoid having to work with multiple vendors. It isn't unusual for an enterprise to support multiple integration brokers. In fact, Gartner predicts that more than 67% of large enterprises will have two or more different integration brokers in production by year-end 2003, and half will have four or more by year-end 2005 (0.7 probability).

PeopleSoft
Right up there with UAN and NetWeaver is PeopleSoft with their AppConnect and PeopleSoft Internet Architecture. The PeopleSoft AppConnect product suites include an enterprise-class portal, a standards-based integration broker, and an enterprise warehouse. The primary communication mechanism for PeopleSoft AppConnect is Web services. Like SAP, PeopleSoft works closely with integration broker vendors such as Vitria and SeeBeyond with the understanding that enterprises will want to ensure that these integration brokers are "certified" to interoperate with PeopleSoft's offerings. With this in mind, PeopleSoft as well as Siebel and SAP have certification processes that validate that the integration broker is a "good citizen" in interoperating with the particular vendors' offerings. PeopleSoft delivers Web services-based integration by exposing Web services so that PeopleSoft applications can invoke services in other systems. In addition, systems can easily invoke PeopleSoft Web services from other systems to access content and data in PeopleSoft applications. PeopleSoft also supports messaging in their offering, where third-party systems can initiate services in PeopleSoft and subscribe to messages by using baseline Internet technologies inherent in the PeopleSoft Internet architecture.

Integration vendors will also vie for the position of controlling the enterprise standard for service-oriented integration inside an enterprise. Although most enterprises' application vendors have integration capabilities built in, many take an integration server-agnostic approach to their integration strategy and have attracted the major integration vendors into their appropriate camps. Most integration vendors see the value of "cooperating" with these vendors as the vendors give them tremendous visibility into a very large base of enterprise customers. The problem with this approach is that integration server vendors now claim that they are the standard for these solutions. I've seen this in action in public symposiums where several integration vendors have claimed that the enterprise application vendors themselves use their solution to build and test processes, giving their offering a strategic advantage over others. Many enterprise application vendors respond that they work with all the integration vendors' products to ensure the success of their solutions. With this in mind, enterprises must take this off the decision-making table as it brings little differentiation. What enterprises must look to is a proven track record of successful implementation using technologies like Siebel UAN, SAP NetWeaver, and PeopleSoft AppConnect that represents real-world scenarios.

Conclusion
With standards maturing, integration brokers supporting service-oriented architectures, and mainstream enterprise application vendors supporting Web services, all of these efforts are leading enterprises down a path where a service-oriented integration platform will become the norm over the course of the next few years. This services-oriented integration platform will help enterprises deliver the right data at the right time and will be an important key to achieving a real-time enterprise. As these efforts take shape and enterprises achieve success, we'll begin to see a fundamental shift in how enterprises integrate their applications. Business process will then be the key driver to help enterprises achieve real-time, cross-business application integration with Web services.

SIDE BAR

Key Strategies

1.   Investigate the benefits of taking a services-oriented approach to your next-generation architectures.
2.   Develop key value propositions and examples tailored to your business to showcase how the business will benefit from taking a service-oriented approach to your future architectures. Some of these value propositions will be streamlining latency in the business, reducing time and cost to integrate business applications, expanding the business model, and developing better customer relationships.
3.   Investigate the capabilities of your existing vendor's service-oriented offerings and ensure that they have existing or near-future capabilities.
4.   Identify early adopter candidates inside the enterprise that will quickly benefit by adopting a services oriented architecture.
5.   Establish processes for developing and deploying a service-oriented architecture.
6.   Develop cost/benefit analysis and if the results are positive move forward.
7.   Develop and deploy the service-oriented architecture in cooperation with your strategic vendors.
8.   Analyze and publish findings in order to gain support for moving forward with other candidates in the organization.