Edit: This is still good information to consider and think about.
Originally posted February 26, 2008 on AIXchange
When assisting customers with their hardware designs, communication is key. Every step of the way we need to educate customers about the configurations we’ve chosen and the thought processes that went into those choices. Then we must listen and address any issues they might have with our proposals.
Rather than push the latest and greatest hardware and virtualization tools, we must recognize what our customers are trying to accomplish and help them understand the tools that can best help them realize their objectives. Ultimately, whether it’s new network gear or System p hardware, we must be sure that the solutions we propose to our customers fit their needs.
We may run from customer to customer and implementation to implementation living and breathing PowerVM, CuoD, VIO and LPAR. But if they’ve not had our training and hands-on experience, we may find that the same words have different meanings. For instance, when I say “LPAR,” my customer might hear “all my eggs in one basket.” When I say “virtual I/O server,” my customer might hear “performance bottleneck.” We must be certain we’re speaking the same language. We must be sure that customers understand the pros and cons of any proposed solution.
We must also be sure that our customers are up to speed on best practices. We need to explain that we wouldn’t propose a solution to them unless we were convinced it was right for their situation.
And again, we must listen. If we’ve educated a customer on LPAR’s benefits but that customer elects to run on a standalone machine, we should help them with their chosen server solution rather than hammer at an option they’re not interested in at this time. This doesn’t mean that we stop educating customers about virtualization’s many benefits. But it’s a matter of priorities. Ensuring that they’re comfortable with the machines they’ll be running in their environment is foremost.
Again, we must be clear on the assumptions we’ve made and the tradeoffs that we took when coming up with our designs. Customers need to know what they’re signing off on. The last thing they want is to discover months down the road that they don’t have the equipment they thought they did. I’ve seen customers who believed that the machines at their production and disaster recovery (DR) sites were identical, only to learn that the DR site was slightly less powerful. Now, in a DR scenario, running a piece of the application and/or using a less powerful machine at the secondary data center may make financial or business sense. But the decision must be communicated to all involved parties. Certainly, system operators need to be aware of these choices long before they start loading new operating systems or testing applications.
We’re in this together. Customers want appropriate solutions to solve real business problems, and we want happy and satisfied customers. We have the right hardware and the right tools–it’s up to us to help customers architect the right solutions.