If you think hardware consolidation when you think of virtualization, you might be thinking a bit inside the box. Step back and think of your entire product life cycle and top pain points, then see if you might be missing opportunities that are much bigger than adding 'cool' to your product. After all, I don't know any engineers who are really that interested in reducing the number of boxes in their solution just for the heck of it.
For example, I just met with an OEM customer that spends 1/3 of their total development schedule and 50,000 man hours on testing activities. If we could reduce that through automation by 30%, that would reduce their development cycle by 10%!
How is this possible?
The client already has some automation in place at the GUI level, so the savings won't come from the execution of the scripts. Instead it will come from one of the following three places:
- Test environment setup. The system architecture is a combination of isolated servers (to ensure availability) and specialized end-points. Bringing up a fresh environment can take forever when it is a manual process involving lots of hardware and different software packages. If you virtualize the components of the architecture, you can quickly assemble a virtual test environment with a few mouse clicks. This includes nodes that are purposefully damaged or in a corrupted state, which leads us to . . .
- Creating more extensive automated tests that were not possible before. As an example, imagine a test case that involves a node losing power. This would be very hard to test in an automated fashion if you were using hardware for the node. If you are using virtualization, it is only a matter of asking the virtual machine of the node to power off. You will still need to extend your testing library with commands to coordinate the virtualized environment, but it won't take long for this to pay dividends.
- Optimizing issue troubleshooting and resolution. What happens if you are manually testing and you hit a bug that is not easily replicated? In our own labs I have seen two or three systems sitting idly with labels 'DO NOT TOUCH' as they awaited engineering resources to diagnose the issue. If you have a virtualized environment and you run into this type of issue, you can pause all of the systems and save them off so that the test team can continue to run test cases. Once engineering has time to investigate, the test team can bring the captured environment back up (or the engineer can bring the environment back up in his cube). This can even be extended to production environments. Can you imagine if Toyota could have captured a copy of the VM running its firmware anytime one of its cars was involved in an accident?
- Hardware consolidation. O.K., so it's not that lame. No company wants to be limited by QA hardware and this is a great way out of that problem. You can either share dedicated resources, or you can use all of the idle desktop cycles during the night to host a virtual test environment that would otherwise be out of reach.
The customer was way ahead of me on this one and had already come up with other ways to leverage virtualization to fundamentally change the way their product functions rather than just make it faster. Innovation is so much more than doing things faster or better; it is changing what you are doing in the first place!
Can you think of ways to apply virtualization to product development or deployment that haven't been discussed in the IT world?
If so, let's hear it.
For more information on our OEM Solutions visit www.dell.com/oem or follow Josh Neland on Twitter at www.twitter.com/joshneland.