Flexible IT, better strategy

From the McKinsey Quarterly
Special to CNET News.com
January 24, 2004, 6:00 AM PST

Technology architecture is one subject guaranteed to make a chief executive's eyes glaze over.

For many CEOs, the topic is mysterious. Even for those who understand technology better, it is a sore subject because today's IT architectures, arcane as they may be, are the biggest roadblocks most companies face when making strategic moves.

Strategists have largely discredited classical notions of strategy formation. The empty biennial reviews of yesteryear are gone, superseded by "radical incrementalism," which emphasizes rapid waves of near-term (six- to 12-month) operational and organizational initiatives brought into focus by a shared view of a company's much longer-term (five- to 10-year) strategic direction. A quick sequence of focused incremental shifts can produce cumulative and radical change that isn't easy to copy. Radical incrementalism has helped companies such as Charles Schwab, Dell, Microsoft, and Wal-Mart Stores reshape industries and deliver superior returns to shareholders.

Yet radical incrementalism is notoriously difficult to accomplish. Operational shortcomings and organizational inertia hinder companies from making near-term innovations in business practice and process. Technology can be an even bigger hindrance--in part because it's so deeply embedded in operations and organization, in part because information systems are rigid.

This inflexibility is endemic today. Big suites of enterprise-wide applications like those in enterprise resource planning (ERP) suites, designed to integrate disparate corporate information systems, dominate client-server architectures. Unfortunately, the onetime, "big-bang," and tightly defined way in which these applications have been implemented, as well as their massive bodies of difficult-to-modify code, mean that enterprise applications integrate businesses only by limiting the freedom of executives.

Introducing a new product or service, adding a new channel partner, or targeting a new customer segment--any of these can present unforeseen costs, complexities, and delays in a business that runs enterprise applications. The expense and difficulty can be so great that some companies abandon new business initiatives rather than attempt one more change to their enterprise applications. Far from promoting aggressive near-term business initiatives, enterprise architectures stand in their way.

IT is on the verge of a shift to a new generation of "service oriented" architectures.

The good news is that just as the limitations of the current generation of IT architectures are becoming painfully apparent, new methods of organizing technology resources are appearing. IT is on the verge of a shift to a new generation of "service oriented" architectures that promise to go a long way toward reducing, if not removing, current obstacles to new operational initiatives. These new architectures are no panacea; technology in isolation has never created strategic value. But service-oriented architectures will enable companies to introduce new business practices and processes more rapidly and at lower cost. Such innovations will accumulate by increments into strategic advantage.

Service-oriented architectures don't require the removal of existing IT resources and in fact were developed specifically to help businesses get more value from them. These architectures are still in their early days, but companies such as Eastman Chemical, General Motors and Merrill Lynch have already begun to experiment with them. Companies that follow suit will break free from the constraints of today's architectures and become capable of leveraging IT--mostly for the first time--to gain strategic advantage.

The agony of customized connections
How are today's IT architectures an obstacle to more agile strategies? Let's consider the example of a company that produces and sells farm machinery. Senior management has looked ahead five to 10 years and decided that the best way for the company to continue creating value would be to evolve into a customer relationship business, thus deepening its ties with a clientele of large agribusinesses and serving a broader range of needs.

What can the company do during the next six to 12 months to accelerate this change in direction? Suppose it decides to focus on two initiatives. The first is intended to provide customers with better, more easily obtained information about the status of their orders--both to improve customer service and to reduce operating costs--since the company maintains a large order-processing staff to answer time-consuming customer inquiries. The second initiative aims to expand the company's range of products by allowing it to source and then resell some complementary ones from third-party manufacturers.

On the face of it, neither initiative seems particularly daunting. Let us say, however, that the company manufactures its products at three U.S. plants, two of them acquired from other companies. Since different companies owned the facilities, each of them uses different enterprise applications to run its operations. Employees checking on the status of orders therefore have to access three separate applications with very different user interfaces and ways of presenting product information. This problem explains why the order-entry staff spends so much time fielding queries.

What would be needed to make the information directly accessible to the purchasing systems of customers? For each of them, the company would have to create three custom-designed connections linking the customer's purchasing system with the enterprise suites of the three manufacturing plants--connections that would have to translate information for product descriptions, shipping instructions and status, and other key data. The custom connections should also provide for adequate security, transaction monitoring, and message routing.

Even if these needs were ignored, the connections would demand a deep understanding of the applications at either end and of the features specific to them. The connections would be not only expensive to create (because of the coding time required) but also unlikely to be reusable for anything other than their original purpose. Technologists aptly describe custom-designed connections as "hardwired," because they lack flexibility.

As for the second initiative, if the company wanted to resell third-party manufacturers' products and to give customers for them the same level of order-status information, it would need to create custom-designed connections between each customer and every supply chain application that its suppliers happened to run.

Even during the early deployment of the company's first initiative, its complexity, cost, and lead times would mount. If the company later wanted to enhance each of these connections--by giving customers a limited ability to modify orders before they were shipped, for example--that feature would have to be coded into every customized connection. Suppose too that some of the company's first product suppliers didn't work out and had to be replaced. It would then have to create entirely new connections. The more business conditions changed, the greater the complexity, the cost, and the lead times.

Under today's information architectures, if you need to connect two applications, databases, or operating systems--or to connect any of these to human beings--each connection must be specially created for its specific purpose, and even the smallest modification requires it to be recoded. Worse yet, the expense and effort needed to establish connections across technology resources increase exponentially--not linearly--with the number of resources connected. Small wonder that companies spend large portions of their IT budgets on integration as they create new connections and redesign old ones to keep up with changing business conditions.

Creating new kinds of connections
Service-oriented architectures take a different approach to connecting technology resources. Instead of customized, hardwired connections, these architectures rely on "loosely coupled" ones in which IT resources, even if they use incompatible operating systems or different vocabularies in their own operations, can be joined together easily without friction or customization and just as easily disassembled and reassembled. (Of course, this assumes that all participants have agreed on a standardized vocabulary to serve as a common translation overlay.)

All of the information required (for instance, which outputs the software can deliver, how they are accessed, and who is authorized to do so) is described and contained in the interface?the electronic description that other applications use to find out how to establish an electronic connection. At the farm-machinery company, the interface to the manufacturing application might specify that it could provide information on a product's manufacturing status and indicate what protocols and standards the "service's" user (another piece of software) would need to access the information.

Unless the standards and protocols are widely adopted, the range of feasible connections is very limited.

Of course, the information must be presented in a way that is broadly understandable, and this is the key role that standards and protocols play in supporting loosely coupled connections. Unless the standards and protocols are widely adopted, the range of feasible connections is very limited. The rapid spread of the Extensible Markup Language (XML) as a foundation standard, and the whole series of standards and protocols derived from it, provide an effective framework for broadly understandable and accessible interfaces.

Much more flexible connections can be established once the standards and protocols are in place. Since computers can "read" and understand them, connections can be automatically created as the need arises. The connection focuses on the service's output rather than on the details of how it is generated. Thus, connections can be established much more quickly, without requiring a deep understanding of the underlying features at each end of the connection.

In effect, service-oriented architectures embody a modular approach to organizing IT resources. As with all such approaches, the key requirements are standardized definitions of interfaces so that different technology resources become self-describing, which allows them to be mixed and matched quickly and easily to meet the requirements of the moment. As new operational initiatives are launched, appropriate applications and information resources are accessed dynamically to support those changes.

Business benefits
To understand the full benefits of service-oriented architectures, let's turn again to the farm-machinery manufacturer. How would such an architecture help it achieve the near-term operating flexibility required for radical incrementalism and other new approaches to strategy?

The architecture would expose, or make visible to other applications, the features and capabilities of each of the company's supply chain management applications. The company's IT department would accomplish this by creating a standardized interface allowing, say, an order's status to be available as a service that could be shared by any application using the same standards and protocols.

Access would come through a loosely coupled connection established only "on the fly" when needed, because all of the necessary information would already exist in the service interfaces. If the consuming application (in this case, the customer's procurement software) didn't already know which manufacturing plant to query for an order's status, a directory service could help identify the appropriate services. A variety of enabling services of this kind could be delivered as loosely coupled services shared across all connections rather than designed into each of them in advance.

The advantages are significant. Traditional approaches require programmers to design a customized new connection in advance for each pair of resources that might need to interact. A service-oriented architecture requires only a onetime investment to write code that allows the service to be accessed by any application with an interface adhering to the same widely available standards and protocols, such as XML and the Web Services Description Language (WSDL).

For more insight, go to the McKinsey Quarterly Web site.

Interested in more research studies like these? If so, free registration at The McKinsey Quarterly will offer you topical alerts, monthly newsletters, and access to selected full-text articles. For premium membership, which offers full access to the McKinsey Quarterly site and the print edition, .