Patterns in Web services projects: the future of enterprise integration – Real World Web Services
Andrew Astor
Having been endorsed by virtually every technology vendor on the planet, Web services are now evolving from “feature” to “fabric.” They are moving from the latest buzzword (hot new feature) to a mature and accepted technology (fabric of the technology landscape). The hype is fading; it’s no longer interesting to develop Web services simply as a proof of technology, or as an end in themselves.
This article is the first in a series that explores the use of Web services in real-world situations, with the purpose of identifying usage patterns. The idea behind the series is to help answer questions like: Where and how do Web services deliver value? Where might they be counter-indicated? What works? What doesn’t?
For the first time, there is enough data from real-world, business-driven projects to allow us to begin to recognize patterns. The data analyzed for this series is drawn from production Web services case studies culled from two sources:
* Sand Hill Group’s study, “The Web Services Derby” (see www.sandhill.com)
* webMethods customers employing Web service-based integration (WSBI)
Where possible, case studies are attributed to specific companies. However, in many cases, organizations requested anonymity, generally because their projects are not public and are considered competitive differentiators.
Project Objectives
In this article, I explore common objectives of Web services projects. In this context, “objectives” are project executives’ stated reasons as to the main purpose of the effort. Clearly, most projects are (or should be) undertaken to increase revenues, decrease costs, or improve customer satisfaction. Such high-level goals, though, are not what we’re investigating here. We’re attempting to categorize project success criteria into a more meaningful set of types or styles. We are looking for patterns of project objectives.
Four major project types emerged from the analysis. A few initiatives were too broad or too unique to categorize, but the vast majority–more than 60 of the 70 case studies reviewed–coalesced around the following four major themes:
* Real-time application interoperability
* Common business services
* Architectural agility
* Customer or partner self-service
Objective 1: Real-Time Application Integration
By far the most common project objective was real-time application integration of heterogeneous systems. This is the most fundamental reason for Web services projects. After all, the most basic premise behind Web services is to get applications to provide services to each other, typically in real time. And since it is a fact of life that every IT organization today is multiplatform, multivendor, and multilanguage, it isn’t surprising to find an increasing demand for real-time integration of heterogeneous business systems. (Note: The idea that integration is at the center of Web services should come as no surprise. Regular readers will have seen this author’s view expressed previously that Web services are the name given to a set of standards associated with integration. For more on this topic, see “From Subroutines to Web Services: An Evolutionary View–Beyond Client/Server Computing,” WSJ, Vol. 2, issue 2.)
Business drivers behind these projects were quite varied, but fell into a few key themes.
Single View of Data
A key motivator of application integration projects is the consolidation of data from multiple systems into a single view. For example, a major insurance carrier used Web services to unify its customer data from multiple systems to a single view for its sales and service staff. Similarly, a biotechnology manufacturer created a single global view of its inventory for procurement decision-making.
Business Process Automation and Acceleration
Web service-based integration (WSBI) projects are often undertaken to improve manual or batch-oriented business processes, or to tie together individual business processes that can be streamlined.
For example, the sales force of an athletic footwear manufacturer spent nearly 80% of their time with their smallest accounts, since these accounts did not have EDI capability and needed to place their orders manually. Using Web services, this company was able to expose order-processing capability to these smaller customers, freeing up the sales force for more profitable account management activities
In another example, an outsourced electronics manufacturer differentiated itself from its competition through process orchestration and differentiated services. They replaced their EDI systems with event-driven solutions such as real-time partner invoicing and delivery date forecasting.
Information Sharing and Collaboration
The need to share information instantly with branch offices, trading partners, and customers is another common theme within WSBI projects. At Infinity Pharmaceuticals, for example, hundreds of thousands of chemical compounds are evaluated regularly for their drug potential. As soon as one of these compounds is recognized as unpromising and no longer worth pursuing, other company systems are instantly informed, and the compound is dropped from further analysis everywhere.
In another example, a high-tech integrated communications manufacturer used a WSBI approach to collaborate with its partners to predict demand, and fed that information to collaborative inventory and ordering systems that enabled them to have the correct stock at the correct time.
Objective 2: Common Business Services
Another very common objective for Web services projects is to aggregate individual application capabilities into coarsely grained business services that are exposed for use by multiple systems. Businesses find this approach compelling for at least three reasons:
* It shields applications from each other’s complexities: A well-established interface is developed for each business service, and applications that use the service need not understand how it accomplishes its task.
* It promotes reuse: Since the services are defined in coarse, business terms, developers have an easier time locating them and understanding their purpose.
* It simplifies the technical environment: The number of connections between applications can be dramatically reduced, since each application communicates only with the common business service. If “n” is the number of applications, then the number of connections can be theoretically reduced from n-squared to n.
Common business service projects where multiple front-end systems need to access multiple back-end systems are very common. For example, at Future Electronics, a $2 billion distributor of electronic components, orders can arrive through several channels (e.g., e-mail, phone, Web), and these orders may need processing by several back-end systems as they arrive. It is both complex and expensive to develop these systems, and even more difficult to maintain them. To alleviate these difficulties, Future recently built a set of common Web services for the creation of all customer orders. Regardless of the channel through which the order is entered, the same set of services is used to create the order, and these services are responsible for navigating the required processing in back-end systems. In addition to the benefits listed above, this solution delivered the ability to know at any instant, in real time, the current order backlog in the system. The CIO’s comment: “How do you put a value on that?”
Objective 3: Architectural Agility
Another common purpose for many Web services projects is to develop an agile and responsive application infrastructure. Over time, most large organizations have built up a complex and inflexible systems infrastructure, made up of applications that were either built without regard for intersystem communications, or which were hard-wired to each other. This condition, coupled with the unprecedented pace of change in both business and technology today has led to a situation where required changes simply cannot be implemented quickly enough. Increasingly, many forward-thinking organizations are responding to this challenge by increasing their systems agility via Web service-enabled solutions.
Generally, the goal of these projects is to replace legacy infrastructures with a service-oriented framework. But such an effort cannot be done all at once, especially in large enterprises; there are simply too many systems that need to be changed. The most common approach is implemented in two phases. In the first, legacy applications are wrapped into a Web services framework and exposed in a single, unified manner, via clearly defined interfaces. Once this step is complete, the individual legacy systems are then replaced over time. Since their interfaces don’t change, the end user experience can be left unaffected.
In one example of an architectural agility project, a major retail banking institution sought to present a single face to its customers after acquiring another bank. The architectural team recognized that a complete merge of the two banks’ systems would take too long, and that the project risk of a “big bang” implementation approach was simply too high. Instead, they placed a “veneer” on their back-end systems, wrapping them in Web services and exposing them to a common front-end application. The Web service wrapper reconciled the interfaces of the two systems, exposing them to the front end in a common manner. To the customers, the bank appeared to have completely unified its systems. The bank is now working to merge its back-end systems, and to eliminate redundancy through application sunsetting.
In another financial services example, a large brokerage re-architected its infrastructure to be more responsive to rapidly changing market conditions and the frequent need to develop new products. Its margins were shrinking due to increased competition from discount brokerage houses, and this company decided to develop “integration agility”–the ability to quickly develop functionality that could not be offered with its old infrastructure. To achieve this, they organized their applications into elemental business services (using Web service technologies) that could be rapidly snapped together to provide flexible services to the business.
Objective 4: Self Service
Self service–for employees, partners, and customers–is the last pattern we will discuss. In these scenarios, companies improve their service levels, reduce costs, and/or increase revenue opportunities by exposing businesses beyond the normal application borders.
At NEC Electronics, a new system provides access to real-time inventory and production information collected from different plants. It consists of a Web portal and an integration framework that gives customers, partners, and even branch offices unprecedented, secure access to their data. Prior to the delivery of this system, wait times of several days were not uncommon.
Dun & Bradstreet uses a Web service-based application to give its customers access to its vast credit database. By embedding this access directly into their applications, customers automate their credit analysis process, dramatically reducing decision times. In addition, since access to D&B is embedded within the customer business process, alternative credit sources are more difficult to exploit, making D&B’s services the default approach. This can clearly have a positive impact on D&B’s revenues.
In a similar approach, a large logistics and transportation company has exposed its shipping and tracking capability to its customers via Web services, allowing customers to embed this access directly into their own applications. By becoming part of the customer’s system, this company’s ability to hold onto its customers may be enhanced.
Conclusion
As we review the patterns of project objectives identified in this article, it’s useful to note that none of them specifically required Web service technologies to implement. In almost every case, project executives were able to name at least one other technology that could have been used as an alternative. This raises the question then, “Why Web services?”
The answer lies in a point made earlier in the article: “Web services” is the name that has been given to the emerging standards associated with integration. Mature integration technologies are available for everything Web services deliver and more. Project objectives, then, are integration-oriented objectives that are not specific to Web service standards. Nevertheless, standards always win out in the end. They lower project costs, risk, and time to completion. It should therefore come as no surprise that Web services-based solutions are the only possible future for enterprise integration.
In my next “Web Services in the Real World,” I’ll explore the technical drivers behind the selection of Web service technologies for integration projects.
Author Bio
Andy Astor joined webMethods in 2002 as vice president for Enterprise Web Services and is responsible for driving the company’s Web services strategy and execution. Prior to joining webMethods, Andy was a vice president at D&B, where he led worldwide customer-facing products, including all Web- and Internet-based applications. His work at D&B also included the development and launch of one of the earliest commercial Web services. He is on the Editorial Advisory Board for Web Services Journal, and was IT Strategy track chair for the 2002 Web Services Edge conference in New York City. Andy holds a B.A. in mathematics from Clark University and an MBA from the Wharton School.
ANDY.ASTOR@WEBMETHODS.COM
COPYRIGHT 2003 Sys-Con Publications, Inc.
COPYRIGHT 2003 Gale Group
