Generally, business users have heard Microsoft's expansive promises of functional flexibility from Web services--and they want it. IT operations leaders, on the other hand, are realizing the many challenges involved in managing a Web-services-based architecture. This ranges from managing systems that exist on multiple servers across the Web (not all of which are inside the organization) to security concerns about what might be concealed in all the XML-based messages coming through corporate firewalls.

Despite these legitimate concerns, however, enterprises are already moving forward with Web services more quickly than expected. IT organizations must scramble to keep up, because the alternative will be business groups buying their own Web services servers themselves, recreating the chaos that ensued when business groups installed their own Web servers a few years ago. Web services will be business services with a standard technology foundation.

[an error occurred while processing this directive]

Application designers are also eager to exploit Web services. From their standpoint, Web services are simply another way to do remote procedure calls, made more flexible by the application of standards for the basic components of remote procedures: UDDI (Universal Description, Discovery, and Integration) for the directory to enable the application to locate the remote procedure; WSDL (Web Services Description Language--based on XML) to define the input and output language; SOAP (Simple Object Access Protocol) to invoke the remote procedures; and HTTP to provide the transport mechanism. From the developers' standpoint, Web services differ from Java APIs, Microsoft COM+, and even MQSeries on MVS only in their rigorous use of these standards and in the scope of the system envisioned.

Proto-Web services already exist and have been in use for two or more years. For instance, when a shipping department sends a package, it uses an application provided by the shipper--UPS, FedEx, Airborne Express, etc.--that automatically links with the shipper's Web site to schedule pickup and delivery. When the finance department wants to check a credit rating, it uses an application from one of the financial services companies (e.g., Dun & Bradstreet) that gets the latest rating information from a Web site. At home, individuals can feed their latest bank and credit card transactions and stock quotes directly from the Web sites of the financial services providers of their choice into their personal financial records, through either Quicken or Microsoft Money, at the click of a button. Another example is the way ADP handles payroll and financial services. "Users" have little or no awareness of underlying software or infrastructure. They can now "submit" this employee information over Web-based interfaces and receive reports on status via the Web.

Although these business and consumer "functional outsourcing" services are not based on the new Web services standards, they are examples of how Web services will work. We expect the companies providing these and similar services to revise the underlying software to incorporate Web services standards, and these will become the first public Web services. We do not expect the market to support a near-term explosion of new competitive Web services that Microsoft and other Web services promoters envision, nor do we believe users will be able to simply connect to any Web service they wish to at a particular moment. However, we expect Web services to be embedded into applications in such a way that users will not be conscious that they are connecting to a remote server. Therefore, the first time the network goes down, operations groups will get calls from users who do not understand why their application suddenly will not work.

The technical problems of managing Web services, as daunting as they might be, are not the most important issues.

"In the past six or seven years, I have seen only two IT organizations that are truly process-oriented," says Meta Group analyst Dan Vogel. "When companies move to a Web services model for internal as well as external functional integration, whether the IT organization has its process act together will become instantly apparent to everyone."

User action: Web services' potential value is too high for organizations to permit infrastructure and operational groups to block their use by the business. However, the IT organization should explain various process impacts, true costs, potential operational risks (e.g., dependencies on other businesses), and security and other exposures to business leaders, and let them decide if the rewards are greater than the risks.

When using Web services, IT groups must consider the "provider" processes/activities (e.g., change, problem, and configuration management; service desk processes; vendor management) and how they will impact user processes.

Who's calling the Web services shots at your company--business units or IT? TalkBack below or e-mail us with your thoughts.

Meta Group analysts Dale Kutnick, Val Sribar, Dan Vogel, Bruce Robertson, Daniel Sholler, and Hollis Bischoff contributed to this article. This article was first published by Meta on June 18, 2002.

Newsletters
	Tech Update Today eBusiness Update	Tech Update Weekly		All newsletters FAQ Manage my newsletters

[an error occurred while processing this directive]

[an error occurred while processing this directive]