Virtualization Journey: Product Adoption

December 3, 2009

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 post, 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

Leave a Comment » | VMware Product Adotpion, Virtualization Adoption Phase, Virtualization journey, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

VMWare Community Interview and QA

October 22, 2009

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

3 Comments | Virtualization journey, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

Virtualization Journey Stages

September 25, 2009

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
  • Virtualized IT
Virtualization Adoption Stages

Virtualization Adoption Stages

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 Virtualized IT Phase), that is the ultimate enforcement and empowering function.

Virtualized IT

In the Virtualized IT 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 Virtualized IT.

Virtualization Adoption Stage - Detailed

Virtualization Adoption Stages - Detailed

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

2 Comments | Virtualization journey, vmware | Tagged: , , , , , , | Permalink
Posted by vittorioviarengo

The Virtualization Adoption Journey – Key Elements

September 15, 2009

As covered in previous posts, a VMware team of 3 people and I spent the last 4 months listening to our customers and learning how they move through their virtualization journey.

In the next many posts, I will share what we learned and I am looking forward to learning even more from the customers who will take the time to read these posts and share their stories.

The Key Elements

Across all the interviews that we did, we found that there are three key elements that drive successful adoption of virtualization technology:

Confidence, Sponsorship and Value.

Virtualization Adoption - Key Elements

Virtualization Adoption - Key Elements

The basic idea is that Confidence and Sponsorship (or ownership, more on this in later posts) drive adoption. Adoption delivers value that comes in the form of

  1. New capabilities/outcomes that benefit IT and the business after completing a project (e.g. faster provisioning time, better up-time, interruption-less hardware maintenance…)
  2. Business Value (e.g. Capex and Opex savings) derived from the achieved virtualization outcomes

1) feeds IT confidence, 2 feeds  sponsorship confidence which in turns gives IT the ability to get better and better sponsorship over time and funding for virtualization projects.

These three key elements don’t drive adoption in a vacuum. Each project is triggered by some sort of business or technical event such as running out of data center space, a hardware refresh and so on. We are going to call these Business Triggers. We are going to talk about type of business triggers and their impact on virtualization adoption and stages extensively in future posts.

This process is actually not unlike other technology transformations that IT organizations have dealt with over time. I will spend the reminder of this post articulating the specifics of how these elements relates to virtualization technology and its adoption within our customers.

Confidence

Confidence here refers to the confidence the IT team has in using virtualization technology. There is a clear correlation between IT confidence and how aggressive they virtualize their infrastructure.

Despite all the success that VMware products has had in the marketplace, there are still people out there that don’t understand virtualization and its value completely. I was one of them when I started here 6 months ago, virtualization sounded like magic to me. At times, this creates skepticism and resistance to adoption.  This is where the confidence and the credibility of the IT come into play.

IT teams who have been formally trained and have been deploying VMware technology successfully in the past are more effective at virtualizing increasingly more business critical systems and applications and break through skepticism. The ones who have adopted the more advanced VMware features such at SRM, Fault Tolerance, High Availability and SRM tend to have the highest virtualization percentages as they quickly move beyond just consolidating servers into providing better SLAs and disaster recovery capability for mission critical applications.  I will spend more time and posts to talk about this concept as it is one of the biggest lessons we learned from our customers.

Virtualization is much more than server consolidation. It is a transformational technology that allows IT to become nimbler, provide better application SLA (Service Level Agreement) and up-time for mission critical applications, lower their OPEX, shorten time to market for new projects and applications, simplify desktop management and ultimately increase their quality of life

I know that above sounds like a VMware marketing slogan, but it is in fact what we heard from customers and in the next few posts I will give you examples and anecdotes in their own words.

Here is a funny video produced by one of our customer that nicely makes the point:

Sponsorship/Ownership

The second key element of virtualization adoption is sponsorship. In the customers we interviewed, there is a direct and strong correlation between whether the CIO is  involved with the virtualization effort and the degree of virtualization they achieved (and in turn the business value they got in return).

Many virtualization projects start below the radar within the IT department. At this stage it is not even a matter of sponsorship but a matter of ownership. IT virtualizes what they own. They see the advantage, they apply the technology, the enjoy the benefits. They don’t have to ask for permission. As virtualization adoption grows, new levels of sponsorship are required for the journey to move forward.

One of the major inflection point is when IT virtualizes the first business application. I will spend a whole post on this later. The key here is that when IT does that, they have to deal with a different sponsor. The application owner. The person whose job is to deploy and operate a given business application such as Microsoft Exchange or SAP and often their counterpart and stakeholders on the LOB (Line Of Business) side.. This new level of sponsorship requires more sophistication on the part of IT both in term of confidence as well as understanding the different set of issues that application owners care about. They don’t care as much about consolidating servers. They care about how quickly they can deploy a new version of the application, how they can improve the application SLAs and up-time and so on. As IT goes on and virtualizes increasingly more mission critical applications and they realize value that goes way beyond server consolidation, the sponsorship goes all the way to the top of the organization, typically to the CIO.

Customers who have not successfully obtained these increasing levels of sponsorship, have stagnated at low level of virtualization or have moved their journey very slowly.

Value

Value is the third key ingredient of a successful virtualization journey. Customers who have progressed steadily have done three main things related to value:

  1. They tracked value delivered by virtualization projects. Some established key metrics that they reported on the regular basis. Other did it project by project. Others built MBOs for their managers around virtualization targets.  In any event, most of the more successful customers have formally tracked value to be able to get better level of sponsorship and justify new projects (and why not, get a fatter bonus)
  2. They evolved the type of value they tracked over time. This means that as they progressed their journey, they went from tracking mainly hardware cost savings to also account for data center space, power and cooling savings, operational efficiency gains (e.g. faster provisioning), increased application uptime, all the way to desktop support efficiency and security, application life-cycle and quality improvement, and faster time to market for new applications.
  3. They shared and celebrated the value. Customers have shared both outcomes and value delivered by virtualization projects to their management team but also across organizational barriers to spread the word about the benefits of deploying virtualization technology and running business applications in a virtual environment. We have collected all sort of evangelization techniques in our interviews. I will share them on this blog later.

Some customers have actually gone back to previous projects and calculated the value delivered even months past the end of the project to show to themselves and their management the benefit of virtualization and get air cover to scale the effort going forward.

The key point here is that effective virtualization journeys require a strong and credible framework to track value over time. We do want to help our customers doing this and as part of the customer journey project we have enhanced our ROI calculator to enable customers to predict and then measure the business value delivered by virtualization projects.  This enhanced ROI calculator takes into account the different business triggers, the cost of adopting virtualization technology, the time it takes to deploy it over time, the type of assets being virtualized etc. Again, more on this later.

Ignore these Key Elements at Your Own Risk

Customers who have overlooked any of the above elements experienced either a slower journey, are still stuck at lower virtualization percentage or ran into painful setbacks.

Without the right level of competence and experience (which combined give you confidence) you can make technical mistakes which can stall your journey.

If you don’t track success, outcomes and value delivered, you are going to struggle to spread the word and break through potential skepticism.

If you don’t learn how to address the concerns of different type of application owners and stakeholders, you don’t get the right level of sponsorship which will ultimately slow down your journey.

We have seen a combination of all of the above is some of the customers we interviewed and we learned how they recovered from black eyes (it takes time BTW), what tactics they used to evangelize the value of virtualization and the internal cloud within the organization, how they used different layers of the VMware product portfolio to address application owners concerns.

The Adoption Workflow

As you will see in the next few posts, we came up with a model that we believe describes most customer virtualization journeys. For sure, it models the over 30 journeys of the customers we interviewed directly. .

Here I want to double click on the “Adoption” box in the figure above and introduce the workflow that describes an individual virtualization project.

Virtualization Adoption - Workflow

Virtualization Adoption - Workflow

  1. Business Triggers: a project is typically started in response to some sort of business or technical trigger. Good examples are: hardware refresh, operating system refresh, data center move or consolidation, mergers and acquisitions etc.
  2. VMware Functionality Ares: depending on the business trigger, the customer then selects the VMware product area that better responds to that trigger. For example a disaster recovery exposure would be addressed by the deployment of SRM, a desktop management challenge would be addressed by deploying VDI and so on
  3. Assets List: then, one needs to identify what type of assets and applications are being impacted.
  4. Confidence Check: At this point the question becomes: does IT have previous experience virtualizing these type of assets using the required VMware product areas? If not, then training, a proof of concept (POC) or consulting is required.
  5. Obstacles: once the confidence is there, it is a question of addressing obstacles (do we have the right storage solution? are all stake holders comfortable? …),
  6. Best Practices: then applying best practices for the project at stake (in this day and age, we are typically hard pressed to find applications that have not been successfully virtualized by somebody out there)
  7. Outcome+Value Calculation: At the end of the project, one must assess the project outcomes (faster provisioning, better uptime, increased capacity for future growth etc) and calculate the business value delivered by these outcomes
  8. Report, Evangelize, Celebrate: finally the team must celebrate their success and evangelize project outcomes and value delivered across peer organizations and with upper management.

We found that most projects can be modelled this way. The two pictures above call out both the key elements that drive virtualization and the major factors that one has to consider when carrying out a virtualization project.

What is Next

In the next post I will cover the three stages of virtualization as we heard it from our customers and explain how the  dynamics between confidence, sponsorship and value change as the customer virtualization journey progresses over time across the three stages. We will also share the taxonomy we came up with based on our customer interviews to catalog business triggers, product functionality areas, capabilities/outcome, related metrics and the different type of value delivered by virtualization.

until then, ciao

Vittorio

3 Comments | Virtualization journey, vmware | Tagged: | Permalink
Posted by vittorioviarengo

Back from the Customer Tour

August 18, 2009

I have been on the road for the past 6 weeks listening to customers. It has been a lot of fun. We learned a ton!!!!!!

The team that has been working with me and I have collected a lot of information about our customers virtualization journeys. We are now in the process of analyzing the data and putting together content to describe what a successful virtualization journey looks like and what business value it delivers.

This tour reminded me of how refreshing and important it is to listen to customers on a regular basis. I pride myself of having done this all my career, from the my youth working in my parents bakery to my days in IT. This time around it was different thought in scale and format. Never had I spent this much time meeting with so many customers in one single project and rarely had I been in a mode where I was not selling or defining a new product.

This time I was just listening, carefully to the words of the customer.

We interviewed more than 30 customers, from Fortune 500 to SMB. We met with system administrators, directors of IT and CIOs. We wrote it all down, analysed it and and identified:

  • Common adoption patterns
  • Virtualization adoption drivers
  • Business and technical triggers
  • Best practices
  • Organizational implications
  • Common mistakes
  • Internal evangelization techniques
  • Obstacles
  • Typical outcomes
  • Business value tracking techniques

We also came up with a model that we believe captures and describes each of the journeys we heard from our customers.

Think of it as an algorithm that plots the main phases of adoption, what triggers each project within each phase, what is the technical outcome (capability) resulting from each phase, who are the stakeholders and sponsors, and how to calculate the business value delivered at each stage.

What we want to do now is to share the learnings and best practices back with all our customer. This will happen through a variety of channels starting from our VMworld User Conference in San Francisco the first week of September.

Also, I will devote the next posts to describe each of the virtualization journey phases in details and I am going to try hard to use the very words of the customers. No marketing or vendor mumbo jumbo, so stay tuned for that.

Now, back to preparing for VMworld

Vittorio

Leave a Comment » | Virtualization journey | Permalink
Posted by vittorioviarengo

Virtualization Adoption Journey

June 9, 2009

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

2 Comments | vmware | Tagged: , , | Permalink
Posted by vittorioviarengo

Go Talk to Customers, no, Wait!! Don’t! Go Listen Instead!

May 20, 2009

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

1 Comment | Product Management | Tagged: , , | Permalink
Posted by vittorioviarengo

Death by Command Line – NOT

April 29, 2009
 

http://viarengo.com has been running smoothly on VMware for more than 10 days now.

CPU utilization is around 10%  which is common in many IT applications out there.

 

CPU Usage Post Virtualization

CPU Usage Post Virtualization

I am running two virtual machines on the server now:

  • My web site
  • A file server.

Unfortunately I don’t really have the need to utilize the available CPU cycles for other applications. My use case is really about encapsulating a legacy application  to be able to run it in the future in its current configuration on any x86 platform. Eventually, I will want to run it in the cloud (more on this later).

A Pleasant Surprise

One pleasant surprise in using VMware Converter, ESXi and the VI Client is their ease of use. The reason I am surprised is that way too often server software is plagued by the “tyranny of the geeks” syndrome where installing, configuring and managing it is done through “Death by Command Line”.

Don’t get me wrong.  If you read Sriram Krishnan’s post on the tyranny of the Geeks, I am NOT against being accurate and strict at the level where VMware software works. Managing hardware resources is not like the Web where the KISS principle rules  and sloppiness is not only acceptable but often useful as described in this great post by Adam Bosworth.

Also, I do get the value of having command line and scripting interfaces for automated management and the ability to integrate with existing management tools.

What I am talking about is the fact that ease of use and management tools are often an afterthought in server-side software. I remember when I worked at Object Design, we had some really amazing engineers (mostly from MIT). They built an amazingly powerful product (Object Store) that stored ANY C++ structure on disk transparently to the C++ developer. Very powerful and elegant.

The problem was that once you stored your C++ objects into the  database, the only way to get at the data was through the C++ application that put it there in the first place. No browsing, query,  reporting, or visual administration tools. This was good for me as it allowed me and my partners to build a startup to fill these gaps but it was bad for early customers trying to build mainstream applications on ObjectStore.

Born to Suffer

The early adopters of any given technology don’t care as much about ease of use. As I sometimes joke about it with colleagues and friends, the early adopters are ‘born to suffer‘. They kind of like it. They feel empowered by making the product work, cracking the code, finding the undocumented command line argument that does the trick.

The rest of us just get frustrated.  Note that this does not apply to most SaaS applications as the lack of usability prevents them from taking off in the first place.

While it is natural for a new technology to be slighlty  hard to use and lack some of the more mainstream tools,  in my experience it requires a different type of product management and engineering culture to take a product to the next level of usability.  But this is not the subject of this post.

The Simple Baker Usability Test

This post is about how refreshing it was to be able to install, configure, run and administer my VMware instance ALL through the UI of the provided management tools (other than the small workaround to make ESXi work on an unsupported disk controller). No complex command line commands, switches, messing with configuration files, etc.

Although my use case is relatively straightforward, I touched many parts of the VMware stack foundation and tools.

  • PTV (Physical to Virtual) Conversion – VMware Stand Alone Converter
  • ESXi installation – VMware ESXi
  • ESXi Configuration – VMware Virtual Infrastructure Client
  • VM Deployment – VMware Stand Alone Converter
  • VM Creation  – VMware Virtual Infrastructure Client
  • Additional Storage Installation – VMware Virtual Infrastructure Client
  • VM Performance Monitoring – VMware Virtual Infrastructure Client

It will be intersting to go learn from VMware customers what their experience is in more complex IT scenarios.

No “tyranny of the geeks” so far.

Leave a Comment » | Ease of Use, Eat Dog Food, vmware | Tagged: , , , | Permalink
Posted by vittorioviarengo

Virtualization Panic

April 25, 2009

After few days running smoothly on ESXi, I got my first scare.

Here is what happened:

First, I upgraded the Windows XP instance running within the VM to SP3.

Then, I created a new Virtual Machine from scratch on my running ESXi server to learn how to do it.

The idea was to create a new virtual file server and move all my multimedia data into it so that I could shrink the size of my website VM.

Everything worked great. This is the process:

  • Create new VM using the Virtual Infrastructure Client
  • Attach the ISO image of Windows XP to the VM and set it up so that it would boot from it
  • Configure the network to use an available IP address (192.168.1.4); I probably could have used DHCP.

Everything worked just fine. I did everything through the management UI and without reading the documentation. I just had to google how to make the VM boot from an ISO CD image to install Windows XP into it. I also had to mount a floppy disk ISO to install the VMware SCSI drivers for Windows XP. Very straightforward.

I started the copy of the “photos” directory to the new VM partition and I let it run overnight (60GB).

In the morning I realized the the main VM had restarted during the night. I blamed Windows’ automatic update service which I now realize I should have disabled (ah! these simple bakers turned naive system administrators…) .

I blamed Microsoft and re-started the copy operation.

But after a short while……. NOOOOOOOOOO!!!

The blue screen of death

Panic

I guess at this point I experienced what I am sure some customers go through sometime. After being on the virtualization high for getting everything virtualized smoothly, I had my first blue screen of death and paniced a little.

Note that I had very reasonable excuses to:

  1. blame Microsoft because they ‘made’ me upgrade to SP3
  2. blame myself, because I jammed another virtual machine on the same server

But both excuses were scary and lame because:

  1. Virtualization is not supposed to impact your ability to patch and update the hosted operating system
  2. Virtualization is DESIGNED to let you run multiple VMs on the same server. that’s the whole point!!! (plus I was still running at 15% CPU utilization at most…)

So, I armed myself with more patience and confidence in the product and debugged a little deeper. I noticed that the error in blue screen of death was “page_fault_in_nonpaged_area“, so i did some research and found out that this error is sometimes due to faulty memory chips… and I had my aha!!!! moment.

If you remember, when I changed the hard drive in the server, I also added a memory bank that I found in my hardware drawer…

So, I removed it and went back to 1.5 GB RAM and the system is back up and running.

And so is my confidence in VMware products!!!! :)

The Lesson

When deploying a new infrastructure, one needs to be careful about all the moving parts, document everything and most importantly be committed to the change.

I wanted it to work, and I know it works. So I did not blame the virtualization layer and went look for the real cause that turned out to be a faulty piece of hardware.

But what if I was not a champion of the technology and I did not know that it does reliably work in ten of thousands of production installations?

A little glimps into a dynamic that does happen in the relationship between IT shops and their technology and solution providers all the time.

Customers need:

  • Guidance
  • References
  • Commitment and Support

They want their vendors to have their back when they run into trouble

Vendors need

  • A technology champion and commitment from the top within the customer
  • Customer references that provide confidence but even more importantly prescriptive guidance on how to deploy the technology successfully
  • Be there for the customer

More on guidance and commitment later as they core to my first project at VMware.

Leave a Comment » | Eat Dog Food, vmware | Tagged: , | Permalink
Posted by vittorioviarengo

Up and Running on ESXi – Day 4

April 21, 2009

Quick Recap: I installed VMware ESXi on my old desktop (turned server) and deployed the VM file I previously created using VMware Converter standalone.

My web site has been up for 4 days and I am back to my usual average load of 20 hits a day (yeah!!!). The family in Italy is happy that they can see what the kids are up to ;)

viarengo_com_analytics

Using VMware Infrastructure Client I see that the average CPU utilization is 10-15%.

cpu_usage

I did noticed that when I remote-desktop into the server to upload new pictures and configure my web application, the UI is slightly less responsive than it was before I virtualized it.

Now that the system is stable, the next step is to separate the storage from the VM and then shrink the VM size to make it more manageable.

Leave a Comment » | Eat Dog Food, vmware | Permalink
Posted by vittorioviarengo

« Previous Entries