Virtualization Journey

In previous posts, I covered the 3 main stages of virtualization adoption, I drilled down into the IT Production Phase and gave an overview of  the Business Production phase.

The transition from IT production to Business Production is the most critical part of the virtualization journey and many customers are dealing with it right now. Let’s dive deeper into it.

Business Production Key Adoption Elements

First, lt’s take a look at the characteristics of the key journey adoption elements in this phase

Confidence

Confidence refers to the level of competence and experience that the IT team has around virtualization technology. While in the IT Production phase we describe confidence as reactive, in the Business production phase confidence is better described as selective. Wha I mean is that the team is not yet ready to virtualize everything that comes their way but they are getting there. They selectively apply virtualization to increasingly more challenging workloads.

In IT production there is a big inflection point when the team learns how to use vMotion as it unlocks their ability to perform maintenance without downtime and start demonstrating one of the most tangible and visible advantages of virtualization: abstraction and workload mobility.

In Business production there are multiple confidence inflection point as the team learns how to deploy products such as SRM for disaster recovery, HA and FT for business continuity and quality of service, DRS for automatic resource management, and VMWare view for Virtual Desktop deployment. These are the products that build out the platform needed to properly support the virtualization of business applications and databases.

Sponsorship

This is the stage of the journey where the sponsorship level for the virtualization initiative is most critical to adoption and success. As I discussed in this other post, there are different stakeholders at the table during this phase such as Application Owners and Database Administrators. To properly win their concerns and get to the resistance is futile stage, IT teams have to get application owners comfortable with the technology. This is typically achieved in one of 2 ways

1. Address their Technical Concerns
   Show them their apps/DBs running virtual, set up a demo of vMotion, HA, FT and so on. Show them that apps run better in the virtual environment.
2. Go over their Head
   Seek a higher level of sponsorship in the organization, ideally the CIO.

Point 1 above is the slower path. You look for a suitable application, you buddy up with the application owner, get him/her comfortable with demo and POCs, you go ahead and virtualize the app, measure the results and evangelize the success. Ideally, turn the app owner into a virtualization evangelist. We have seen this over and over again.

But… if the IT operation team is very comfortable with virtualization technology and with the management products mentioned above (HA, FT, DRS etc), the best and fastest way to achieve both 1 and 2 above it to lead the process from a business perspective, turn it into a business case. Depending on the business application at stake and the requirements and constraints around it, the business case can be made around business continuity, better SLA, faster provisioning (or even self service where applicable), faster time to market for new versions combined with the usual cost saving from hardware consolidation.

This is how you get the attention of the senior management team which in turn will give you air cover to win over the application owners and database administrators.

Value

Business value is always a key to drive any sort of transformation and technology adoption. As mentioned above the key in this phase is to switch the value proposition from consolidation and cost saving to business continuity and better service level for business applications. We have seen this in every customer that is successfully going through the Business Product phase. Cost saving for consolidation is “last decade” value prop to them. It is taken for granted. It becomes all about building a better environment to run Virtual Desktops, Business Applications and Databases.

I always use this example that stuck with me as I was interviewing our customers on their journey last year. After meeting with 4 customers that were squarely in the IT Production phase, I met with this IT professional who told me, and I quote: “I am virtualizing a mission critical application that manages 40 billion dollars in revenue every year and I am doing it because as long as that application runs physical, I don’t sleep tight”.

Back then, I did not realize exactly what I was looking at. Now, after more than 50 in-depth customer interviews I know. I was looking at a customer in the middle of the business production phase with a very high level of confidence and clearly the right level of sponsorhip. He was even willing to go down to a 1 to 1 consolidation ratio (in certain cases) to get the benefits of the virtualization platform. He was clearly past the consolidation stage.

Do you see this?

If you are a customer of ours and you are not yet thinking this way, it means that you are not there yet and you should look at the key elements above (confidence, sponsorship and Value) and see which one you should work on to move forward.

Do you have the right experience but you are getting push back from the app owners? From the Top? Do you have the right mandate but you don’t have the confidence to tackle business applications? Do you have a formal way of tracking the business value you are deriving from your virtualization projects? Is it just around cost savings? Are you reporting it routinely to your management team?

We are rolling out tools to help our field and our customers answering these questions and in the next few posts I will share some of the business production obstacles and best practices that we learned form our own customers

Ciao

Vittorio

In previous posts, I covered the 3 main stages of virtualization adoption and the key elements driving the virtualization journey. Just a reminder that most of the material in these posts comes directly from our customers through a primary research project that we carried out last summer.

Let’s now double-click on the Business Production phase.

During the IT Production phase customers tend to virtualize Test and Dev servers as well as assets that IT owns, infrastructure services such as file, print, web, domain controller and so on. Customer stay in this loop for a while until one of these three main event happen

1. One, they deliver so much value in the form of cost savings, that somebody more senior in the organization notices and they provides them with the air cover to scale the virtualization effort
2. Two, they run out of things to virtualize and so they have to go and find something else to do. This typically happens around 25-35% virtualization level (unless they are an ISV)
3. Third, they get hit by a big major trigger. For example they buy a new company and they need to integrate the assets, or they are about to have to build a new data center and that pushes them to the next phase.

The next phase is what we call business production and we call it business production because this is when a customer virtualizes their first mission critical application or database. Customers in this stage are in a different league because they need to learn a  whole set of new tricks, they need to learn how to deal with application owners.

This transition is not always easy and the reason why this is a chasm for most customers is that all of a sudden, IT organizations go from virtualizing what they own to virtualizing business applications that are owned by somebody else.

That somebody else is typically an application owner or line of business IT and those guys sit at the top of a pile of concerns of which saving money on servers is not the top priority.

They are concerned with risks, performance, ISV support, uptime, business continuity… and so on and so forth.

We find that as customers transition through this phase successfully, these concerns will go away over time and they get into what we call, “resistance is futile” phase your application will be virtualized and we are not even going to tell you. There are a lot of customers that do this, but it’s a transition. They need to get comfortable, learn how to use features like HA, FT, SRM, and so on to address the line of business owner concerns. Once the information about initial successes gets around, the push back from application owners and database administrators goes away. Sponsorship from the CIO always helps.

The main business drivers for this phase are

• Business continuity
• Better quality of service for business application and databases
• OPEX savings

Capex savings are still a factor but it is like customers at this point take them for granted and move their attention to building a better environment for business applications and databases to run on.

In the next few posts I am going to cover what happens in this phase, what type of applications get virtualized, what are the best practices around it and so on. Stay tuned

Vittorio

The journey framework that I have been covering in the posts of this blog is applicable to both large and small and medium enterprise, say less than a 1000 people. The main difference between small and large enterprises is the speed at which SMBs move. Most of the ones we interviewed said they went from 0 to (virtually) 100% in 12-18 months. This is mainly because:

• The CIO sits in the same room with the rest of the team (typically less that 10 people overall) in most decisions, so when they get comfortable with the technology they immediately get top level air cover
• The business is not as involved in the technical decisions, so there is less FUD and push back from application owners. When IT is comfortable with the virtualization technology, then they go ahead and quickly virtualize everything that comes their way including business applications and databases
• Their IT scale is smaller (typically 100-500 servers)
  
• It is easier for them to change their processes, thus removing friction and shortening the path to full value realization
  
• There don’t have barriers between network, storage, network and security teams which is one of the biggest obstacle to virtualization
• Because they reach critical mass quickly, they benefit by automating management using features like DRS early in the journey
• For the same reason they can have a robust DR solution across most of the assets very early in their journey

We hear many of them saying “we virtualized the whole environment in 12 months, and we have not bought a physical server since“

Obstacles

One of the biggest obstacles we heard from SMBs  is need to buy pre-tested configurations of server, storage, network and virtualization software. They don’t have the staff and the time to go through lengthy evaluation and testing and because they are not big companies, they don’t get the same level of attention from the vendors.

Quality of Life

interestingly and refreshingly, the  ‘better quality of life’ theme came up very often in out SMBs interviews.

One example if the ability to do disruption-free hardware maintenance thanks to vMotion: “We don’t have to come in during weekends to do hardware maintenance and upgrade anymore, we vMotion the virtual machine to a different server and we do this during working hours without business disruption“.

Another good one is the use od DRS to automatically manage the virtual infrastructure based on quality of service policies: “We used to obsess about whether all my server lights were green, now DRS does that for us“

Vittorio

In my previous post I talked about what are the key elements that drive the adoption of VMware virtualization technology in our customer base.

After looking at dozens of customer journeys directly and  indirectly through various customer proxies (Sales Account Managers, VMware Consultants and Technical Account Managers (TAM), etc) we find that customers are in one of three stages that we are going to call:

• IT Production
• Business Production
• ITaaS (IT as as Service)

There is also a stage zero where companies just experiment with the technology. I am not going to address this phase here. I am concerned with projects that take virtualization into production like with all the customers we interviewed in the journey project.

The chart show all key elements for adoption: Sponsorship/ownership, Confidence and Value. These evolve pretty significantly over time with two major inflection points along the way.

Each of these three stage is worth its own post. In this article I will address how the journey evolves at the high level.

IT Production

This is the Cost-Efficiency phase, building the core technology and skills base by virtualizing IT-owned applications, and benefiting from the value of server consolidation.

Sponsorship/Ownership
In the IT Production phase, IT organization virtualize what they own. In fact at this stage it is not really a matter of sponsorship, it is more matter of ownership. They are comfortable with the technology from previous experimentation or deployments and they are now ready to virtualize the applications where they don’t need to ask permission to the business.

Confidence
At this stage, confidence can be characterized as reactive. The team reacts to a business trigger such as hardware refresh or data center consolidation by using virtualization technology. They typically deploy the VMware hypervisor and the core management platform and they start virtualizing the low hanging fruits: File,Print, Web servers, domain controllers, Test and Development servers. At this stage they are building up their virtualization skills. They don’t tackle applications that are perceived to be riskier or that require them to fight tricky political and cultural battles. Just not yet.

Value
The predominant value proposition in this phase is consolidation of IT infrastructure to save on hardware, space and cooling. Customers also end up with some nice by-product and capability such as faster provisioning, a better storage infrastructure (required to deploy VMotion and other useful virtualization features). This creates the technical and knowledge platform to target more interesting applications and for future growth.

Business Production

The Quality of Service phase, tackling business applications (such as Microsoft Exchange, SAP, Oracle Apps, Databases etc) while adopting more of the VMware product stack (such as DRS, SRM or View) with a rapid switch of the value proposition towards better SLAs, business continuity and overall quality of service.

This is a major chasm that customers have to cross on their way to high level of virtualization penetration. I will probably spend multiple articles on this phase in the future, addressing triggers, obstacles, best practices and examples. This is just a quick summary.

Sponsorship
In the Business Production phase, the IT organization which is driving the virtualization agenda needs to find new level of sponsorship for the journey to progress. They have virtualized all the low hanging fruits, everything that they owned. Next step: business applications.

To do so, they now need to get the “Application Owner” on board. Application owners bring about new concerns besides saving money by consolidating servers. They care about performance, lowering risk, quality of service, time to market for new versions of the application, business continuity, planned and unplanned downtime. This is why every single customer we talked to who is in this phase learned how to address these concerns by painting a different value proposition than just server consolidation. They use VMware product features such as SRM, High Availability (HA) and Fault Tolerance (FT) to provide better quality of service (and performance) for their business applications running in a virtual environment.

Confidence
Confidence can be characterized as selective at this stage. The team carefully selects the first applications to virtualize based on a path of least resistance for their organization. “Do I have a good relationship with that application owner?, “Do I have skills to virtualize the application in question?”, “What are the risks associated with virtualizing it?”, “What are the risks associated with NOT virtualizing it?”, “Does the ISV support the application in a virtual environment?”, “Is there a compelling reason to virtualize this particular app (lack of HA, deploying a new version, non-satisfactory uptime…)?”…

Often the seed for virtualizing a business application is planted when a new version is being developed and tested. This process may already be happening in a virtual environment and when the app is going into production, deploying it on a physical server introduces a risky architectural discontinuity. It often makes sense to just leave it running in a virtual environment and take it into production.

After the first couple of business applications are successfully virtualized things get easier, the confidence grows fast and soon the team is ready to take on most business applications. Evangelizing the success and the business value achieved is a critical success factor in this stage. We found that customers do very creative things to make this happen. I will share some of these stories in the upcoming posts.

Value
In this phase the predominant value proposition is quality of service along pillars such as business continuity, lower downtime risks, faster provisioning, time to market and so on. It is actually pretty interesting how dramatic is the change in the type of value people associate with virtualization as they make the transition from IT Production to Business Production. More on this below.

Virtualization First Policy

“Virtualization First” policy refers to an IT mandate by which the VMware-based virtualized environment become the default deployment model. Physical servers are only provisioned on an exception basis and only when there is a strong technical or business justification.

Many of the customers we interviewed have such a policy in place but there are differences in when they put it in place and how well they enforce it.

Timing
Some customers put this policy in place very early but they don’t enforce it very well and it is pretty easy to make the case for getting a physical server.

Other customers, put this policy in place for the type of applications that they have experience virtualizing at any of the three stages. In fact, the ability to enforce this policy is highly correlated to IT confidence and maturity around VMware technology.

Enforcement
Some other customers put the policy in place after successfully virtualizing few business applications. At that point virtualization tend to get on the radar of higher level of management in the organization and in the same way as increased confidence influences their ability to enforce the policy, increased level of sponsorship provides even better teeth.  When the sponsorship is at the highest level (such as in the ITaaS Phase), that is the ultimate enforcement and empowering function.

ITaaS

In the IT as as Service phase, virtualization is just part of what IT does. Everything new is deployed on virtual, and the value is all around time to market, process automation, and ultimately business agility.

Sponsorship
In this stage, the sponsor for the virtualization journey is all the way tot the top of the organization (typically the CIO). Tracking the value delivered over time raised the visibility of the virtualization journey and it is now a top initiative for the CIO, sometimes with MBOs associated to virtualization penetration and speed of adoptions for the CIO’s reports.

Confidence
Confidence is very high. Most of the product stack has been adopted, including SRM, DRS, Lab Manager, HA, FT and so on. The virtualization team is often folded back into the core server team as virtualization is just part of what IT does.

Value
At this stage organization are looking to scale their virtualization effort so that they can in turn scale the associated benefits that come from process automation, better resiliency, and increased quality of services.

Some customers refer to this state as their “internal cloud” when resources can be allocated on demand where and when needed. IT is nimble. Their credibility has improved throughout the journey and (in their own word) their quality of life is better. They don’t obsess about hardware failures because they know they can move the impacted VMs around. They use DRS to automatically increase resource allocation on the fly. They have a Disaster Recovery (DR) strategy or even a complete solution in place. They are looking at or implementing their desktop virtualization roadmap.

Conclusions

These are the three main stages that characterize most customer virtualization journeys we have seen: IT production, Business Production and ITaaS.

The adoption is driven by IT confidence, level of sponsorship and tracking the business value delivered by each project.

There is a major chasm/inflection point around the time customers move from virtualizing IT infrastructure services and tes/dev servers to their first business applications. When they do cross this chasm, the value proposition that they track, perceive and sell internally radically shifts from server consolidation and CAPEX savings, to better quality of service, OPEX savings and better business continuity.

What’s Next

In the next few posts I am going to

• Talk more about the value path for virtualization and what is the relationship between business triggers, product functional areas, capabilities and value
• drill down on each phase and use specific examples to talk about obstacles, best practice, evangelization techniques and so on

Ciao

Vittorio

The Journey stages I discussed in this post cover most of the customers we interviewed so far.

There are few exceptions. I talked about the case where customers start their journey in the Business Production phase virtualizing production databases. A minority.

There is also another pattern that is notably different: ISVs (Independent Software Vendors).

ISVs make software for a living, so optimizing their Dev, Test, QA environment is mission critical for them. Moreover the number of test and dev servers they own typically outnumbers the servers they use to run their business.

As a result their stage I (test and dev) is both much prolonged and much bigger in scale. One may say that they reach stage 3 which is typically characterized by >50% virtualized servers without ever going through phase II (Business production).

For example, I interviewed a large ISV last week. They have 18,000 test and dev servers vs. <200 servers that run business applications. They virtualized 50% of their test and dev servers saving north of 20 million but they have not tackled their business applications yet. In a typical enterprise customer scenario when the virtualization percentage reaches 25-30%, that’s when customers typically start virtualizing business applications and databases switching the value proposition from server consolidation to better SLA and business continuity. In the ISV example above, virtualizing more test and dev is where they are going to get the biggest business benefits as they are vastly improving their development efficiency and the quality of their software while at the same time cutting support and hardware costs.

Besides aggressively virtualizing more test and dev servers on their way to 100% virtualized environment, they are also increasing the level of provisioning and management automation by deploying self-service capabilities. Their  target is 30% self-service penetration within a year.

In summary, although the three stages of adoption apply to most enterprise customers, there are exceptions that highlights interesting use cases and best practices.

All scenarios seem to have one thing in common thou: what drives high level of virtualization adoptions are clear business drivers that are beyond server consolidation.

Vittorio

Now that I got your attention…. let’s talk about a couple if customer interviews where virtualizing production databases came up and the first step of their journey.

In the Customer Journey stages post, I covered how the majority of the customers we interviewed start their journey in the IT production stage where they virtualize test and dev servers and IT infrastructure applications like file, print, domain controllers and so on.

There are exceptions. The more interesting one is when some mid-size companies (say 1000 to 20,000 people)  start their journey virtualizing critical production databases. I personally talked to two of them and heard about others from our system engineers.

Why do they do that? Most customers virtualize production databases and business applications in what we call the Business Production phase. What made these other customers start from databases?

There are tons of material about how to best virtualize database on VMware. In this post I want to cover what I learned from a business perspective from these two aggressive customers.

Biggest Bang for the Buck

Both of the customers I talked to said that virtualizing databases would give them the best bang for the buck based on better management, better performance, better quality of service. DB License saving was also mentioned as a factor.

They both sold the project internally around, and I quote:

“Databases will run faster and will have better management and instantaneous failover capability”

“I wanted to give my customers (the business owners of these databases, that is)  more memory, more network and more CPU, VMware running on updated hardware allowed me to do that”

“I demonstrated and documented that performance was going to be better in the new virtualized environment”

They did not sold the value proposition of server consolidation, although it was definitely a factor.

So, how does a database run faster in a virtual environment? Well, most of these databases were running on relatively old and under-utilized machines. By upgrading them to a new modern server running VMware, these customers could allocate more resources to each database instance therefore achieving better performance.  Moreover, thanks to VMware HA and FT, they could provide their internal customers with better business continuity without deploying more complex clustering solutions from the database vendors.

Although consolidation was not the main driver, one of the two customers went from 200 physical servers down to 25. He said he was not too concerned with the consolidation ratio anyway as he wanted to keep some performance buffer in there just in case. The intent is to be more more aggressive at the next refresh cycle once he has more data about how the databases perform over time. This is definitely a best practice we heard form many customers in the Business Production stage.

Everything Else Will Be Easy

Both customers said that one of the reasons they chose production databases as the starting point of their journey was that by making them work they would get instant credibility for their team and for virtualization. This would make it easy to virtualize less mission critical workloads going forward and would take the FUD about virtualization off the table for ever.

It is not by chance that both customers have a >80% virtualization penetration and are working actively to get to 100%.

Confidence+Sponsorship

How did these customers jumped stage one (IT Production) and be successful?

As covered in the this previous post, the key drivers of successful virtualization journeys are Sponsorship, Confidence and Value. Both customers had the three elements taken care o:

Confidence
Both technical leads where highly competent, credible and involved in the technical details.

They both formally trained their teams, and not just the server team but also network, storage and security. One of them did not trained the network guys initially and regretted it later and some of the network architecture had to be redesigned later in the process. This is too a best practice. Formally train the team on virtualization across multiple disciplines.

Sponsorship
Both technical sponsor were very senior in the technical ranks and had a direct path to the CIO who was involved from the beginning and both formally reported the technical and business results achieved to the top.

Value
Both customers skipped the IT production phase where the prevalent value proposition is cost savings from server consolidation and went directly to phase two. Interestingly, the value proposition that they used to sell the project internally and to track the business value delivered was around business continuity and quality of service. This is very consistent with other customers who got to stage 2 after going through IT production first. The difference is that these two customers moved much faster in their virtualization journey after establishing their credibility virtualizing mission critical databases in their first project.

Conclusions

I would not suggest to start the virtualization journey from production databases to most customers, but now I have seen it work for some.

Maybe we should create a swat team at VMware that goes around and does this full time. A way to accelerate the journey?

Vittorio

More information about virtualizing SQL Server here: http://www.vmware.com/solutions/business-critical-apps/sql/

and Oracel DB here: http://www.vmware.com/solutions/business-critical-apps/oracle/

In the “Key Adoption Drivers” post, I covered what the main drivers for virtualization adoption are and in the “Virtualization Journey Stages” post we saw how the virtualization journey evolves along three main stages that are characterized by:

• Different type of applications being virtualized (IT infrastructure, test and dev, business applications, databases…)
• Level of organizational and process maturity
• Different business value delivered

The three stage framework represents the first axis of the virtualization journey adoption:

Business Value Evolution

One of the most interesting findings from our customers interviews was how the value proposition that virtualization delivers evolves across the journey. Mind you, I am talking about what customers told us, not what VMware marketing says.

At the beginning of the journey (IT Production), it is all about cost efficiency around server consolidation, space, power and cooling savings.

When customers enter into the Business Production phase and they start virtualizing business applications and production databases, the value proposition is all around better quality of service and business continuity. This shift is sudden and dramatic. It is like cost savings from consolidation is taken for granted at this stage and customers switch their focus on faster provisioning, better capacity management, reliability and process automation for their business applications.  This is where features such as High Availability (HA), Fault Tolerance (FT) and SRM become important.

At the right side of the journey, it is all about business agility. Customers are on a path to virtualize as much as they can of the IT environment so that they can scale up the benefits derived from virtualization and achieve more process automation, faster time to market, and dynamic allocation of resources to cope with varying demand. This is the stage that gets them closest to running a private cloud. More on this in later posts.

The Second Axis of Adoption: the VMware Product Stack

The journey also evolves along a second axis: the VMware Product Adoption that is which functional areas of the VMware product portfolio a customer deploys overtime.

There are five main functional domains in the VMware product portfolio (pre-SpringSource acquisition):

• Infrastructure Consolidation (ESXi and core vCenter)
• Application Development Quality and Efficiency (Lab Manager)
• Cost Effective Availability and Disaster Recovery (SRM, HA and FT)
• Desktop Security, Mobility and Support Efficiency (View, Workstation)
• Virtualization Efficiency and IT process Automation (DRS, Lifecycle Manager)

The core platform  with ESXi and the basic management capabilities of vCenter provide the foundation for hardware abstraction, consolidation and CAPEX savings along the whole journey. To unlock the higher level business value of virtualization, customers need to adopt and deploy the upper layers of VMware product stack.

SpringSource add some very nice application management and monitoring capabilities with Hyperic, a lightweight development framework (Spring + Tools) and a lightweight run-time container (tc Server).

Although adoption stages and product adoption are somewhat related (e.g. customer who virtualize mission critical applications tend to aggressively deploy features such as HA and FT),  each customer will follow their very own path in deploying the different functional areas of VMware’s product stack. The path mainly depends on what their business triggers are (e.g. running out of data center space, hardware refresh, security compliance on the desktop) and their business priorities.

Business Triggers to Business Value Framework

As part of our customer journey project, we built a taxonomy to map triggers to functional areas, to capabilities to business value. This is how we help customers define the custom journey that best maximize business value returns based on their set of triggers and concerns.
To do so, we first enumerated all the business triggers that are relevant to virtualization; then we mapped which product area addresses each business trigger. From there, we listed all the capabilities and the business values that each product area delivers.

This is the high level view of triggers-to-business-area mapping by stage:

And this is the drill down for the set of triggers the typically spark the deployment of Lab Manager.

And the related capability and value mapping

In the next posts, I am going to show how we use this framework to build a customer adoption journey and then how we calculate the ROI across the different business value categories: Cost Efficiency, Quality of Service and Business Agility

Virtualization Journey Q&A Podcast

Today I had a great Q&A session with members of the VMware community about the virtualization journey. The call was facilitated by John Troyer who runs our VMware community and it has been recorded here.

Lively exchange of ideas and great feedback!!

I covered the key elements that drive the adoption of virtualization technology and the three main stages of the journey, then we had a great discussion about adoption obstacles, sponsorship, and organizational structures.

A coupe of takeways

Controversy

When I present our findings on the virtualization journey, there is often controversy around the Business Production phase. As a reminder, the business production phase is when customers virtualize mission critical business applications and databases. This is when IT operations work side by side with Application Owners (e.g. the person who is in charge of running SAP) to virtualize business applications. entering this stage is a critical inflection point as virtualization moves from being an effective tool to consolidate servers (and save power, space and money in the process) to a computing platform that provides better business continuity, disaster recovery and improved SAL (Service Level Agreement).

Some of the best practices that we heard people use to tackle this phase sparkle some very animated debates.

My favorite one is the following:

Best Practice #1:Publish a Roadmap

According to this best practice, when you virtualize business applications you should always tell the application owners and LOBs why you are doing it and what’s in there for them. Many customers do this. They publish a roadmap, they get the app owners comfortable, they execute, track results and share the success stories with other LOBs.

Best Practice #2: Don’t Tell Them

In this best practice, IT just does it. They virtualize business applications and they don’t tell the app owners. Their attitude is “they (LOB) should tell me how to run my infrastructure. I know this technology works and I just do it”.

We absolutely heard both practices applied successfully by different customers. When I bring this up people react violently to either #1 and #2 above. I believe it depends on their level of confidence (the more confident tend to just do it) and level of maturity. In any event, this controversy came up three times in three presentations I did on this at VMworld, with a delegation of CIOs yesterday here at VMware and today during the podcast.

I am just reporting what I heard from customers. Different strategies for different customers.

CIO-Level Sponsorship

The level of sponsorship for virtualization projects evolves over time from lower levels in IT all the way to the CIO at later stages. Today when talking about the Business Production phase, I mentioned that some IT organizations have to convince one application owner at the time about going virtual. Somebody in the audience was very vocal about the fact that companies should go through this phase with a mandate form the CIO in place. This provides the right air cover to address the skeptics objections and move forward swiftly. I could not agree more. The fact is thought that many customers don’t have that top level mandate at this stage and they consequently struggle.

This is an area of focus for us as a company going forward. More on this later.

Keep the feedback coming.

Ciao

Vittorio

In my previous post I wanted to talk about the project I am working on at VMware and why I am about to hit the road and go listen to a number of customers. I ended up rambling about how to listen to customers, what to listen for and so on and never got to describe the project. So here it goes.

VMware has a huge number of deployed customers that have virtualized all kinds of workloads (a term we use to describe what runs within a virtual machine). As it often happens, customers are using our technology in ways that we may not have anticipated.

Also, some customers have been more aggressive than others about their use of virtualization technology and have virtualized most of their infrastructure, while others have virtualized 1000′s of servers but mostly within the realm of a given type of workload (say web servers).

The Journey

The main question we are trying to answer is: what is the typical virtualization journey?

Is there a typical journey in the first place? Is there one by industry? Company size? Workload type?

In my first month here at VMware, I talked to many smart people (primarily people close to the customers such as in professional service, system engineers, sales etc) and I got some good answers to the above questions. What I want to do now is to go directly to the source and find out from our customers and from their perspective how they achieved high level of virtualization and why.

A Different type of Listening

If you read my previous post on listening to customers, it was inspired by years of working in either a product management or product development capacity. In that context, I was typically meeting customers to validate a new product idea or gather input for a new release of an existing product. This time is different.

I don’t have an idea to validate or requirements to gather. I don’t really have a preconceived notion of what I am going to find out. I am just going out there, listen and learn what our customers have done with VMware technology.

This is not going to be a quantitative type of research. It is going to be qualitative. We want to find out

• When – the project started and finished
• Why – the project got started
• What – was virtualized
• What – products were used
• How – it was done
• Who – drove the project
• Who – helped
• Who – sponsored it
• What – were the technical and business results
• What – processes and organizations changed as a result
• How/When/Why – the project influenced the next one

This last point is critical. We really want to understand the relationship between multiple virtualization projects and how  they come together in an overall journey (when they do).

We selected a number of customers in different geographies and in different stages of virtualization adoption. Cant’ wait to meet them.

Let the learning begin!!

Vittorio

I am excited!! I am about to hit the road and go talk to a bunch of customers.

As I typed the above sentence, I just remembered of a funny episode. When I was at BEA one of the product managers in the team said something along the same lines “I am going to go talk to a bunch of customers in preparation of planning our next release”. Adam (Bosworth that is) was in the room, looked at him and went “Talking to customers is fine, but the question is: are you going to listen to them?”

This is indeed the point: listening to customers.

Listening, not that Simple

But how do you listen to customers? When? How often? Which customers?

There is no simple answer. It depends on the product (Saas or Enterprise, Application or infrastructure…), the stage of a product (product idea, beta version, 1.0 version, mature product, disruptive technology, …)

Some examples:

SaaS

Web-based applications (well, most of the ones worth using at least) have spoiled us end-users over the last few years by listening to us and evolving their services quickly to meet or sometimes exceed our expectations. The ones who didn’t, are not here with us anymore (check out this great talk about this very topic from Adam).

SaaS type of applications have an advantage over traditional enterprise applications and infrastructure products. Once an SaaS application provider makes a bet and launches the app, they can closely measure what customers use, what they like and dislike and they constantly improve the application or service. They can deploy a new version quickly, sometime weekly. A great model.

If a company has a reasonably low cost way to get a prototype out there, it it a great way to get started, measure what customers do with it and improve the product.  But there is always the risk of making a bad first impression and damage the company brand. Focus groups can help but again it is not that simple. I heard (but I am not sure if it is true) that when Apple did focus group around the iPhone concept, the feedback was not very good. If true, this is a case where the customers didn’t know what they wanted until they saw it. This is what startups and people working on brand new products try to do. Go figure out what customers need but they don’t know it is possible or don’t know it is coming. The good ones listen carefully, discover the pain, understand technology trends (sometimes they create them) and intimately know the type of talent they have in the R&D lab. They project the pain one year out, make a bet and go. They walk a fine line between innovation, intuition and… yes, arrogance. We all have our share of failed arrogant bets…

Enterprise Applications and Infrastructure

Enterprise applications and infrastructure products on the other end have a harder time learning from customers and improving rapidly (emphasis on rapidly). This is mostly due to the development-sell-deploy-upgrade cycle that is typical of enterprise software. It may take years from when a product is first conceived to when a customer deploys it in the real world. Even worst, even when enterprise software companies do a good job listening to their customers and make improvements to their products, it takes time for customers to uptake new releases. Software development companies can make the upgrade process easier and minimize disruption by keeping the software backward compatible, but still…

In my experience enterprise customers want predictability, support and compatibility.

• Predictability: customers want to know that they can rely on a new release being available at given interval of time. 12-18 months is typically fine for enterprise software.
• Support: they need to have their problem fixed on the release they are on. The DO NOT want features (even small ones) in service packs.
• Compatibility: 100% compatibility for patches and service packs is a must. 100% backward compatibility on minor releases is also a must. 100% backward compatibility for major releases is ideal but costly.

Unfortunately, it is hard for disruptive technologies and products to satisfy the above requirements (isn’t that why they are called disruptive??).
Even when evolving mature products the requirements above are costly to meet. But mind you, history is full of product failures due to taking shortcuts on these important issues.

These considerations are relevant to the topic at hand, because one has to take into account the stage a product is in when listening to customer requirements.  If you are building a brand new product you can be more aggressive about number and size of features, disruption (as long as you let the customer know in advance that things are bound to change). You can make bets and do things the customer may not have asked for. They may not know what’s possible with your engineering talent.  After shipping, go find the early adopters and listen to them. Go find people who did not buy the product. Listen them them too. Carefully.

If it is a mature product with a large install base, these

Quality is a feature. A big one. Taking shortcuts on quality is the sub-prime mortgage of software development… and the bailouts are costly. Very costly. Foreclosure a definite possibility.

Choose Your Customers, Choose When to Listen

Is it always a good idea to listen to your customers?

Mostly. There are exceptions.

For example, after you have gather enough requirements and you think you know what you want to build, it is ok to stay inbound focused for a while, develop the product util you reach some sort of end-to-end milestone. Then you can hit the road again and go show it to customers and get early feedback. Talking to customers in the middle of a developent cycle maybe defocussing unless you are doing scrum, in which case you are supposed to be able to show a fully running product every 2-3 weeks.

Another example is when you keep going back to the same customers or to the same group of people within a customer IT organization. For example, say you built a development platform and you keep going back to developers for more requirements. You may be just marginally improve the product by adding more developer-oriented features while you are missing out on a great market opportunity by not adding management features targeted at the operational staff. Go find who else uses your product maybe in different stages of the product life-cycle at the customer site. Listen to them too.

Also, if you are trying to disrupt a given market and you listen to the people who have been traditionally involved with it (analysts, system integrators and customers) they may stir you into build yesterday’s product. Not tomorrow’s.

Internal Customers

Eat the Dog Food

There is a great way to shortcut the time it takes from building a product and getting customer feedback. Use the product yourself internally. Some companies do this very well. Amongst the companies I worked at, Oracle and VMware do it very well. BEA did it to a lesser extent. Listen to your internal customers with the understanding that they may to be an exact representation of your actual customers (e.g. you have a number of hard core system developers in your staff, while your customers are higher level application developers, your internal customer have better access to your team resources, your customer don’t).

If you are not using the product yourself, why not????? You better have a great answer for this question, or go back and DO use your product!

Support and professional Service

The support and professional service  organizations are great proxy for customers. Listening to support people will give you a great idea about trends, quality, release adoption, customer satisfaction as well as great requirements for better product supportability.

Your colleagues in the professional service are the ones to know how customers use the product in the real world. they keep it real. They keep you honest.

Sales and System Engineers

If you have a direct sales force,  account managers and systems engineers are your customers too. They feel the pain when the product does not sell and have often have great insight into why it is not selling. Listen to them but not too closely. Sometimes they require you to disrupt product plans to chase short term quarterly revenue. It is not always a good idea to do so.

Conclusions

Ah! What a great topic. I just realized that I still have to explain why I am going to talk to… sorry, I mean listen to some VMware customers. It is actually not about gathering product requirements (although it is inevitable that I will stumble on some). It is for a different and very interesting purpose.

Next post.

Vittorio