Insights & Publications

Article

IT architecture: Cutting costs and complexity

A joint effort by IT and business leaders can help companies not only to save money but also to prepare for the return of growth.

August 2009 | byJanaki Akella, Helge Buckow, and Stéphane Rey

Amid the economic downturn, companies are searching for every opportunity to cut costs. IT represents an important part of total spending—5 percent or more in some industries—and its direct contribution to revenues and profits is often difficult to assess. As an unsurprising result, many CEOs and CFOs are eager to squeeze their CIOs’ budgets.

But finding substantial savings isn’t easy. Many CIOs have already spent years reducing costs in operations, procurement, and outside services. Among many other things, they have consolidated data centers and help desks, virtualized servers instead of buying more expensive new ones, rationalized procurement processes, postponed upgrades, and outsourced services to less expensive offshore providers.

Nonetheless, significant additional reductions and efficiencies are possible if companies take a broader look at the way they manage the IT architecture as a whole. The key to these economies is bringing business and IT leaders together in a combined effort to rationalize not only business applications and processes but also the core IT infrastructure and operations. At one large consumer products company, for example, such a joint initiative to combine, consolidate, and rationalize disparate IT systems across business units led to a drastic reduction in the size of the IT staff (by more than 50 percent in the application-management area) and inventories of spare parts, increased leverage in negotiating discounts with suppliers, and the faster completion of new IT initiatives.

The complexities of IT architecture

The IT architecture of a company is a formal description of its business operations (processes and functions), the business applications and databases that support them, and the equipment and services that run the applications. A complete IT architecture has six layers (Exhibit 1). In the best cases, companies codify it in a compendium—a blue book—that details the workings of the six layers, as well as the processes, roles, and responsibilities for managing the whole. This document should also provide a road map and rules to guide upgrades and additions.

Exhibit 1

Mapping IT architecture

An IT architecture has six layers.

Most companies have an IT architecture, but few control it. Instead, it grows organically, and the result is often duplicated systems, proliferating and inconsistent data, and makeshift integration. To make matters still more complicated, at most large companies, even within divisions, many IT initiatives are driven as much by short-term business wants and needs as by any long-term blueprint. That operational reality is especially evident for applications software and the business processes it supports. Such software is usually designed and deployed to suit the needs of one division or business unit, with relatively little regard for the impact on a company’s overall IT architecture.

CIOs at the corporate or division level generally do have substantial control over the core IT infrastructure components: servers, storage systems, and the associated infrastructure software. But the business applications, processes, and business model sitting atop the IT infrastructure often reflect the wants of the leaders of business units and functions, who understandably focus more on their own needs than on overall IT efficiency. Across a global company, the result is often an unwieldy, heterogeneous IT environment where incompatible (and often duplicative) hardware, applications, and processes sprout year by year, in every corner of the organization, in response to specific near-term needs.

At a large financial-services company, for example, we recently found seven different payments systems with 20 custom-built applications, which mostly undertook the same functions for purposes such as payroll, taxes, and suppliers. The company had gradually created the systems and applications to meet its major needs, and the outcome was a complex, inefficient, and expensive operation. The IT architecture team had little influence over many ongoing IT projects, so only a small fraction of them were fully in line with corporate standards and guidelines.

Similar inefficiencies characterize the IT operations of companies in every industry. These patchwork systems require substantially more time and money for development, support, and maintenance—at the expense of budgets, new IT capabilities, and business innovation. At large companies, eliminating these duplications and inefficiencies can reduce IT spending by tens or hundreds of millions of dollars while improving the quality of the IT operation and the satisfaction of those who rely on it. The CIO alone, however, cannot reduce these costs; business leaders too must sponsor and participate in the transformation.

Reducing costs and complexity: An integrated architectural approach

Today’s global economic crisis has created a golden opportunity to make order-of-magnitude reductions in IT costs by modifying the corporate IT architecture. What’s needed is a clearly defined IT blueprint with organization-wide guidelines for the most appropriate and efficient systems, applications, and processes. Developing and enforcing these guidelines helps companies to create a consistent and standardized infrastructure and to minimize unnecessary complexity, duplication, and costs (Exhibit 2).

Exhibit 2

A clean-system landscape

A clearly defined IT blueprint with company-wide guidelines promotes consistency and standardization.

That’s why CEOs must engage a cross-company team of business unit and IT leaders in a no-holds-barred program of architectural review and transformation. We have found that a phased joint approach, focused on a series of cost reduction levers, can reveal and realize substantial savings far beyond the norm for IT-only initiatives. In fact, companies that take this route can also create more flexible and efficient architectures that will help them thrive when the downturn ends.

To create an efficient IT architecture, business leaders and the CIO must jointly evaluate the business requirements and processes that underlie the existing architecture and then explore more efficient alternatives; without a high degree of collaboration, companies probably won’t adhere to even the best architectural designs. In our experience, the right starting point is a high-level business–IT task force that provides cross-organizational governance and accountability. This team’s main responsibilities are to review the existing IT architecture and create a baseline for the new initiative, to define a process ensuring that systems and projects comply with the desired architecture, and to identify short-, mid-, and long-term opportunities for savings and improvements. The team should include all key stakeholder groups, with representatives at a sufficiently high level to make strategic decisions on their behalf.

In the interest of minimizing disruption and maximizing benefits, we suggest a three-phase approach, beginning with the easier changes and working gradually toward more substantial ones (Exhibit 3). Staging them carefully makes companies far more likely to build internal collaboration at an appropriate pace, to generate early gains that can finance subsequent initiatives—and to avoid the significant risks of an all-at-once, “big bang” approach: excessive up-front investment, an internal backlash, or system-wide failure, for example.

Exhibit 3

A three-phased approach

A three-phased approach to IT transformation minimizes disruption to the business.

Phase 1: Immediate cleanup

In the first phase, the team’s task is to identify obvious targets and generate quick wins through cost reductions that help build momentum for larger initiatives. In our experience, three levers are important at this point.

Rationalize software licenses. An inventory of licenses should uncover idle, underused, and even incorrect ones. When business managers participate in the review, CIOs can determine how many licenses are truly necessary, retire those that aren’t, and then negotiate deeper discounts by consolidating licenses.

Cancel noncompliant projects. An assessment of the degree to which ongoing projects support both the business and IT strategies can reveal candidates for continuing support, revision, or termination. In ordinary times, this type of review often highlighted projects that business leaders regard as important enough to justify exceptions to architectural rules. The exceptions bar should now be set much higher. Together, the team can segment projects into four groups: (1) projects that have high business value and directly support the IT strategy ought to continue; (2) those that have high business value but don’t comply with the IT strategy should be reshaped; (3) those that comply with the IT strategy but have little business value ought to be delayed; and (4) noncompliant projects with low business value ought to be cancelled.

Decommission little- or never-used applications. Candidates for retirement include business applications that have rarely or never been used over the past year. Different approaches may be required: depending on usage and need, some may be retired immediately, others replaced by newer applications, and still others phased out gradually.

A telecom operator, for example, recently observed that violations of its IT architectural guidelines were rising sharply because managers of business units—who weren’t directly affected by the failure to comply with the guidelines and had little incentive to do so—demanded that IT support new business initiatives quickly. The violations usually made the IT operation more complex and therefore raised its long-term costs.

The company decided to focus on potential IT architecture violations at the start of any IT project or the release of a new application. The new approach—which involves assessing the overall implications of violations, including their possible additional cost—enables the company to support new business requirements quickly but requires any violations they create to be fixed in a later phase. The company can therefore assess the business and IT cost–benefit trade-offs in each case before moving ahead with projects.

Phase 2: Reducing complexity

In the second phase, the team should focus on making the whole IT architecture less complex. This more ambitious undertaking is essential to reverse the ad hoc expansion of customized systems, applications, and processes and to begin enforcing a more complete adherence to the desired architecture. The main objective now is to decide if different pieces of the existing IT setup are truly needed rather than trying to optimize them. Often, the team will find that simpler off-the-shelf systems and the reuse of existing components can support business requirements. Companies can use a number of levers during this phase.

Enforce out-of-the-box solutions. Too many projects adopt customization as a first rather than last option. A company can’t make all its business units embrace standard, completely uncustomized applications immediately, but given limited resources the team should require out-of-the-box solutions in the vast majority of cases, allowing customization only when absolutely necessary to meet legal requirements or provide meaningful competitive advantages. Functions such as finance and accounting, human resources, and purchasing, which typically don’t play a role in direct competition with other companies, are prime candidates for savings in this phase. It’s hard to change organizational mind-sets and behavior, but many IT projects fail because of excessive customization, so its end can make companies substantially more efficient and effective.

Encourage reuse. Too many companies spend precious IT resources reinventing the wheel. A serious review of the existing project portfolio will probably uncover a number of opportunities to reuse existing solutions and build a common repository of services and solutions. The move to a service-oriented architecture (SOA)—which describes a system in terms of the business capabilities it requires and a uniform way of accessing and interacting with them—is an important part of this shift.

Consolidate databases and develop an integrated data model. As companies grow, they add new databases and applications for online sales, customer relationship management, and billing to support business units and functions whose needs actually don’t require different databases. In fact, nonintegrated databases greatly raise costs and result in inefficient processes, duplicative development efforts, longer times to market, business errors, and missed opportunities.

Standardize technologies. In many companies, the great diversity of technologies—including programming languages, operating systems, and integration tools—creates tremendous inefficiencies. A careful review will point out redundant versions, unsupported technologies, and nonstandard tools that should give way to fewer, more standard systems. The cost savings come from simpler and consolidated procurement, as well as lower support and maintenance expenditures.

Reduce interface complexity. An IT staff can spend as much as 30 percent of its development time on applications making all of their interfaces work, largely because customized applications have so many point-to-point interfaces. Standardized interfaces, such as the enterprise service bus (ESB), can greatly ease the burden of system integration and minimize the chore of dealing with local changes. The team should start by identifying and focusing on the key interfaces driving most of the effort.

Consolidate systems that do similar things. Different business units in the same company often have their own versions of essential systems, such as payments and Internet applications. Consolidating these systems at the corporate level can bring substantial savings and make processes simpler and more efficient.

In addressing each opportunity, the CIO and business leaders must look hard at trade-offs between short-term convenience for business units and short- and longer-term costs and complexity for the company as a whole. Facing such realities isn’t easy, but the economic crisis should create a sense of urgency. Some of these cost-cutting opportunities will call for investments, and every one of them will demand a solid business case.

At one retail bank, for example, a comprehensive assessment to reduce architectural complexity identified major cost savings in most areas. A team of business and IT executives helped the company find more than 50 unused applications to decommission, 150 redundant applications to consolidate, 800 point-to-point interfaces to put on an integration platform, and 400 applications to connect with a data integration platform.

Most of these changes required near-term investments—in several cases, such as eliminating or consolidating larger redundant applications, fairly substantial ones. Not all consolidation proposals showed a positive return. What mattered most was the team’s decision to insist that the leaders of projects prove the business case for each of them. In all, the effort is on track to provide a return on investment of more than 50 percent, a reduction in time to market of at least 30 percent, and additional organizational benefits, including better alignment between business and IT.

Phase 3: Business innovation

In times of crisis, companies must consider transforming or even completely reinventing themselves. IT can play a central role in implementing big changes in the way they operate and bring products or services to market. The third and most ambitious phase of architectural transformation is about making these bold changes. As companies look beyond the downturn, they should consider changing their IT in more radical ways that can drive or support strategic innovation and fundamentally new areas for growth. Two levers are relevant.

Assess alternate operating models. Most companies have a global business, but far fewer have developed a truly global IT operating model that supports the corporate strategy. A comprehensive review of the IT value chain should identify the level of sourcing, harmonization, consolidation, governance, and IT enablement necessary for each essential business capability. This review can lead to a new, more effective blueprint and architecture model for IT.

For example, managing and minimizing risk, which is especially important in downturns, depends heavily on getting the right data from the entire business to support timely decision making. Business and IT leaders must work together to design the data-management model that promotes the most effective data-driven decision processes.

Shape the future. Business leaders should work closely with IT to explore investments in a wide range of emerging technologies that support new ways of working, such as using the Internet to cocreate products with customers and suppliers, online collaboration among employees, and data-driven management. New tools and processes can accelerate globalization in product development, find profitable niches in declining markets, and increase productivity.

The triggers for this more ambitious approach to architectural transformation can vary. At one manufacturing company, it was an acquisition. The company had just purchased another international business, vaulting the combined entity into the top five in its industry, with more than 20,000 employees and more than $13 billion in annual revenue. Looking to capitalize on this enhanced position, the company’s leaders realized that they couldn’t succeed with two different operating models relying on archaic information systems.

After defining a new, integrated global operating model for sales and distribution, the supply chain, product-life-cycle management, and postsales service, the company implemented it with a streamlined IT architecture. The impact was substantial. Among many other benefits, the company reduced the time required to quote special-bid prices by 90 percent and to create custom products by 80 percent.

The architectural transformation at a national oil company was sparked by its management’s desire to turn it into one of the world’s top oil and gas businesses. The company’s IT systems couldn’t support such growth. Too many systems were customized to local needs. Too few business processes were in compliance with company standards. Data were inconsistent from one business unit to another, so cross-divisional collaboration was arduous. And IT rarely matched best industry practices.

With a clear mandate from top management, IT and business leaders focused on core business objectives requiring a reformed architecture. Under the new plan, IT would support world-class processes, facilitate corporate-wide decision making by supplying better data, help the company develop better insights about customers, and provide an accurate and up-to-date view of its financial, managerial, and logistics position. The company is developing a unified information system to link all divisions and reviewing with greater discipline all requests for new IT projects. IT is exerting more control over critical functions such as finance, human resources, and sales.

The downturn gives IT and business leaders an important opportunity to collaborate in reducing costs and reshaping the IT architecture for competitive advantage. When companies look solely to the IT function to find savings, the results are often limited. A joint IT–business team can achieve much more.

Bringing IT and business leaders together can also help IT create new ways to make the business grow. Greater flexibility, faster times to market, and more efficient and effective business processes will outlast the downturn. For companies that see the present troubles as a chance not only to control their costs but also to reposition themselves for faster growth once the turnaround begins, restructuring the IT architecture can be among the most valuable moves.

About the authors

Janaki Akella is a principal in McKinsey’s Silicon Valley office, Helge Buckow is a consultant in the Berlin office, and Stéphane Rey is a principal in the Geneva office.

About this content

The material on this page draws on the research and experience of McKinsey consultants and other sources. To learn more about our expertise, please visit the Business Technology Practice.

  • © 1996-2014 McKinsey & Company