Part 2: While You’re At It, Fixing the People…

As you may remember from part 1 of this 2 part series, I talked about how IT organizations typically use people as the gap fillers between silos or domains within their systems (i.e. to approve provisioning requests, measure capacity, transfer data from one application to another, etc.) and that as they transition to cloud infrastructures, more and more of those holes are being filled with software using automation and orchestration to accomplish the same tasks faster and more accurately. So now I want to talk about what happens after they plug those holes with software and what they then have to do with the people…and, no, it’s not fire them.

When I talk to CIOs, CTOs and their direct reports, a question that’s often asked is “If, by leveraging cloud technologies, I increase my efficiencies by several orders of magnitude, does that mean I will lose a great portion of my engineering and IT staff?” and my answer always is that it’s not about replacing people, it’s about replacing activities.  I say that by transitioning to a cloud infrastructure they are getting their engineering staff out of the “commodity activity” business (i.e. commissioning servers or business services, patching or upgrading systems, P2V, etc.) and getting them into the “value-add services” business.  Once the engineers and technical folks are freed from the daily grind of “keeping the lights on” they will have the opportunity to work on truly enjoyable projects… actually what they became engineers to do–the stuff that provides true value to the business such as new, revenue generating applications, better performing systems, etc.

But, once they do evolve the organization to a cloud infrastructure and the staff is now delivering value-added services, what does that organization look like? And more important, how do they have to change their thinking in order to best manage those resources?

Services, services, services

In a cloud infrastructure, as noted, the type and character of the daily activities change from people doing manual stuff (e.g. commissioning servers or business services, patching or upgrading systems, etc.) to the system automatically doing the same stuff based on rules, templates and model behaviors that have been pre-defined and designed as workflows.  These workflows are then logically strung together (orchestrated) and delivered as business services, which can be defined as the bounded and associated capabilities required for delivering a business benefit.  That benefit being a new application or the movement of an application to a different host or really anything that results in making money, saving money or better management of the capabilities to do either of those.

Because now the IT environment revolves around delivering these business services, an operational infrastructure has to be created that effectively supports those efforts…the one designed to support a traditional datacenter is totally inadequate…and the associated roles and responsibilities within that operational infrastructure need to be aligned as well.  A really good phrase to learn before we get too far is “service level agreement” or SLA as it is not just how the delivery of a specific business service is measured, but how those who do the delivery are measured as well.  No longer will personnel be measured  on the number of hosts provisioned, the configuration of vSwitches, how many LUNS were presented or VMs were created or application installed but instead will be measured on the aggregate of those services (which together form a business service) which is encapsulated in the associated SLA.

Based on SLAs, a brand new way of measuring IT will have to be implemented and that measurement must be based on the delivery of business services because to do otherwise defeats a large point of having a cloud infrastructure (the abstraction of the underlying system from the operation of the system).  And once the measurement system is changed, the methods of managing the personnel within that system must be changed likewise.  There will be additional and different roles and responsibilities created as well as some existing roles revised or retired.  A new role created will be the Business Service Architect whose responsibility will be to define and design business services from both a process and technology perspective using the inherent capabilities of the cloud infrastructure.  He or she will work with business leaders (associating the expected business benefits to the capability of the system) and will work with system engineers associating the capabilities of the system in order to support the delivery of the business benefit.

Conclusion

Transitioning from a traditional datacenter to a cloud infrastructure involves not just plugging the holes between systems with software instead of people, it also involves fundamentally changing how people are measured and managed because the traditional ways are simply inadequate.  Any organization that attempts one without concurrently attempting the other is unfortunately bound to fail at both.