Why is it easier to meet these requests with Web services than with previous generations of technology? Two things come to mind: widely adopted industry standards and an unprecedented ability to harvest business content in real time.

Web services come with a set of Internet industry standards (see sidebar, page 51) that are gaining across-the-board acceptance throughout the IT community. These standards are promoting a dramatic growth in Web services built from scratch, applications outfitted with Web services interfaces, partners' Web services, and the emerging hosted Web services available for lease. They are also enabling businesses to easily tie together Web services-based applications regardless of platform, development environment, or physical location. The results are powerful, federated, heterogeneous business systems that span organizational boundaries and provide a more comprehensive and timely record of the state of the business.

Before the advent of Web services, it was difficult - if not impossible - to harvest real-time business content unless the application had been specifically coded to provide that information. Runtime systems-management tools could observe system-level information such as the number of messages, throughput, queues, failures, speeds, and response rates. However, these tools provided no visibility into the content of the messages, such as the dollar value of an order. Web services-based applications, by contrast, can unlock access to rich payloads of information - such as the source and destination of the data, information on the person requesting the data, and the quantitative business information itself. By accessing this type of real-time information, organizations can not only address security and service issues, but can also realize new opportunities for business success.

Accessing Real-Time Business Content
As organizations run more of their business functions on Web services-based systems, they can gather real-time information about usage patterns and business content by examining the messages passed among Web services. Since these messages are written in XML, even when communicating among Web services built with different tools they provide a standard, structured format for accessing business content. This content can be accessed as messages pass into (or out of) any Web service. The standardized format makes it easier to collect business information at multiple points in the business process and easily aggregate data elements into meaningful business information.

Theoretically, real-time business information can be gathered by looking within the Web services themselves, but this approach presents several difficulties. First, it's not always easy - or even possible - to instrument the internals of a Web service in order to collect a specific piece of business data. This is certainly the case with fast-breaking business opportunities that do not allow enough time for extensive recoding. Second, an IT organization may not have access to the internal workings of a Web service. This is most often the case with a packaged application that presents a Web service interface. (According to a recent report by Forrester Research, Inc., most major commercial applications will have a SOAP interface by the end of 2002.) Third, many organizations consume external Web services that are beyond their control, such as Web services they lease or Web services they consume from partners. For example, an organization may access data from an external shipping company whose Web service they cannot reconfigure. In all of these cases, it would be very difficult to access information from within a Web service itself. In each case, however, it remains relatively simple to monitor the XML messages that are passed among such Web services.

XML is a highly structured format for data interchange. Both requests and replies contain "tags" for the delivered data. These tags can be read as a way of gathering meaningful, real-time business information and applying it in ways never before possible.

For example, say a company uses an XML Web service for order processing. A business manager may want to be notified when one of his preferred customers places an order of 1 million dollars or more. He may want to give priority to filling such orders, even if it means giving a retroactive back-order notice to a lower-priority customer. Traditionally, this capability was either pre-coded into an application or the business manager had to wait to collect this information after the fact through summary reports or a data warehouse. Organizations deploying Web services can employ a new, more powerful model. They can quickly instrument their Web services-based systems to check the business content of each request - or selected requests - to gain insight into and provide immediate notification of new or emerging conditions that are important to their operations.

Combining Content with Context
In addition to making use of business content (such as order size), Web services systems can leverage contextual information - who's requesting the data, what are his or her access rights, and what type of client device is that person using, to name a few examples. When the user is authenticated through a security system, the Web service might call an LDAP directory for a complete user profile, including user identity, roles, preferences, and access policies, and can apply this information accordingly.

Content and context form a powerful combination. A Web service can use both types of data to adapt and reconfigure itself on the fly to ensure appropriate access to the immediate audience. Say a company has a Web service that tracks "Total Parts Ordered." It can make the application available to different types of users, each with its own requirements and restrictions. A customer might be allowed to look up the real-time status of his or her order, but no one else's. An operations manager might be allowed to track a complete record of all orders, backlogs, and shipments. A business analyst might correlate information on orders with cost of goods sold in order to understand profit contribution. A sales manager might use the same Web service to compile a regional sales report.

By using the message content in conjunction with its context, a Web services system can make XML Web services far more responsive to specific business requirements than previous generations of applications ever could.

Business Examples
The following are just a few examples of how access to the content of XML messages can add business value.

Content-Based Security
Security is the number-one concern for IT managers considering Web services. The thinking goes, if Web services allow access to anyone, what's to keep everyone from getting at business-critical data? The ability to implement content-based security should stem such concerns.

The more abundant the contextual data, the greater the opportunity for access control. By using profile data in conjunction with business content, a business system can grant user-specific, content-specific read and/or write access to a Web service. By interacting with the existing authentication system, it can dynamically tailor responses based on each user's most current security profile and the context of the request.

Here's an example. A company employing a human resources Web service can conceal salary information for all employees of an equal or higher rank than the requestor. Leveraging both context (profile information) and content (salary information), the company can secure inappropriate data on a content-specific level.

Evaluating and Maintaining Service-Level Agreements
It's necessary to track the content and performance of Web services in order to set and maintain service levels. Consumers need to verify that they're getting the service levels they requested or paid for. From a Web service producer's standpoint, it's necessary to track operations to ensure that acceptable levels of service are met. In addition, producers must be prepared to make hard choices. For example, given limited resources, it may make good business sense to dedicate system use and inventories to the highest-value orders and most valuable customers.

Insight into Business Operations
Message-stream analysis enables business managers to identify new opportunities and understand consumption patterns. By seeing who's using various aspects of Web services and how the services are being used, the organization can gauge the effectiveness of its products and promotions, calculate the return on its investments, and more intelligently plan its IT roadmap.

Content-Based Alerts
Businesses need to know about fast-breaking, exceptional conditions. For example, a company launches a "while supplies last" marketing campaign. The program manager responsible for the campaign needs to know when inventories are depleted in order to handle the respondents whose requests cannot be fulfilled - ideally while the respondents are still online. Business managers also need to know about extraordinary conditions that might affect customer satisfaction so that they can deal proactively with them - before the customer complains. A Web services system can track the content of transactions in progress and send immediate alerts whenever appropriate.

Upgrading Online Systems
The traditional change control model calls for relatively infrequent system upgrades, perhaps quarterly or annually. With many older systems, upgrades were installed over a weekend or during a holiday because the system needed to be taken down. This model, of course, doesn't work in the era of Web services, where businesses need to be online 24 x 365 and where market changes are measured in days rather than months.

Fortunately, a new version of a Web service can be installed without taking the system down by simply redirecting messages from the old service to the new one. Such changes are transparent to Web services consuming data from the updated system. Moreover, by accessing the business context and content, changeovers can be done gradually and selectively. For example, lower priority customers placing smaller orders can be redirected to a new version of the Web service until it has been sufficiently "burned in." Once the new version is robust enough to handle all traffic, the old version can be de-installed without disrupting the system.

The Future Is Now
With all the talk of Web services as "the next big thing," it's easy to forget that they've already arrived. New Web services go into production every day. Many initial Web services implementations are integration projects inside the firewall. For instance, Citigroup used SOAP interfaces to join 200 different content and data feeds into a customizable portal for its bankers and brokers. Others are linking Web services outside the firewall. Lloyds TSB Commercial Finance accesses Graydon UK's credit service to provide real-time rate calculations for short-term loans against a borrower's accounts receivables. MedUnite uses Web services technologies to provide more than 130,000 healthcare offices with centralized access to data from hundreds of insurance providers. The list goes on.

As more and more organizations migrate from early Web services experiments to production-ready use, the number and magnitude of interconnected networks of applications will grow exponentially. Business-driving new combinations of data will result, elevating the role and worth of Web services to even greater heights. Backed by standards and bolstered by their use of content, Web services will raise the business value organizations harvest from their information systems.

The 90-Day Plan
As with any new technology, the best way to get a handle on the potential reward is to create a proof of concept (POC). With a well-devised POC, you can get a jump on the competition while minimizing risks.

Month One
Start by setting objectives and identifying opportunities to dynamically create new correlations from previously unrelated data sources. Form a task force comprising both business and IT professionals. Look at systems and subsystems in your environment and identify information pairings that can solve a real business need. Look for metrics with which to gauge the success of your POC.

Month Two
Develop your POC incrementally. The POC is a learning exercise, so don't over-architect it. Start with a relatively simple service and move forward in short iterations. You can always add more functionality later. By focusing your efforts on a single business need, you minimize costs and can then build on the knowledge you acquire. Incorporating a management layer early in the process can assist in measuring POC effectiveness.

Month Three
Measure as many quantifiable results as possible. Analyze the results - both system metrics and business content - and compare against the objectives you established at the outset of the project. If possible, use these metrics to estimate ROI for a production Web service. Use your findings to devise a Web services project plan.

SIDE BAR

Web Services Standards
Standards bodies and industry consortia such as W3C, WS-I, and OASIS have done well to guide and promote Web services standards. Here are some of the more widely adopted standards, to date: