Does Virtualization Reduce Staff?
Virtualization, Fine, Well Sort Of? - Chapter 06
In a word, yes. Ok, this article is done, right? Wrong. It may surprise you which staff you must maintain in order to maintain your virtualized infrastructure. However, I hope this discussion does not surprise you! There are a number of approaches to supporting an infrastructure; I am going to suggest one strategy that has tactical elements. This strategy is not cheap, cough, inexpensive. There are a few places where any organization just can not global source completely and expect to get quality results. You must have high quality associates or resources in a few key places:
- Engineering
- Operations
- Problem Management
- Project Management
Engineering is a key area, these resources must understand technology, emerging, architecture, and beyond the vendor, rah rah, roadmaps, they should also come from operations at least in part. Product evaluation by the vendors that publish said products is dumb, although there is a very strong trend to doing this, because it promotes reduction of engineering staff. Never make a decision on beta code or even release candidate code. Never implement general release code if you can avoid it. The trend is to be an early adopter, the concept of late adopting seems to be lost in the dust of the past. Funny, how no one wants to tabulate TCO in the context of late versus early adoption impact costing. The total time allowed to select, evaluate, develop and certify solutions, no entire architectures, continues to shrink, and yet I continue, as one observer, to hear about the bad results of this trend, when engineers are forced to make decisions on release candidate or worse beta code exposure. Some things can not be rushed, something that management never wants to acknowledge. What is the old joke? The manager asked the engineering team, “What is the number one thing I can do to improve the quality of your work?” An engineer speaks up and says, “Give us the time and resources to do the job right.” The manager replies after a short pause, “What did you say? Sorry. We need to rap this up so you and I can both get back to work; I have operations team coming in next to explain why they are having so many issues.”
Operations teams are virtualized in nature, smaller, non-site specific, lots of talent based on fewer brains. People world-wide, recently I called a vendor on a specific issue, and was transfer from the US, to Canada, and then to Costa Rica, yes, I went from low level customer support, to elite team support, to engineering for the vendor. No, this is not outsourcing, or global sourcing to use the newer term. Thus, these new operation teams you have will rely on external resources to be sure. But talent in-house, focused on the house, if you get my implication. No matter how good global sourcing, you must have good internal operational support. Quasi teams, more strike force in nature, interchangeable parts or cogs, experts in chronic issue resolution, root cause analysis, not to mention very good trouble shooters and problem solvers. Focusing on resolving the immediate impact, and then after the issue is resolved, worked-around, etc., figure out the long term solution. The focus is reduction of immediate impact first, not always the reduction of total impact. Real solutions often take real time. Odd, that operations management understands this, but engineering management does not? A solution that takes time to test and implement, opens the door for the problem management team.
Problem management might be the most misunderstood. Problem management is not the job of your operations team. Problem management is not the responsibility of the engineering team; however, many firms see this as the case. Let me explain, you are paying your operations team to support the environment, and the engineering team to create and improve the environment. The project management team to take what engineering team does and roll it into the environment in a way that the operations team can handle. Therefore, problem management team resolves problems by leveraging the vendors, to get issues addressed, and only then validated as viable by the engineering team, and ultimately adopted by the operations team. It makes no sense to have the engineering and operations teams debating with the vendors, developers, etc., until there is something concrete and solid for them to evaluate or support. To be direct, the project management team has to have balls. There is no other way to say it. If your project management team does not have the strength and intelligence to tell management where to go, when deadlines and deliverables are insane, then your engineering team can not get superior design work done. This in turn nails the operations team, since a bad design once implemented is horrible to support. And, your problem management team is buried with lots of rework or issues that never should have left the project evaluation/test effort. Unfortunately, I see this aspect of the total model is often an after thought. Weak project managers are the norm not the exception in many firms, and the results speak for themselves, customers are not happy, management is not happy, and most of all the technology teams are left holding the bag, from nose to tail, engineering gets blamed by the operations team, etc.
Of course, there is some overlap between all the teams at various points in the life cycle of a solution or even the development and recovery cycle of issue resolution, but that should be informal and synergistic in nature, not expected by default. Oh, did anyone notice, only now I have mentioned the word, virtualization, again? I guess the concepts are valid no matter how far they are applied from virtualization, no?
Add comment February 26th, 2008
