Why Your IT Strategy Is Moving To the Web

10/29/2001

Companies have traditionally embraced proprietary, in-house information systems. Until now. As John Hagel III and John Seely Brown write in this Harvard Business Review excerpt, there are compelling reasons why smart companies have been switching to the latest Web services architecture. Among them: It's just plain more efficient and flexible.

by John Hagel and John Seely Brown

The Web services architecture is completely different [from an ERP environment]. Constructed on the Internet, it is an open rather than a proprietary architecture. Instead of building and maintaining unique internal systems, companies can rent the functionality they need—whether it's data storage, processing power, or specific applications—from outside service providers. Without getting too technical, the Web services architecture can be thought of as comprising three layers of technology. At the foundation are software standards and communication protocols, such as XML and SOAP, that allow information to be exchanged easily among different applications. These tools provide the common languages for Web services, enabling applications to connect freely to other applications and to read electronic messages from them. The standards dramatically simplify and streamline information management—you no longer have to write customized code whenever communication with a new application is needed.

The service grid, the middle layer of the architecture, builds upon the protocols and standards. Analogous to an electrical power grid, the service grid provides a set of shared utilities—from security to third-party auditing to billing and payment—that makes it possible to carry out mission-critical business functions and transactions over the Internet. In addition, the service grid encompasses a set of utilities, also usually supplied and managed by third parties, that facilitates the transport of messages (such as routing and filtering), the identification of available services (such as directories and brokers), and the assurance of reliability and consistency (such as monitoring and conflict resolution). In short, the service grid plays two key roles: helping Web services users and providers find and connect with one another, and creating trusted environments essential for carrying out mission-critical business activities. The role of the service grid cannot be overemphasized: A robust service grid is vital to accelerating and broadening the potential impact of Web services. Without it, Web services will remain relatively marginal to the enterprise.

Using Web services reduces the risk that companies will end up using obsolete technologies.

John Hagel III and John Seely Brown

The top layer of the architecture comprises a diverse array of application services, from credit card processing to production scheduling, that automate particular business functions. It is this top layer that, day to day, will be most visible to you, your employees, your customers, and your partners. Some application services will be proprietary to a particular company or group of companies, while others will be shared among all companies. In some cases, companies may develop their own application services and then choose to sell them on a subscription basis to other enterprises, creating new and potentially lucrative sources of revenue.

To illustrate how the architecture works, let's contrast the way a typical business activity—loan processing by a bank—would be carried out through a traditional proprietary architecture and the Web services architecture. Loan processing is a complex procedure requiring at least six steps (data gathering about an applicant, validation of data, credit scoring, risk analysis and pricing, underwriting, and closing) and involving interactions with a number of other institutions (checking an applicant's credit rating, verifying investment and loan balances, and so on). With a traditional IT architecture, the process is usually supported by one, very complicated application maintained by an individual bank; like a Swiss Army knife, the integrated application does a lot of things, but it may not do any of them particularly well. And since the costs of maintaining electronic connections with other institutions are high, requiring leased communication lines and expensive software to link different systems, the necessary interactions are often handled manually through phone calls and faxes. The process, in sum, is cumbersome, costly, and prone to errors.

With the Web services architecture, loan processing becomes much more flexible, automated, and efficient. Leased lines are replaced with the Internet, and open standards and protocols take the place of proprietary technologies. As a result, the bank can connect automatically with the most appropriate institution for each transaction, speeding up the entire process and reducing the need for manual work. And rather than maintain its own integrated loan-processing system, the bank can take a modular approach, using specialized Web services supplied by an array of providers. It can also shift easily among providers, using one service, say, for risk analysis of loans to restaurants and another for risk analysis of loans to hospitals. In other words, the bank will always be able to use the best tool for the job at hand; it will no longer have to compromise on performance to avoid the complexity of integrating proprietary applications.

Clearly, the Web services architecture offers important advantages over its predecessor. First, it represents a much more efficient way to manage information technology. By allowing companies to purchase only the functionality they need when they need it, the new architecture can substantially reduce investments in IT assets. And by shifting responsibility for maintaining systems to outside providers, it reduces the need for hiring numerous IT specialists, which itself has become a significant challenge for many companies. Using Web services also reduces the risk that companies will end up using obsolete technologies; third-party utilities and application providers will be required to offer the most up-to-date technologies in order to compete. Companies will no longer find themselves stuck with outdated or mediocre applications and hardware. The standardized, plug-and-play nature of such an architecture will also make it much easier for companies to outsource activities and processes whenever it makes economic sense.

Second, and perhaps more important, the Web services architecture supports more flexible collaboration, both among a company's own units and between a company and its business partners. When traditional information systems need to talk to each other, they do so through dedicated, point-to-point connections. For example, when a sales-force-management application needs to send information on closed sales to a payroll processing application for the computation of commissions, a programmer has to write a special piece of code—a connector—to allow the two systems to communicate. The problem with such point-to-point connections is that they are fixed and inflexible and, as they proliferate, become nightmares to manage. With the Web services architecture, tight couplings will be replaced with loose couplings. Because everyone will share the same standards for data description and connection protocols, applications will be able to talk freely with other applications, without costly reprogramming. This will make it much easier for companies to shift operations and partnerships in response to market or competitive stimuli. The loose-coupling approach of Web services also makes it an attractive option within an organization. CIOs can use the Web services architecture to more flexibly integrate the extraordinarily diverse set of applications and databases residing within most enterprises while at the same time making these resources available to business partners.

Until now, what's been called e-business has for the most part been a primitive patchwork of old technologies. Most companies that do business on the Internet have had to yoke together existing systems with new ones to create the illusion of integration. A visitor using a corporate Web site may think it's a single, streamlined system, but behind the scenes, people are often manually taking information from one application and entering it into another. Such swivel chair networks, as they have come to be known, are inefficient, slow, and mistake ridden. Merrill Lynch, like almost all large companies, has struggled to patch together hundreds of different applications to support its sites for customers. John McKinley, the company's CTO, draws an analogy to the Potemkin villages in czarist Russia, where brightly painted facades hid the unseemly reality of run-down homes. The Web services architecture promises to solve this problem. Taking the people out of the network, the architecture will enable connections between applications—both within and across enterprises—to be managed automatically.

Excerpted with permission from "Your Next IT Strategy," Harvard Business Review, Vol. 79, No. 9, October 2001.

John Hagel III is the chief strategy officer of 12 Entrepreneuring, an operating company in San Francisco. He can be reached at jhagel@12.com.

John Seely Brown is the chief innovation officer of 12 Entrepreneuring, where he developed the perspectives in this article, and he also serves as the chief scientist of Xerox. He can be reached at jsb@12.com.

Five Questions You Need to Ask

Senior managers need to ensure that their organizations' executives are thinking ahead about the implications of the Web services architecture. Here are five questions you can use to spur your people:

Does our management team have a shared vision of the long-term (five to ten years out) business implications of the new IT architecture?

Do we have transition plans that balances the state of the architecture's development with a clear understanding of the areas of highest business impact?

Are we moving fast enough today to build our expertise and exploit immediate opportunities for streamlining intercompany processes, outsourcing activities in which we don't have distinctive capabilities and designing Web services that we can market to other companies?

Do we have a clear understanding of the obstacles within our organization that may hinder us from exploiting the full value of the new IT architecture, and do we have initiatives underway to overcome these obstacles?

Are we exerting sufficient leadership in shaping both the functionality offered by providers of Web services (defining, for example, the performance levels required for mission-critical applications) and the standards needed to collaborate with our partners?

Excerpted with permission from "Your Next IT Strategy," Harvard Business Review, Vol. 79, No. 9, October 2001.