Virtualization Management Software Should Solve Business Problems, Not Create Them – Part One
Have you ever bought something you were told "everyone" needed to solve a problem you had never heard of? If so, you were sold on FUD (fear, uncertainty and doubt), and it made you feel as though you didn’t want to risk being caught without a solution to this newfound problem. Conveniently, the company that made you aware of this problem offers a product of some sort, with a cleverly named feature that provides you the solution. You bought the product because it offered the feature that solved this new problem, but did it solve it, or create it? Was it even a problem in the first place? Even worse, did I choose the right product based on my real needs?
Take this and apply it directly to the virtualization management software marketplace. It’s a fast-growing and extremely competitive industry, without a doubt, and that means you need to be even more cautious in your selection process. One virtualization management company has gone so far as to provide prospective customers a spreadsheet loaded with features specific to their own product, in an effort to "save the customer time and effort". Obviously a spreadsheet full of product-specific features masked as a generic product comparison tool will unfairly tip the scales every time. The worst part is that real employees at real companies are knowingly using these loaded "comparison tools", publishing the requirements as their own, and ultimately betting their job and their employer’s success on it. Scary stuff, but it happens.
How do you avoid it? Easy – go back to basics. Shop as if your job depends on it (because it probably does). With just a slight slant toward virtualization, here is a list of generic questions to ask yourself before you shop for any software solution:
1. What is the business problem I’m trying to solve?
Business needs should always drive IT requirements. For example, your business need might be to provide certain users access to one or more servers, each with a fresh install Windows 2003 Server, within 30 minutes or less for each server, and give each user a maximum of 5 servers. This could be accomplished technically by giving every one of those users admin access on the virtualization management console, but it doesn’t address the 5-server limit. If this is a legitimate business problem that cannot be solved with your current toolset, it becomes a solution requirement.
2. What is the company vision for virtualization technology?
This one is important, because it sits at the base of every solution requirement. If your company has decided that physical server deployment is the exception rather than the rule, your requirements need to reflect that goal.
3. Who is my internal customer, and what do they need?
You may have multiple solutions for one internal customer, or multiple internal customers for one solution. Either way, your requirements should reflect the need for flexibility, and make sure the product fits the solution. Deviating from your best practice means you’ve moved to your second-best practice, and should be avoided.
4. Is there a metric to meet as part of solving the business problem?
Service Level Agreements (SLAs) are the metrics that keep IT organizations on their toes. Very few SLAs have any consideration for scaling of a deployment. Make sure the product you select can scale, whether it’s a pilot deployment at 100 servers, or global production at 10,000 servers.
5. What do I have for resources to support my infrastructure?
Selecting a management platform that requires 5 people from your team sitting at a console 24 hours a day makes no sense if there are only 3 people on the team in the first place. Consider a self-service slant to offset administrator needs, and remember, the more automation, the better – "do more with less".
6. Who pays for the infrastructure, and how is the financial responsibility divvied up – by geography? Business unit? Not at all?
Those servers aren’t being shipped to your datacenter for free. Someone is paying for it somewhere, and they will probably want to know how their investment is being used. Chargeback, or at least some solid reporting capabilities, are a great way to support your requests for additional infrastructure and budget consideration.
7. What factors are preventing me from solving my business problem with what I have in place today? (process, resource constraints, political challenges?)
Be honest with yourself -where are the holes in your operation? Once you’ve identified the holes, you can find a way to plug them. Figure out how to fill the gaps, and make them requirements of your solution. If a vendor can’t fill those gaps today, find out if it’s planned in a future release, and get a hard commitment on when they plan to deliver the solution. Buying on near-term futures is fine, but think long and hard about what happens if you don’t get your must-have features on day one.
8. Whose jobs depend on the successful rollout of your new virtualization management solution?
These folks should probably be involved when you’re gathering requirements, and actively participate in evaluations of the components they will be using.
9. Am I willing to be locked in to a single vendor?
It happens all the time: someone decides that you’re no longer using Vendor A for whatever reason, and you are to move from Vendor A’s platform to Vendor B’s platform within the next 12 months. What happens if Vendors A and B are hypervisor vendors? All of a sudden, that single-vendor approach you took doesn’t seem so hot. Your best bet: keep your options open.
10. Where are my integration points, and can they be supported?
Does your current process involve interaction with any in-house, homegrown, custom or 3rd party system? If so, you need to speak up through your requirements if you want them included as part of the solution. If integration with your external system is not offered out-of-the-box, don’t be afraid to set a requirement to make the integration required AND supported.
11. What do I need for support?
When you have the expertise in-house, support becomes a formality to get access to the latest code. If the solution you are deploying is a critical piece of your day-to-day operations, consider what might happen if you’re down at a point in time outside your support window. Solutions containing customization don’t always come with vendor support, but if it’s available, take it into serious consideration.
In part two of this article, we’ll dig further into legitimately generic, standard features for virtualization management, and discuss how those features map to your core business needs.