virtualization.info

The Cultural Impacts

The last post covered cost models and changes needed to adopt virtualization, this post will cover the cultural change aspect of the technology within a company.

As typical with technology, change is constant but always a battle as many people do not embrace it.  Virtualization has been one of the biggest changes in technology in several years.  The reason is that virtualization touches so many different technology disciplines.  This one technology causes change in server, storage, network, data centers, software management, etc.  Therefore, virtualization is a very disruptive technology, but for good reason.

The challenge is managing this change across all these groups and keeping the technology and program moving forward.  The first a request is made to a network team to have 5 to 8 physical network connections to a few x86 servers but over 100 IP addresses, or a few terabytes of storage at one time for an environment consisting of multiple physical servers that all need to see the same storage - these are request that will get similar responses to the Internet replacing newspapers - it will never happen!  But, it will happen, although the change should be as non-disruptive as possible to keep program moving forward.

Communication is key in this space, this will be covered more in a later post.  Education of the support teams across the different disciplines is also very important.  The better they understand the technology and why they are being asked to make the changes the more receptive they will be. Another successful approach is to keep as many things the same as they are today, but tweak things to make them work in the virtual world.  In other words, make baby steps, the less disruptive the change is at a given point in time the less those effected will even realize things are changing.  The goal would be that they look back in a few months and say "Wow, did not even realize we had changed at this level".

In summary, do not build new policies and procedures from scratch were it can be avoided, try to retro fit the existing to get the virtualization program started and continue to review and tweak the processes and procedures as the program grows.  This will make the level of change appear less disruptive and will not not cause a rebellion from support teams against virtualization due to the level of change.

The next post will cover operational readiness for virtualization and what items need to be addressed before getting too deep into the program.