Your New Product: Infrastructure

Analogies are useful to simplify complex things like IT, though sometimes they can oversimplify. In this article, McKinsey consultants compare IT infrastructure to the early days of automobile manufacturing, when cars were all built one at a time for rich people who could specify everything down to the door handles. The McKinseys suggest a Henry Ford approach to infrastructure architecture, whereby application developers no longer specify the infrastructure their applications will run on, but choose from among a number of predefined IT infrastructure “products” that are designed to handle different levels of expected user demand, scalability and speed requirements, as well as the amount of downtime that is acceptable. Each product has a unique service level agreement (SLA) and price.

McKinsey estimates that CIOs could save 20-30 percent on infrastructure costs doing it this way, because of increased standardization and consolidation and reduction in time developers spend negotiating low-level infrastructure specifications with IT staff. IT can create a few standardized processes for delivering and maintaining the infrastructure–and perhaps automate some of those processes–rather than approaching it piecemeal. “We’re talking about creating a selection of horizontally scaled hosting platforms,” says McKinsey consultant James Kaplan. “Companies have been standardizing at the component level [application servers, for example] instead of creating bundles that are meaningful to users or application developer requirements.”

Sounds great in theory, but I wonder if it doesn’t oversimplify infrastructure planning strategy. As McKinsey’s Kaplan points out, this simpler model requires a complex understanding of infrastructure demand patterns and good governance. “You’re asking for significant change on the part of business users and application developers,” he says. “You want them to begin articulating service level and functionality rather than technical specifications for the infrastructure.” Responsibility for the performance of the infrastructure will need to shift from developers to the IT managers (most likely enterprise architects and/or senior technical engineers, says Kaplan) responsible for specifying and managing the different infrastructure products. “It used to be that the application developers would accept the SLA and say here are how many boxes we need,” he says. “Now the infrastructure function will have to accept the SLA, develop good pricing models and accept penalties if the hosting platforms don’t perform as expected.”

The infrastructure function will also have to have an exceptions process for new, untested or very high-performance applications. “A key success factor for this type of governance is to make sure the exceptions are truly the exception,” says Kaplan. “If 60 percent of the time there is labor put in to decide which products to use for a new project then you’re not getting the speed and efficiency you should.

Specifying the products could also be very difficult. Do you stick to a very low level like the managed-service providers or do you get fancy and include standard applications, say document management, for example, in the products? In really big, diverse companies, the challenge could be immense.

And then there is the issue of legacy. How do you productize what you already have? Kaplan suggests focusing on new additions to the infrastructure first and then migrating the old stuff forward to the extent you can. “You can start making the infrastructure problem better or continue making it worse,” he says. “The best time to change legacy would be when you have to change the business logic anyway, like a product upgrade, for example.”

The point, says Kaplan, is to redirect effort from the infrastructure to applications. “Application developers should be focused on what creates value not technology infrastructure which is an enabler rather than a primary value creator.” OK, makes sense. But how realistic, or rather, how simplistic, is this product analogy? Spend some time and give us your war stories about trying to rationalize your infrastructure.