So you’ve managed to avoid going the way of the dodo, and dodged the IT job “endangered species list” I talked about in my last post (and at Cloud Expo). Great. Now the question is, what are some of the roles within IT that cloud computing is putting front & center?
I listed a few of my ideas during my Cloud Expo presentation a few weeks back. My thoughts are based on what I’ve heard and discussed with IT folks, analysts, and other vendors recently. Many of those thoughts even resonated well with what I’ve heard this week here at the Gartner Data Center Conference in Las Vegas.
IT organizations will shift how they are, well, organized
James Urquhart from Cisco put forth an interesting hypothesis a while back on his “Wisdom of Clouds” blog at CNET that identified 3 areas he thought will be (and should be) key for dividing up the jobs when IT operations enters “a cloudy world,” as he put it.
First, there’s a group that James called InfraOps. That’s the team focused on the server, network, and storage hardware (and often virtual versions of those). Those selling equipment (like Cisco) posit that this area will become more homogenous, but I’m not sold on that. James followed that with ServiceOps, the folks managing a service catalog and a service portal, and finally AppOps. AppOps is the group manages the applications themselves. It executes and operates them, makes sure they are deployed correctly, watches the SLAs, and the like.
I thought these were pretty useful starting points. I agree whole-heartedly with the application-centric view he highlights. In fact, in describing the world in which IT is the manager of an IT service supply chain, that application-first approach seems paramount. The role of the person we talk to about CA 3Tera AppLogic, for example, is best described as “applications operations.”
Equally important as an application-centric approach are the skills to translate business needs into technical delivery, even if you don’t handle the details yourself. More on that below.
Some interesting new business cards
I can already see some interesting new titles on IT peoples’ business cards in the very near future thanks to the cloud. Here are some of those that I listed in my presentation, several of which were inspired by the research that Cameron Haight and Milind Govekar have been publishing at Gartner. (If you’re a Gartner client, their write-up on “I&O Roles for Private Cloud-Computing Environments” is a good one to start with.):
· “The Weaver” (aka Cloud Service Architect) – piecing together the plan for delivering business services
· “The Conductor” (aka Cloud Orchestration Specialist) – directing how things actually end up happening inside and outside your IT environment
· “The Decider” (aka Cloud Service Manager) – more of a vendor evaluator and the person who sets up and eliminates relationships for pieces of your business service
· “The Operator…with New Tools” (aka Cloud Infrastructure Administrator) – this may sound like a glorified version of an old network or system administrator, but there’s no way this guy’s going to use the same tools to figure all this out that he has in the past.
In Donna Scott’s presentation at the Gartner Data Center Conference called “Bringing Cloud to Earth for Infrastructure & Operations: Practical Advice and Implementations,” she hit upon these same themes. Some of the new roles needed that she listed included solution architects, the automation specialist, the service owner, cloud capacity manager, and IT financial/costing analyst. Note the focus on business-level issues – both the service and the cost.
Or maybe the truth is that these roles blend together a bit more. I could see the IT organization evolving to perform three core functions in support of application delivery:
— Source & Operate Resource Pools This person would be someone who would maintain efficient data center resources, including the management of automation and hypervisors. The first is the ability to more effectively manage resources—to determine how much memory and CPU is available at any given time, to scale up and down capacity in response to demand (and have the ability to pay only for what you use). These resources might eventually be sourced either internally or externally, and will most often be a combination of the two. This function will be responsible for making sure the right resources are available at the right time and that the cost of those resources is optimized.
— The second function is Application Delivery, focused on building application infrastructure proactively, so that when the next idea comes down the pike, you can be ready. You can proactively build an appropriately flexible application infrastructure. You can provide the business with a series of different, ready-made configurations from which to choose, and you would have the ability (when they are needed) to quickly get these pre-configured solutions up and running quickly.
— The last, higher-level function is the process of engaging with the business closely. Your job is to Assemble Service. You’ll be able to say to the business ‘bring me your best ideas’ and you’ll be able to turn those concepts into real, working systems quickly, without having to dive into lower-level technical bits & bytes that some of the previously mentioned folks would.
In all cases, I’m talking about ways to deliver your application or business service, and the technical underpinnings are fading into the background a bit. “Instead of being builders of systems,” said Mike Vizard in a recent IT Business Edge article, “most IT organizations will soon find themselves orchestrating IT services.”
James Urquhart talks about this as an important tenant of the DevOps approach: The drive to make the application the unit of administration, not the infrastructure. James had another post more recently that underscored his disappointment that shows like Cloud Expo are focusing more on the infrastructure guys still, not the ones thinking about the applications. I’m all in favor. I heard Gartner’s Cameron Haight suggest why this might be true in most IT shops: while development has spent a lot of time working toward things like agile development, IT ops has not. There’s a mismatch, and work is starting on the infrastructure side of things to address it.
Still, how do you get there from here?
So the premise here is that cloud will change the role of IT as a whole, as well as particular IT jobs. So what should you do? How do you know how to ease people into these roles, how to build these roles, or even how to try to make these role transitions yourself?
I’ll repeat the advice I’ve been giving pretty consistently: try it.
— Figure out what risks you and your organization want to take. Understand if a given project or application is more suited to a greenfield, “clean break” kind of approach or to a more gradual (though drawn-out) shift.
— Set up a “clean room” for experimentation. Create the “desired state” (Forrester’s James Staten advocated that on a recent webcast we did with him). Then use this new approach to learn from.
— Arm yourself with the tools and the people to do it right. Experience counts.
— Work on the connection between IT & business aggressively
— Measure & compare (with yourself and others trying similar things)
— Fail fast, then try again. It’s all about using your experience to get to a better and better approach.
There was one thing that I heard this week at the Gartner show from Tom Bittman that sums up the situation nicely. IT, Tom said, has the opportunity to “become the trusted arbiter and broker [of cloud computing] in your organization.” Now that definitely puts IT in a good place, even a place of strength. However, there’s no denying that many, many folks in IT are going to have to get comfortable with roles that are very different from the roles they have today.
(If you would like a copy of the presentation that I gave at Cloud Expo, email me at firstname.lastname@example.org.)