The technology adoption lifecycle is very important in the high-tech industry.  An entire genre of books, such as Crossing the Chasm (and its sequels) and The Innovator's Dilemma (and solution), have focused on the adoption of new technologies, disruptive innovation, and maturity/obsolescence. 

Technology adoption almost always follows a bell curve, as in Everett Rogers' Technology Adoption Lifecycle model:

By some measures, virtualization is in the "Early Majority" or even "Late Majority" phase: for example, VMware has 100% of the Fortune 100 as customers, which says that large enterprises are using virtualization.  At the same time, however, various studies pinpoint the number of virtual servers as something less than 10% of the addressable population (putting us in the "Early Adopter" phase - not really applicable for a 6th generation product).

This tells me that the technology adoption lifecycle isn't the best framework for categorizing where an organization is in the adoption of virtualization.

Maybe we could look at it as an S-Curve:

...that's better.  One could fit a 5-stage framework into that curve.  However, that only looks at the percentage of addressable servers that are virtual.  It doesn't take into account the way virtualization is actually used (i.e., is the customer using VMotion for maintenance activities, or snapshots for quick roll-backs).

So, I came up with a 5-level framework that could probably fit into some kind of 2x2 matrix, but we'll defer the visuals (for now), and look at five stages, and the corresponding timeframes at which customers reached these stages.

Level 1 - Experimental [2005-2006]

In this phase, an organization uses physical (non-virtual) infrastructure for all new builds and refreshes of existing assets.  Virtualization is only used in pilot, proof-of-concept, or limited development deployments.

Most organizations are already beyond this level. 

Level 2 - Limited Deployment [2006]

As organizations became a little more comfortable with virtualization, they began to use it to replace actual physical servers -- these servers were normally development, test, or non-critical production servers.  Some of the common themes in Level 2 include:

• Use of broad rules of thumb instead of actual utilization data to determine virtualization candidates (e.g. "never put a database in a VM; avoid VMs for network-intensive applications)
• Hesitance to use virtualization for critical applications (ignoring capacity or workload requirements)
• Resistance to shared infrastructure from business units (normally a chargeback issue, if not purely a perception issue)

Here, the financial effects of server virtualization are mostly limited to capital costs (mainly server hardware) and operational costs associated with power, cooling, and floor space.  It is very difficult to take advantage of the flexibility and operational efficiencies afforded by virtualization when virtual servers are treated as second class citizens.

 

Level 3 - Virtualize First [2006-2007]

Somewhere in the past two years, IT shops began to see server virtualization as strategic.  For a time, this was my definition of "strategic virtualization" - in other words, if a virtual server is the default target for a new deployment or refresh of an existing asset, then it passes the test for whether virtualization was considered "strategic" to an organization.  I now realize that the "strategic" bar should be set higher (see Level 4).

The "Virtualize First" policy means that at the time a decision point is made on a server (for example, a new deployment, refresh, migration, or event caused by  power/cooling constraints), the default target is a VM, unless a logical counter-case can be made.

Examples of logical counter-cases might include:

• Server requires direct access to hardware (e.g. fax server, USB dongles), and no cost-effective workaround is available
• An inordinate amount of capacity is required, e.g.24 GHz [ xxx SPEC] of CPU cycles (keeping in mind differences in throughput between legacy and state-of-the art technology)

There are still a number of poor counter-cases in organizations' decision trees, for a variety of reasons.  For example, VMware ESX Server 2.x was limited to 3.6 GB of RAM per VM - whereas a 3.6 GB limit was applicable in 2005, the ESX 3.0.x limit is 16 GB, and the current (ESX 3.5 limit) is 64 GB.  At the same time, processing power (mainly due to multi-core processors) and I/O bandwidth capabilities have kept pace.

Capacity Planner studies, time and again, show that 80-90% of Wintel workloads are virtualization candidates in organizations large and small.  Finally, whereas application vendors were loath to support their applications in a virtual environment in the past, much of that has gone away due to customer pressure and general industry maturity.

As promising as the "Virtualize First" policy is, it does not, on its own, provide much operational efficiency.  Even if an organization moves 100% of its servers to VMs, it will not see much operational efficiency if it continues to manage its newly-virtualized servers as if they are the same physical assets that they replaced. 

Level 4 - Operational Transformation [2007]

Somewhere between Levels 4 and 5 is where the term "strategic virtualization" could be applied.

Level 4 can only be achieved with some level of executive buy-in.  Whereas it is relatively easy migrate a large number of physical assets into virtual machines without changing an organization, it requires real executive sponsorship to drive a change in the way systems are managed.

Examples of the types of activities that can be transformed because of virtualization may include:

• Provisioning: builds of new servers is made easier with hardware-independent template-based provisioning.  This can include not only the OS and core tools (the traditional "image-based" deployment approach, but also entire application stacks
• Standardization: template-based provisioning drives a higher level of standardization, and higher standardization is the number one driver of a high server-to-admin ratio
• Configuration changes: if a VM snapshot is taken before a change, it allows for a quick, low-impact rollback to a known trusted state when necessary
• Server maintenance: using VMotion, a server can be taken offline for upgrades, part-swap, or replacement without impacting the applications running on it - during business hours, and without requiring off-hours work and overtime pay
• Patching: even before VMware Update Manager, organizations were able to use clones or snapshots to test patches(clones) or roll back from bad patches (snapshots) - now, patching of hosts, guest OSs (online or offline) and applications is automated
  

Level 5 - "Business Transformation [2008]

This is the year of Business Transformation through virtualization. 

Some organizations got a head start on Business Transformation in 2006-2007 through the uses of Virtual Desktop Infrastructure (VDI) and Virtual Software Lifecycle Automation (VSLA) tools like Lab Manager.  These tools allowed them to change the way development infrastructure or desktop services were built and managed, without transforming their production server infrastructure.  We're seeing an increased adoption of those solutions, but my focus here is on the transformation of the way production servers are architected, built, managed, and commercialized.

Another key development is the concept of "Transient VMs".  Traditional (physical) server architecture means static servers, built for a purpose, and those servers typically "stick around" for a long, long time.  A server that is powered on and placed on the network is a server that must be patched and managed.  Transient VMs are those that are created for a purpose, but then may be archived or destroyed as required. 

Examples may include test VMs (clones of production, perhaps), development environments in Lab Manager, or legacy applications in VMs that can be powered off and archived for compliance reasons.  Plus, the great thing about powered-off VMs these days is that they can be patched with VMware Update Manager (in other words, the best of both worlds: a patchable VM that doesn't need to be managed on a day-to-day basis).

A third development is the use of advanced automation with virtualization.  VMs, because of their portability and flexibility, are a much better object for automation than physical machines.  This has given rise to solutions such as Dunes VS-O (now part of VMware), which automates hundreds of workflows that normally would be performed manually.

A fourth development is the fact that organizations (both outsourcers and internal IT shops) are offering new services that use virtualization at their core.  These includes Disaster Recovery (using internal assets instead of third parties), on-demand computing, or hosted virtual desktop.  For outsourcers in particular, it means that they can get new revenue streams, without increasing their customer's overall IT spend (usually, the customer gets more revenue, and the customer reduces costs).

A combination of organizational experience, experience in the systems integrator community, and product capability has given us the "perfect storm" in 2008 for business transformation.