Virtualisation: Building blocks to achieve benefits

This week I was invited to attend a gathering at Collabworks, an organisation focused on the virtual enterprise. Collabworks believes that the kinds of savings and efficiencies that virtualisation has brought to IT can be brought to entire companies by reorganising workplaces along the lines of what has happened in IT (virtualisation to remove dependencies, focus on service outputs rather than processes, and use of specialised external resources rather than internal employees).

As IT only accounts for around 3% of total corporate costs, if Collabworks' theory is right, there's clearly great opportunity for enterprises.

Collabworks puts together a programme that included a speaker who was a former HP employee, who worked on HP's IT consolidation efforts, along with a panel that included the CTO from a large software vendor. We'll call the CTO "Bob" for purposes of this post.

What both of them described and the way they operated to restructure IT was really interesting, and a good vision for how most companies should approach this critical task.

The fellow from HP described some impressive stats to illustrate the restructuring outcomes: 85 data centres down to six; 6000 apps down to 1500; resulting in over $1 billion (£640 million) in savings.

Likewise, Bob outlined some of the benefits that his organisation has achieved: a large drop in costs, a shift to offering many of their products as cloud services, and most important, IT's ability to be much more agile.

How did they achieve these results? Here are some of the points they made:

HP

1. Timebox the effort for any given initiative. Start with a fixed due date to ensure focus.

2. Aggressively reduce support for legacy systems. When people insist they need access to existing systems for laudable reasons (for example, potential legal discovery), offer to keep them available - for a price. It's amazing how unimportant some "important" things can become when there's a cost associated with it.

Bob

1. Get out of non-differentiating packaged apps as quickly as possible. Move to SaaS offerings to replace on-premise software aggressively. This frees up budget to invest in innovation.

2. Change the relationship with business units from "point" projects (like upgrading to the next version of Product X) to placing what are in effect product managers within the business units to understand needs that can be translated into technology deliverables - that are focused on profitable offerings and innovation.

3. Don't sell technology improvements to business units funding initiatives. For example, don't sell a SAML implementation as part of a move to Salesforce. Instead, sell the ability for a person to sign on once and have access to all SaaS applications he or she uses.

I have to say, most of these lessons seem sensible and pretty obvious. Why doesn't everyone implement them? What needs to be in place for these sensible lessons to occur in any IT organization. Here is my take:

1. Firm service level interfaces between applications and core services. It's clear that for applications to support agility, it must be easy to create them. That means IT departments need a set of infrastructure services that are available and can be integrated at an API-level. Any time an application implementation requires customising an infrastructure capability, there is a dependency that will frustrate overall business agility.

2. Methodical focus on removing legacy applications and migrating to SaaS equivalents for non-differentiating functionality. This is quite difficult in practice as it's much easier to make the incremental budget spend each year for an application, rather than take the effort to replace it with SaaS. Unfortunately, the sum total of all the "it's cheaper to maintain this application rather than replace it" is the 80% legacy problem most IT shops face. A dedicated focus is required to implement a multi-year plan to replace applications and reduce costs. The result is savings that can be invested in innovation and business-facing applications. This, of course, requires higher company management to allow the savings to be invested in additional applications rather than treating them as additional costs that can be extracted from IT.

3. Funding core services with an infrastructure-oriented budget. Providing a service interface requires IT operations to be a service provider. Making this transition requires a substantial, ongoing and protected budget to invest in the infrastructure. It also requires that these investments be made through thick and thin, avoiding the "we need to make the numbers this quarter, so we'll put off the network upgrade" phenomenon.

One challenge associated with it that applications get most of the attention, so how do you ensure investment in infrastructure? Bob explained that his company has a "Bob tax," in which business units know that they'll be expected to pay a surcharge on the cost of an application to fund infrastructure improvements. Bob has a pool of funds to invest up front to get the infrastructure improvement implemented; these funds are gradually returned to the pool via the surcharge.

4. Trust from senior management and business units. I think that this is perhaps the most important requirement, albeit completely non-technical. Both speakers had this support. The HP rep worked on an initiative spearheaded by Randy Mott, the ex-Dell CIO handpicked by Mark Hurd to cut costs. Obviously, this initiative had upper level support. In Bob's case, he has been at his company for a number of years, and crucially, worked in the product group (i.e. the revenue-producing business unit). This gave him the credibility to implement the kinds of changes he described.

Obviously, not everyone has this level of trust. One cannot be sure what an IT leader can do in the absence of trust. Certainly, the kind of changes described above cannot be achieved in an environment of low investment and lack of trust. That's a recipe for continued minimal investment, inability to retire legacy systems in favor of migrating to SaaS alternatives, and, frankly, eventual irrelevancy. And trust is crucial. One can note that Mott left HP in July of 2011, with a rather perfunctory send-off - triggered, no doubt, by Hurd's own messy departure.

As I observed earlier, the changes described by the Collabworks presenters seem sensible and even obvious. That doesn't mean they can be easily achieved. As a colleague once noted, just because something is simple doesn't mean it's easy.