After explaining and giving examples of VSM, I had the class participants map out their most troublesome processes. The IT practitioners in one group chose to map out the way they created a new development environment for their software engineering customers. They wrote down the steps in the process, then determined how much time it took to complete each step and how much time it took between steps.
When all was said and done, it was taking them 43 days to create a new development environment.
Forty-three days? That's a lifetime for software projects. As they described the various process steps, the waste became obvious. After they finished their description, I told them it seemed to me that they could greatly simplify and shorten the process if they used virtualization to create their development environment. That's when they hit me with the real shocker: "Niel," they said, "this is with virtualization."
"With virtualization? How long did it take to create a development environment before you started using virtualization?"
"Hmmm, I guess around 43 days."
This group had virtualized their servers and storage, then treated the creation of each virtual environment as if they still needed to buy a server, buy storage, get approvals for the capital investment, configure the servers, configure the storage, test the servers and storage -- and get all this work approved and prioritized. In other words, virtualization had changed nothing and was not generating any real value.
Going back through their process map, we eliminated the steps that assumed equipment acquisition and configuration and the associated approvals. When the dust settled, it turned out they could create a development environment in about 30 minutes. Forty-three days to 30 minutes: Now that is an agile IT organization.
Too often we let legacy processes and thinking drive how we use virtualization. On another occasion, I met with an IT team that was complaining about their underused virtual environments. Their software development and application support groups were constantly asking them to create new virtual development and test environments. The developers and application support personnel would use these environments for a while, then seemingly abandon them. The IT operations crowd wanted to limit users' ability to request new virtual environments -- after all, they had plenty of environments they weren't using.
I asked this group if their approach -- limiting the ability to get new virtual environments -- was what they would do if there were underused physical environments.
"Absolutely!" they answered.
I then asked them if this same approach made sense in a virtual world. Now there was some hesitation.
I went on. "First of all, is this farm of underutilized environments causing any problems? Are these development and test environments taking capacity away from other uses? Or do you still have enough virtual server and storage capacity to exceed current needs?"
More on virtualization
"No, we still have plenty of room -- but it might become a problem eventually."
I paused for a moment: "If there are no capacity opportunity costs, these unused environments are not costing you anything. But to avoid an issue in the future, how about you generate a monthly report for software development and application support detailing which development and test environments aren't being used. You can then ask them to identify which ones they no longer need."
They agreed to give it a try. Within a couple of months, the issue had resolved itself.
IT operations in a virtual world are different from operations in a physical world. We obviously want to avoid a proliferation of unneeded virtual environments. On the other hand, we want to take advantage of the inherent capabilities of virtualization to improve our responsiveness to the dynamics of our business and to improve customer service.
Niel Nickolaisen is CIO at Western Governors University in Salt Lake City. He is a frequent speaker, presenter and writer on IT's dual role enabling strategy and delivering operational excellence. Write to him at firstname.lastname@example.org.
This was first published in October 2011