Virtualisation is one of the hottest topics in the IT world these days, due to compelling stories about return on investment (ROI), rapid provisioning capabilities, and application deployment flexibility. Although most of the focus is on server virtualisation and its consolidation benefits, virtualisation at the network, file, and/or storage layers may also provide a variety of potential benefits. Virtualisation has the potential to drastically reduce IT acquisition costs and ongoing maintenance costs, helps facilitate disaster-recovery strategies, and can support critical (but typically painful) data-migration activities as well.
However, several recent surveys have indicated end users’ dissatisfaction around these value propositions: Customers that implement virtualisation often cannot quantify or meet the ROI numbers they expected, and in many ways are finding management of the virtualised environment more complex than originally envisioned.
Obstacles To Success
What is the root cause of this dissatisfaction and missed expectations? To best answer that, we can start with another question: What did these organisations do to assess how ready they were for virtualisation prior to implementation? Most companies have greatly heightened their focus on preparation for disaster, but it seems that similar rigour has been largely overlooked during the implementation of virtualised environments. One should note that this lack of preparedness is not limited to virtualisation implementations: It’s often seen with a variety of other IT projects as well, including enterprise resource planning (ERP), customer relationship management (CRM), and storage resource management (SRM) implementations.
Companies encounter the first obstacle to success in a server virtualisation implementation when proper expectations with both management and the operations team in the implementation trenches are not set. The misunderstanding typically starts with a lack of context-how the virtualisation implementation will fit into the overarching IT strategy, from both a short-term and a long-term perspective (assuming there is a strategy that’s documented and agreed to).
Fundamentally, no IT project should move forward unless it is driven by a defined business requirement. When you’re setting expectations there should be a defined and documented strategy statement that 1) clearly articulates the business objectives, the critical success factors, and the expected ROI; 2) provides a comprehensive understanding of the costs, as well as the real constraints and risks; and 3) achieves consensus from the organisation’s key stakeholders, articulated up the chain of command. This strategy statement is critical for the success of a virtualisation initiative.
Now that we’ve covered obstacle number one, let’s discuss how setting expectations fits into the overall virtualisation strategy, and what business requirements the virtualisation environment will support. It’s important in the early stages to clearly define the key stakeholders, including C-level sponsor(s), application owners, server architects, LAN/WAN architects, and data-centre managers/operators. This early involvement and participation leading to buy-in with these stakeholders is critical to success.
The second obstacle to a successful virtualisation implementation involves outside influence, or the gap between vendors and the client. The gap between perception and reality often begins with the vendors, who are more than likely to downplay the specifics regarding the level of effort required to implement their technology, or the number of hours required to properly test and develop new operating procedures or to modify existing ones.
Internally, this misguided enthusiasm may also get propagated with IT personnel. Many times these projects are sold via a “dollar figure per hour of downtime,” which is fine as a unique metric. However, this approach overlooks other benefit areas such as power, cooling, and floor space, as well as the question of whether the implementation team is fully capable of success and whether the potential impact to your operational processes has been fully considered.
Given these common obstacles, what benchmarks are available to determine the “virtualisation readiness” of your organisation? We will offer several below.
Let’s start by examining some of the impact areas of adopting a virtualised IT environment. The first question you should consider is: How mature does the governance, policy, and process framework need to be to handle the changes associated with virtualisation?
To answer this question you first need to understand whether your organisation is more technology-centric or service- centric. In technology-centric organisations, IT projects are more often driven by an “inside-out” approach, in which the IT organisation recommends technology and the benefits they perceive the business will derive from implementing these recommended technologies. In a service-centric organisation the approach to implementing new technology is reversed. A service- centric organisation first looks at the business problem(s) to be solved and the technologies that might best solve these business problems, and then makes recommendations based on this analysis.
Many companies have embarked on an ITIL initiative, which at its core is designed to move the IT organisation further along the maturity curve from technology- centric to service-centric. If you are implementing ITIL, then the identification of where your company fits along the ITIL maturity curve may help explain how the virtualisation project needs to be justified internally. If the organisation is moving more rapidly to a service-centric model, then the benefits to the business must shine through in the justification analysis. Any cost/ benefit model must include business objectives (external to the business and internal to IT), critical success factors (ROI, TCO, provisioning process cycle time efficiency), and potential risks or constraints (budget shortfalls, staff capacity for change, training).
Any proposed benefits of a virtualisation implementation must be derived and communicated in the context of the service provider maturity level with appropriate weighting applied to those benefits that fall into a technology-centric bucket and those that fall into a service-centric bucket. For example, technology-centric benefits might include lower capital costs for server purchases, decreased data-centre footprint, and lower operational costs. Service- centric benefits might include shortened provisioning cycle times leading to more-rapid application deployment, which translates to competitive advantage for a particular line of business.
It’s important to know how the virtualisation technologies will affect all process areas, including not just the obvious ones such as SAN configuration, provisioning, and disaster recovery, but all processes along the ITIL spectrum of service support (release, change, incident, problem management, etc.) and service delivery (capacity, availability, service level, and financial management, etc.). Also, do you have defined business process criticality documentation, supported by under- lying application criticality documentation, which in turn defines the underlying architecture and infrastructure?
This documentation set may guide the determination of which environments are the best targets for virtualisation. Typically, this documentation is generated through an overarching data-classification effort, which defines the value of a given business process’s data through a business impact analysis related to the cost of downtime of that process. While data-classification initiatives can be time-consuming and difficult to complete, “proof-of-concept” approaches limited to few business processes can expose large potential benefits in risk mitigation and compliance/regulatory areas.
The second question you need to consider is: How does the implementation of a virtualised IT environment impact the organisation, and what level of training is required to really make this work? As mentioned earlier, many companies can trace their dissatisfaction with virtualisation implementations to the lack of internal experience with the technology itself during design and implementation. Considerations here must include all functional teams tasked with implementing, testing, operating, administering, troubleshooting, and repairing the virtualised environment. The assumption organisations make is that it’ll be easy, when in fact substantial training and knowledge are imperative to the project’s success.
A virtualisation project has broad and deep personnel effects. Before any project gets underway, it’s critical to ask the hard questions related to personnel readiness and any gaps therein, and to accurately estimate the training time required to close those gaps. Clear identification and communication of roles and responsibilities for the various functional groups before, during, and after the implementation must be accomplished to ensure success. Project management, server engineering, database administration, technical documentation, network engineering, storage, backup, and disaster-recovery engineering, performance and capacity planning, application ownership, and procurement personnel must all be involved at the beginning of the project.
Question number three involves the technology impacts a virtualised environment will have on the overall organisation. A virtualisation implementation impacts server-farm design, including storage, clustering, network connectivity, and switching, and this will drive the requirement for new or updated operating system “templates.” The relative maturity of your IT standards and documentation is important to understand, as work will need to be done to fit the virtualisation components into the existing architecture. The virtualisation components must also fit within corporate guidelines for new technology deployment and lifecycle, including potential retirement of legacy equipment.
In addition, there must be a defined approach to ongoing monitoring and reporting on the virtual machines- an area that is often overlooked but highly necessary. Salespeople may not touch deeply on this area as it can be an arduous process, but the implementation team must understand what tools are currently in the environment that provide application-to-host-to-server-to-storage mapping, such as an SRM tool, or overarching IT environment management tools such as Hewlett-Packard’s OpenView or CA’s UniCenter. This ongoing monitoring and reporting will provide vital feedback on performance, capacity planning, service-level management, and ROI.
When you design your monitoring framework, be sure to include visibility to the hosts, not just the virtual machines themselves, and the ability to monitor and report on the virtual environment in the same way that you report on the physical environment. This is particularly important in those organisations that are more mature and service- centric, where service-level agreements (SLAs) are required. SLAs related to the virtualised infrastructure will need to be developed and adhered to, and the monitoring toolset and its operating policies, processes, and procedures are at the crux of this adherence.
The last question you’ll need to think about is: How do you successfully deploy your virtualisation strategy? If you followed the strategies above, you should have the foundational design or architecture for a successful project. Now you must take this and the deployment plan to all of the key stakeholders and start talking. Collaborative sessions will need to be scheduled where you discuss and agree upon aligning the stages of the project with the organisation’s ability to absorb change, identifying dependencies within the virtualisation project and how these dependencies affect other ongoing projects.
This article has covered some of the obstacles to success that must be considered when an organisation undertakes a virtualisation effort. We’ve also touched on the potential impacts of a virtualisation project on an organisation’s people, processes, and technology, from the perspective of preparedness and relative maturity as a service provider. It’s clear that although virtualisation implementations can have far-reaching consequences and do require appropriate due diligence in understanding the work at hand, with solid preparation, success can be achieved.
Organisations must consider virtualisation as a strategic component of the long-term infrastructure, and not pigeon-hole it as a point solution. Because the potential benefits are so significant, having a diligent, big-picture view from the start is essential to fully realising the benefits of the virtualised environment.