Large infrastructure functions1 have traditionally been organized in “technology towers” for mainframes, servers, storage, middleware, databases, networks, and end users. These technology domains, often combined with smaller regional towers, each have their own staff interfacing with business partners, developing and deploying service offerings, and supporting operations.
However, this model seems to be hitting its limits for large enterprises as businesses become more global, the expectations of partners grow, and the pace of IT infrastructure innovation increases. As a result, sophisticated infrastructure organizations are increasingly turning to functional “plan-build-run” organizational models, which, by breaking down silos and working across technology domains, can facilitate a broad set of performance-improvement and transformation objectives.
The declining relevance of technology towers and regional constructs
As large enterprises started to consolidate IT infrastructure across individual businesses, they typically designed organizational models around a combination of central and regional technology-tower elements. For example, the infrastructure function of a large manufacturer might be organized by big technology towers—global data center, network, and desktop organizations, each with regional components in the Americas, Europe, and Asia. This type of organization had the benefit of simplicity. One executive could be held accountable for the cost and uptime of each technology tower and its regional components, and regional staff stayed relatively close to internal customers such as application-development and maintenance groups.
However, technology tower–based organizations have always been suboptimal in several respects. They often result in an inefficient duplication of activities, with people in each technology tower responding to basic incidents or making simple changes to infrastructure configuration in different ways (Exhibit 1).
Traditional technology-aligned organization is suboptimal.
Perhaps more important, the tower model makes it much harder to provide important business capabilities and address complex problems. For example, diagnosing challenging application-performance issues, where any one of a number of technologies might be the root cause, could require coordination across almost the entire infrastructure function. In addition, the absence of a single “front door” for infrastructure makes it much harder to manage demand, which is often frustrating for business partners and application developers. As one senior architect said, “I spend a third of my time running between the server, storage, database, and network towers to get them on the same page on the overall infrastructure design.”
Increasingly, tower-based models conflict with the aspirations and objectives of infrastructure leadership teams. As more infrastructure functions have adopted lean operations, they have sought to cross-train personnel and segment tickets for incidents and changes related to hosting service, such as configuration and patches, by complexity rather than technology discipline. Naturally, technology silos limit the extent to which this can be done.
Technology evolution presents an even bigger need for organizations to have integrated technology design, infrastructure solutions, and operations. This is because private-cloud environments,2 converged infrastructure products, Internet Protocol (IP) telephony, unified communications,3 and virtual-desktop4 infrastructure make traditional distinctions between end user, data center, and network less and less relevant. As one head of infrastructure told us, “Unified communications nearly broke my organization. The network guys said it was the next generation of voice. The data-center guys swore it was just another server running an application.”
Making the transition to a plan-build-run organization
A plan-build-run organization is structured around major infrastructure functions that work across technology domains (Exhibit 2). There are two “plan” functions. Relationship management is responsible for collecting business requirements, performing demand management, and serving as the overall interface with business partners. Product management is responsible for developing and optimizing a set of reusable service offerings to be used by application developers. This involves understanding business requirements, defining service levels, and calculating product unit costs. It also includes optimizing product economics over time, just as it would for a product-management group at a technology vendor.
Leading IT infrastructure organizations are increasingly adopting plan-build-run models.
Likewise, there are two distinct “build” functions. Product engineering does the technology design and configuration to make the service offerings defined by product management ready for use in a production environment. This includes investigating vendor offerings, selecting specific technologies, performing the integration required to make sure they work together, and conducting prerelease testing to ensure required stability. Deployment takes complex requests from relationship management, develops implementable solutions using standard service offerings, and provisions them into the day-to-day environment. The deployment team, for example, determines how many servers and how many gigabytes of storage should be provisioned to support a new business application.
The “run” group performs all the operations and provides support to keep the technology environment operating and meeting service-level expectations. It usually includes several large components:
- a service desk to receive user incidents and requests and resolve as many of them as possible; those that the service desk can’t resolve are passed on to the appropriate service group
- a level-one group with staff trained on many technologies to address simple tickets for most technology domains
- level-two and level-three groups to address more complex tickets that require some degree of technical specialization and to oversee the operational health of each technology area
- a field-service organization to resolve all tickets that require “physical touch” of an asset in a business location (for example, installing a new local-area network or changing a power supply on a local server)
- a facility organization to oversee and operate the data centers and resolve all tickets that require physical touch inside a data center
Addressing design and implementation considerations
To translate the broad plan-build-run structure into a working organizational design, there are a range of questions to address according to an infrastructure organization’s ambition, starting point, and constraints. Two examples of these illustrate the kinds of considerations to be weighed.
What is the balance of power between regional and global functions? Within the broad parameters of a plan-build-run organization, it’s possible to have strong regional functions, perhaps with a global group driving process consistency, or to have global functions with a thin regional overlay to address local regulatory, administrative, and HR issues. Some infrastructure organizations choose to maintain strong regional functions because they believe it’s simpler and allows them to stay closer to local application-development and maintenance teams and other business partners. But it’s becoming much more common for core functions to become global, with regional management as a thin overlay, as the businesses that infrastructure teams support become increasingly globalized themselves.
Who has ultimate budget responsibility? In a plan-build-run model, the end-to-end P&L responsibility for infrastructure services can sit in one of two places: with the product managers or with level-three operations. Both choices have proved successful in different circumstances. In most cases, the choice is based on senior leadership’s beliefs about where the managers with the skills and organizational authority to drive budgetary objectives sit.
At the same time, transitioning to a plan-build-run model requires careful implementation planning in a number of dimensions, including the redefinition of roles, new types of metrics, skill implications, training requirements, inspirational communications, and sequencing of key milestones in a pragmatic way.
Unlocking short-term value and enabling a broad range of strategic objectives
In our experience, transitioning to plan-build-run infrastructure usually drives short-term cost reductions amounting to the equivalent of 5 to 10 percent of labor costs, which are captured within 6 to 12 months and based on several sources of value:
- eliminating duplication of activities by forming shared services for common activities (for instance, global product management and product engineering; global build factories; analytics and reporting; project management; and finance)
- adding scale in operational activities such as incident management, problem management, and product engineering
- improving performance of middle managers and workers, for example, by using output-based metrics
- reducing demand for activities that don’t add value (for example, the frequency and size of metrics reporting)
In addition to short-term value, transitioning to a plan-build-run model accelerates and reduces the risks associated with the major transformations that are increasingly important to leading-edge infrastructure groups:
- enabling organizations to effectively introduce and manage next-generation infrastructure products across technology domains (for example, private cloud, unified communication, virtualized desktops, and IP telephony) by breaking down technology silos and creating product-management teams to drive the introduction of sophisticated, integrated offerings
- increasing the effectiveness of demand management and enhancing the business-unit IT experience by creating dedicated groups to work with senior development managers on decisions and trade-offs that affect infrastructure costs
- accelerating deployment of complex applications that span multiple technology domains by creating integrated deployment teams
- facilitating more effective sourcing arrangements, with companies retaining strategic functions including product design, engineering, and customer management while sourcing activities that are more execution oriented
- expanding the value of lean operations by facilitating the segmentation of operational activities by complexity rather than technology domain
For many infrastructure functions, transitioning to a plan-build-run model can both unlock short-term value and enable a broad range of strategic objectives. However, doing so requires getting important decisions right and planning carefully to overcome implementation challenges.
