Business and IT managers at some leading companies have been working together to change the way information technology supports the enterprise. As a result, they have cut the cost of IT, made it easier to change the business, avoided the constraints of inflexible support systems, and increased the participation of business leaders in the management of IT.

As companies that binged on new IT systems during the late 1990s know, insufficient business involvement in IT programs can depress returns (see "What CEOs really think about IT"). To avoid repeating this mistake, business and IT managers are starting to gather IT systems into "domains"—sets of applications and databases that are managed as units for business reasons—instead of managing them on the applications level or organizing them by the types of computers and operating systems on which applications run.¹ A company might, for example, bring together the systems that contain customer information and rethink the links among them; in this way, it streamlines the tangle of interconnected systems, roots out duplication, and retires unneeded applications, thereby slashing its maintenance and development costs. IT employees find it easier to change or scale such systems and can thus support business changes more rapidly and less expensively. Moreover, the new approach eliminates a source of tension between the two cultures, business and IT.

The goal is to turn something that resembles a plate of spaghetti into a system of modular blocks with relatively few interconnections

By transforming the IT architecture in this evolutionary way—rather than tackling change by patching in systems individually or replacing whole areas in "big bangs"—companies make it possible for IT and the businesses it serves to learn how to work together through a series of small, clearly defined projects. These companies can also apply the savings they gain from one project to finance the next. A team of business and IT executives, basing its decisions on the company's current business needs and future strategy, defines the domains, identifies the systems to be grouped together, and specifies how they should communicate with one another. IT experts then deploy an integration backbone based on middleware technologies to establish the necessary connections. The goal is to turn something that resembles a plate of cooked spaghetti—with innumerable applications and databases dispersed across the architecture—into a system of modular and logical blocks with a minimum of interconnecting wires.

In a sense, this approach involves a "buy one, get one free" deal: you overhaul your IT architecture to cut costs and gain flexibility, and if you do it right you gain business ownership of IT in the bargain. In large companies, the process can take over two years to complete and have an up-front cost of more than $10 million. Nonetheless, any company hamstrung by an IT landscape that makes the cost of adding new applications prohibitively high should remap and transform its architecture, since doing so can slash the cost of integrating them by 60 to 70 percent in the medium term. A company should at least think about transforming its IT architecture if it faces any urgent business challenge—a strategic shift, the cross-border integration of business units, a merger, an acquisition, a divestiture—that must be addressed through IT support. Even companies that don't see information technology as a problem ought to consider the potential gains of readying themselves for future challenges.

Gulfs

The IT architecture is important to business leaders because it can promote—or obstruct—the launch of new processes, products, and channels. The problems caused by a poor IT architecture are particularly evident in sectors such as banking, logistics, and telecommunications, where IT is the musculature of the business. Many banks, for example, find that their IT units can't efficiently support multichannel offers, because products and channels are served by separate IT systems that communicate only to a limited extent. Business leaders in other IT-intensive industries, such as manufacturing and retailing, experience frustration because IT takes too long to make changes, their cost is too high, or they fail to deliver the expected features. Many such problems are rooted in the IT architecture.

This gulf between what business needs from that architecture and what IT departments can deliver without incurring huge development costs tends to exacerbate another well-known division, the one between people on the business and the IT sides of companies. Business executives, who often believe that IT managers neither understand their requirements nor deliver real value, don't like to commit good staff members to work on IT projects. With limited input from business, IT developers struggle to deliver the best systems they can, but from a technology rather than a business perspective.

For IT people, the architecture of information technology is a minefield. In most companies, IT units add new systems by patching them in, figuring out which other systems must be connected directly to them, and forging the links. Patching is fine when systems don't have to be connected to core applications or databases. But where such connections are necessary, a typical IT department usually pays too little attention to making the new system and its interconnections fit in with the overall IT landscape, because doing so costs time and money up front. As the company patches in more and more systems, their sheer accumulated complexity makes it increasingly difficult and costly to maintain, change, or scale them. Furthermore, since patching is just a quick technology fix, it neither requires nor promotes deeper involvement by business managers in the affairs of IT.

Some companies have tried to solve their architecture problems by replacing important parts of the landscape through big-bang implementations. This approach is exemplified by the installation of large enterprise-resource-planning systems: monolithic, integrated applications that replace a number of disparate ones, typically in the areas of human resources, operations, and accounting, or in the supply chain. Such big-bang efforts may be necessary at times—for example, when companies implement global accounting systems based on enterprise-resource-planning software—but should be avoided if at all possible. Throwing out old systems and the messy connections between them is tempting, but this is a costly, risky strategy that delivers mixed results and usually doesn't help narrow the gulf between business and IT. We have seen several cases in which the business side started out directing immensely complex programs only to become exasperated by time and budget overruns and then decided to delegate control to IT. As problems worsened, projects were canceled or left to wither.

So while it is high time many companies overhauled their IT architecture, it is equally important to bridge the divide between the cultures of business and IT. The good news is that companies can actually do both simultaneously (Exhibit 1).

Working together

Companies that have overhauled their IT architecture through the kind of managed evolution we recommend have achieved these two objectives. By "modularizing" a maze of legacy IT systems into logical and transparent business-driven domains, they make it possible for business managers to control the direction of information technology. The domains provide a foundation for business ownership of and accountability for IT.

This broad evolutionary methodology doesn't rely on random change or on risky big-bang revolutions, though it does permit the selected patching and focused replacement of obsolete systems. We believe that it is not only less risky but also more cost-efficient than the usual approaches because it starts by using existing assets and transforms them step-by-step. The trick is to win short-term benefits while creating a consistent IT landscape that is flexible enough to support evolving business needs without expensive overhauls.

Leading companies in many industries—including banking, energy, insurance, logistics, manufacturing, retailing, and telecommunications—have gone down this road, following a common process.

Assemble a mixed team

If IT people rethink the architecture from their operational perspective, they are likely to cut the domains along technological boundaries

Grouping applications and databases into business-driven domains and deciding how they should interface requires extensive knowledge of a company's business processes and potential strategies, so business leaders must take charge of this part of the project. Getting the job done by proxy—having IT experts interview the business leadership, as they sometimes do when designing applications to support business processes—just won't work. If IT people rethink the architecture from their own operational perspective, they are likely to cut the domains along technology boundaries.

Ideally, the team that tackles these issues should be set up, supported, and overseen by a board member—for instance, the chief operating officer (COO)—and include senior executives, managers of business units, and IT and process specialists. One retail bank, for example, formed a team consisting of business-unit managers, process specialists from the business units, IT managers, and senior IT architects. At a major logistics company, the overhaul of its IT architecture was initiated by the COO, who drove the project jointly with the chief information officer (CIO). The company's team (which included operations managers for various countries, network and hub operators, and IT architects) first defined the domains and the "rewiring" that would enable them to communicate and then determined the order in which new connections were created.

Define domains and services

Taking information technology strategy as the starting point, a company must ask what it wants from IT, assess its actual IT capabilities, and decide what direction it wishes to take. The team at the retail bank began by analyzing its business initiatives, current IT projects, business process blueprints, and IT applications and databases while bearing in mind some particularly urgent problems. The bank hoped, for example, to offer its products through several channels—branches, call centers, and the Internet. But its IT systems couldn't develop and use the same information and business processes across all of them simultaneously, because they had been created on a stand-alone basis with limited powers of communication.

The team looked for commonalities among the pieces of the IT puzzle—for instance, customer information needed by more than one product—and soon decided to reorganize the bank's systems into about half a dozen domains. These included a channel domain (with subdomains such as branches, the call center, and the Internet), a product domain (accounts, credits, payments), and a customer domain (sales support, customer information). All were relevant to the bank's multichannel offer.

Next the team arranged for the exchange of instructions and information among domains. IT specialists refer to such interfacing as "services" because they control the way different parts of the business serve one another. The bank's branch, call-center, and Internet subdomains, for example, needed a standard service enabling them to access any profile they needed from the new customer-information subdomain. They were duly able to do so simply by calling an "update customer information" service. Other bank services might include "track channel usage of customer" and "calculate product profitability" (Exhibit 2).

Services help companies to root out duplication, are available to all of the domains, and usually have to be implemented only once

Several hundred standardized business services can replace tens of thousands of tailored interfaces between applications and databases. These services offer important benefits to the business and IT sides alike: they must usually be implemented only once, are available to all domains, and help root out duplication, thus making it possible to reduce costs and complexity and to make businesses more flexible. Services "decouple" changes to the business from changes in technology, for although IT systems within a domain may have to be modified or replaced (as a result, for instance, of technological change or a merger), the services reflect stable business relationships between domains and usually remain the same. IT managers in a domain can therefore change an IT system without having to rewire hundreds of interfaces to other systems.

The impact of overhauling the IT architecture has been substantial for companies in a wide range of sectors. The retail bank cut its time to market by 30 percent and its development and maintenance costs by 10 to 20 percent. A European cable telephony operator overhauled its legacy IT landscape by creating invoicing and customer-information services that could be reused to support new products and succeeded in cutting their time to market from months to weeks. An Internet service provider that was spending 70 percent of its application-development budget to modify features and only 30 percent to develop actual products adopted the managed-evolution approach and is now well on its way to reversing those proportions. And an oil exploration company that transformed its IT architecture then found it relatively easy to combine its IT landscape and that of a company with which it merged; moreover, overall IT spending fell by considerably more than 30 percent.

Delegate ownership

Business leadership of IT can easily evolve into business ownership even as the first domains are being overhauled. In several companies, the working relationships forged during the early stages of projects to transform the IT architecture have been formalized in a new IT governance model balancing local and central control. In this dispensation, business managers have more direct responsibility for managing the domains and connections, while information technology managers continue to be responsible for providing IT support to domains and services.

One of the most interesting examples of this approach can be found at a global logistics company that overhauled its IT architecture after a merger, remapping its systems into a set of global domains such as production and customer integration. The top business manager most closely linked to a given domain is responsible for its architecture; the global head of operations, for example, chairs the cross-functional architecture steering group of the production domain. Its steering committee, which includes business and IT managers along with representatives from other functions whose domains interface with it, defined and developed the domain's IT landscape and interfaces.

At the central level, the COO (or sometimes the CFO) shares overall responsibility for the company's IT architecture with an architecture board that usually includes the CIO and other IT and business executives. The board manages relations between the business domains (for example, by brokering requests from the business managers of domains requiring services from other domains) and monitors the implementation and provisioning of services.

The next challenge is to make the transformation stick—and prevent any return to the bad old days

Business leaders are solidly in charge of IT decision making—the system of governance ensures that they continue to own IT decisions even after projects are well under way instead of delegating that task to IT. The CIO usually continues to have operational responsibility for the development of applications and their IT infrastructure and for managing the overall IT budget. But business managers and leaders have more control over the IT assets that directly affect their businesses and a far greater understanding of what it takes to manage, change, and invest in technology for business results.

The era of business ownership of IT is in its infancy. Some leading companies in a wide range of sectors have taken important steps down that road by managing the evolution of their IT architecture, and the results so far will surely encourage others to follow. The next challenge is to make the transformation stick—and to prevent a return to the bad old days of crossed wires between business and IT.