Cisco Blogs

What Will UCS Mean For Your Job?

December 21, 2010 - 5 Comments

Yesterday morning I got around to catching up on and came across an article (G00209080) about staffing needs before and after server consolidation.  Interestingly, the first point they make is that there may be many reasons IT leaders won’t actually let anybody go, from legal reasons in some locales to the practical reality that there are always more and better things to throw staff at, if only they could be freed up from the firefighting that classically consumes 70% of their time.

That doesn’t mean that consolidation projects are pointless or won’t save money.  The key is framing the objective of such projects in terms that are meaningful to a CEO: to paraphrase John Chambers at Gartner Symposium, “revenue per employee and cost per unit served”.  If your leadership can get more services spun up more quickly and supported well with an essentially flat IT budget, the CIO has contributed net value to the organization.

What UCS brings to IT is just that: in the remarkably short term, you can spin up and support IT services much more easily. People measure this differently: Slumberland reduced per server management costs from $1575 to $80 with Cisco UCS; ExamWorks expects to support 250 employees per IT head, vs 50 at a similar size firm. But pretty consistently if anecdotally, our customers are seeing about an 80% reduction in ongoing operational costs, which translates into new opportunities to scale their businesses with existing resources.

What about who does what? Do you have networking people managing UCS servers? Do you have to create a new type of position just to manage UCS? (Two questions I’ve fielded recently.) The answers are no and no, unless you decide otherwise.  We’ve reduced the points of management on the backend, but designed the management front-end to map to existing IT organizational structure and culture. You can set up UCS Manager to make all tabs (LAN/SAN/Server/VM, etc) viewable by all, but individually operable only by members of a defined group. A super-admin can create policies or restrict policy choices that others may implement. Or everything can be open to all, which can be useful in smaller organizations where a few people cover many areas.

Because these things are not pre-defined or hard-coded, the management paradigm is highly adaptable to shifts in organizational definitions.  I think few would argue at this point that a denser, more converged, more logical and automated IT world is not on the horizon, even if the timeframe for mass adoption varies wildly depending on who you talk to. As a result, while UCS isn’t going to cause one group to take over another’s job, it’s a leading indicator of larger trends that may in the long run cause overall IT job growth to flatten, and the nature of many jobs to change.

For example, in a logically configured, “wire-once” world, fewer server admins will really need to know much about physical set-up or cable management. The need for such knowledge will still exist, but it may become a highly specialized job—with increasing job security as the current IT generation ages out, but relatively few such positions, and ones that may eventually become attached more often to services firms than to in-house IT.  On the other hand, in-house practitioners can reasonably expect to become more versed in policy and process design (whether it’s called ITSM or something else), in order to ensure that their infrastructure can be automated securely and effectively. Domain expertise will remain crucial, but so will an understanding of how the different domains intersect and affect one another.  UCS Manager with all tabs visible can be a useful training tool in this regard, as it exposes and documents these intersections while providing a consistent logic for managing them —rather than isolating the process segments in separate management constructs.

On a topical note, as Omar has just highlighted, we’ve just expanded your capability for improving operational scalability across several dimensions with our UCS Manager 1.4 release, most notably by extending the UCS management paradigm to the C-series rackmount servers. And more to come along those lines in future releases!

In the meantime, best wishes for your holiday season, and for a productive new year.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. We just installed out first UCS pair this week and are going to be migrating systems over starting tomorrow. so, as you might imagine we are soaking up as much as we can find in the UCS community. This was a good summary of a lot to consider. I especially like the idea about the narrow need for specialized skills for a wired once world.For now, the whole team is involved and so proud we took photos and posted them. Cisco UCS, Consolidated Infrastructure, Private Clouds

  2. OK..I see where you are going. My shop was on the road to the third stage before virtualization/consolidation. We already had a large portion of day-to-day operations automated so consolidation was just a minor operational improvement (but big fiscal impact). Though there are still some areas where we can improve, I don't forsee any staff reductions coming out of them. I still contend that consolidation itself does not provide a means for staff reduction. If your processes are bad, consolidating just means you consolidated. The bad processes still exist. BTW, you can fix bad processes without consolidation. What I think it happening is that companies are taking the opportunity to fix bad processes via consolidation projects, resulting in staff reductions. And this result gets propagated as "consolidation = staff reduction", not the fact that the bad processes being fixed is the real reason for being more efficient.

    • I agree with you, Adam. There are those who propagate the "consolidation = staff reduction" notion as FUD, but I think it unlikely to be a zero-sum game in most cases. Your experience with broadened horizons seems to be more common. Bad processes typically arise as reactive workarounds to various technology add-ons. Do enough add-ons at various times by various individuals and teams, and you wind up with an unholy mess that can only be managed in an extremely manual fashion. My point here is that UCS is unlikely to affect your job all that much in the near term--unless you're high enough up in your org that you're being measured on TCO, in which case it's a net-plus, usually due to increased productivity and physical savings. But the increased automation it helps facilitate points to a shift of focus for many in the future.

  3. But don't take my word for it--more on the shift from physical to policy mgmt, from people with data to back it up:

  4. I don't understand how consolidation can lead to staff reductions. We've reduced our footprint with UCS, but it still takes the same amount of staff to manage our environment. We still have the same number of operating system instances running. We still have the same number of applications running. All we did was reduce the amount of hardware that was running. If you are buying good equipment, you really shouldn't be managing the hardware that much. Yes, things will fail (hard drives, power supplies), but unless you have a large data center, these are not daily events. Where UCS has really helped (in terms of staffing) is that it required us server admins to learn some networking and our network admins to learn a bit about servers. Now we have increased our skill sets and learned to appreciate the other disciplines. adam