A good friend who spent years selling to CIOs once commented about CIO priorities "They can only focus on three big things, and two of them are budgets and people, so don't expect that it's easy making your widget a top priority within the organisation."
There's a lot of wisdom in my friend's perspectives, and it's instructive to think about what the people side of cloud computing is going to look like or to put it another way, how will cloud computing change the various roles within an IT organisation and how will it change their importance, relative to one another?
We believe it's impossible to understand these questions without understanding the environment in which IT personnel will be working in the cloud computing future. Our prediction is scale: big data, more (virtual) servers, more applications, much larger applications, and many more highly elastic applications. In the past, growth in computing capacity was mirrored by a linear growth in headcount. It's clear that this phenomenon, if it ever made sense, is unsustainable at the scale IT will have to operate in the future. Companies can't and won't support the scale growth with headcount as in the past.
The solution is quite clear: the substitution of software automation for what was manual interaction. This is the only possible way that IT will be able to cope with the one, two, or three order of magnitude growth of scale the future will hold. And the personnel of the IT organisation will need to implement and support that automation. Essentially, what was heretofore implemented manually must be standardised, captured in rules, and executed without human interaction. So what will it mean for IT people when automation is infused within the systems and processes? Here are five of the likely implications:
Enterprise architects become more important
The prerequisite for automation is standardisation, and the bane is customisation. IT organisations will be forced to implement standardised infrastructures, application architectures, and system automation. Developing, implementing, and enforcing standardised architectures requires skilled technical architects, and every IT organisation will need this role desperately. Applications will become functionality added onto a collection of standardised components assembled in common configurations. Of course, many organisations have enterprise architects today, but their influence is often muted by "the needs of the business," which causes non-standard applications to be implemented. For company IT organisations to operate at cloud scale, those kind of one-offs need to stop. On the other hand, the availability of public cloud providers tempts business units to pursue "shadow IT" initiatives, so it's hard to predict how this will play out in specific companies. One thing is for sure though: scale demands automation, which demands standardisation. Which leads to the next changed role in a cloud IT organisation.
Hands-off operations personnel come to the fore
There's a lot of talk about devops, a terms that means that operations personnel and operations requirements are involved earlier in the application development cycle to ensure that the resulting application is scalable and supportable. That's fine, but it implies that operations has designed infrastructure systems that can be operated in an automated fashion and that operations insists in operating in a hands-off manner. Devops is a shorthand term that subsumes many assumptions, including the ability of operations personnel to be involved early in order to avoid manual interaction later.
Any process that requires a human touch carries a bottleneck that will hamper operating at scale. As a side note, many of the private cloud plans I've seen envision whiz-bang infrastructure being operated in the same old way, so a resource request portal is offered for application developers, but all that happens is that the portal spits out an email for an operations person to provision some resources in the same old manual way. Any plan that envisions implementing a cloud infrastructure to dissuade application groups from using public providers without including an operations process re-engineering effort as well is doomed.