Author Archives: Kevin Lees

Transforming IT Services is More Effective with Org Changes

By: Kevin Lees

Last time, I wrote about the challenge of transforming a traditional IT Ops culture and the value of knowing what you’re up against.

Now I want to suggest some specific organizational changes that – given those cultural barriers – will help you successfully undertake your transformation.

At the heart of the model I’m suggesting is the notion of a Cloud Infrastructure Operation Center of Excellence. What’s key is that it can be adopted even when your org is still grouped into traditional functional silos. 

Aspiration Drives Excellence

A Cloud Infrastructure Operation Center of Excellence is a virtual team comprised of the people occupying your IT org’s core cloud-focused roles: the cloud architect, cloud analyst, cloud developers and cloud administrators. They understand what it means to configure a cloud environment, and how to operate and proactively monitor one. They’re able to identify potential issues and fix them before they impact the service.

Starting out, each of these people can still be based in the existing silos that have grown up within the organization. Initially, you are just identifying specific champions to become virtual members of the Center of Excellence. But they are a team, interacting and meeting on a regular basis, so that from the very beginning they know what’s coming down the pipe in terms of increased capacity or capability of the cloud infrastructure itself, as opposed to demands for individual projects.

Just putting them together isn’t enough, though. We’ve found that it’s essential to make membership of the cloud team an aspirational goal for people within the IT organization. It needs to be a group that people want to be good enough to join and for which they are willing improve their skills. Working with the cloud team needs to be the newest, greatest thing.

Then, as cloud becomes more prominent and the defacto way things are done, the Cloud Center of Excellence can expand and start absorbing pieces of the other functional teams. Eventually, you’ll have broken down the silos, the Cloud Center of Excellence will be the norm for IT, and everybody will be working together as an integrated unit.

Four Steps to Success

Here are four steps that can help ensure that your Cloud Infrastructure Operation Center of Excellence rollout is a success:

Step 1 – Get executive sponsorship

You need an enthusiastic, proactive executive sponsor for this kind of change.  Indeed, that’s your number one get – there has to be an executive involved who completely embraces this idea and the change it requires, and who’s committed to proactively supporting you.

Step 2 – Identify your team  

Next you need to identify the right individuals within the organization to join your Center of Excellence. IT organizations that go to cloud invariably already run a virtualized environment, which means they already employ people who are focused on virtualization. That’s a great starting point for identifying individuals who are best qualified to form the nucleus of this Center. So ask: Who from your existing virtualization team are the best candidates to start picking up responsibility for the cloud software that gets layered on top of the virtualized base?

Step 3 – Identify the key functional teams that your cloud team should interact with.

This is typically pretty easy because your cloud team has been interacting with these functional teams in the context of virtualization. But you need to formalize the conneciton and identify a champion within each of these functional teams to become a virtual member of the Center of Excellence. Very importantly, to make that work, the membership has to be part of that person’s job description. That’s a key piece that’s often missed: it can’t just be on top of their day job, or it will never happen. They have to be directly incentivized to make this successful.

Step 4 – Sell the idea

Your next step is basically marketing. The Center of Excellence and those functional team champions must now turn externally within IT and start educating everybody else – being very transparent about what they’re doing, how it has impacted them, how it will impact others within IT and how it can be a positive change for all. You can do brown bag lunches, or webinars that can be recorded and then downloaded and watched, but you need some kind of communication and marketing effort to start educating the others within IT on the new way of doing things, how it’s been successful, and why it’s good for IT in general to start shifting their mindset to this service orientation.

Don’t Forget Tenant Operations 

There’s one last action you need to put in place to really complete your service orientation: create a team that is exclusively focused outwards toward your IT end customers. It’s what we call Cloud Tenant Operations.

Tennant Ops is one of three Ops tiers that enable effective operations in the cloud era. It is also called “Service Ops,” which is one of three Ops tiers outlined here and here.

One of the most important roles in this team is the customer relationship (or sometimes ‘collaboration’) manager who is directly responsible for working with the lines of business, understanding their goals and needs, and staying in regular contact with them, almost like a salesperson, and supporting that line of business in their on-boarding to, and use of, the cloud environment.

They can also provide demand information back to the Center of Excellence to help with forward capacity planning, helping the cloud team stay ahead of the demand curve by making sure they have the infrastructure in place when the lines of business need it.

Tenant Operations is really the counterpart to the Cloud Infrastructure Operation Center of Excellence from a service perspective – it needs to comprise of someone who owns the services offered out to the end customers over their life cycle, a service architect and service developers who actually can understand the technical implications of the requirements. These requirements are coming from multiple sources, so the team needs to identify the common virtual applications that can be offered out and consumed by multiple organizations (and teams within organizations) as opposed to doing custom one-off virtual application development.

In a sense, Tenant Operations function as the dev ops team from a cloud service perspective and really instantiate the concept of a service mindset, becoming the face to the external end users of the cloud environment.

These Changes are Doable

The bottom line here: transforming IT Ops is doable. I have worked with many IT organizations that are successfully making these changes. You can do it too.

Additional Resources

For a comprehensive look at how to best make the transition to a service-oriented cloud infrastructure, check out Kevin’s white paper, Organizing for the Cloud. 

Also look for VMware Cloud Ops Journey study findings later this month, which highlights common operations capability changes, and the drivers for those changes. For future updates, follow us on Twitter at @VMwareCloudOps, and join the conversation by using the #CloudOps and #SDDC hashtags.

Transforming IT Services Starts With a Culture Shift

By: Kevin Lees

It’s happening. In place of their traditional, project- and technology-based approach, IT organizations really are making the shift to deliver IT as a service.

My last post examined what an IT service looks like in practice. But what if you’ve only gone as far as deciding that you need to transform IT? How do you act on that decision?

Your first priority, I’d argue, is to understand how functional silos create an anchor for your organization’s culture, and how that may be your biggest barrier to change. That’s what I’ll be looking at here. In part 2, I’ll suggest a solution for specific organizational changes that address the culture shift problem.

Changing Minds to Change Behavior

For context, here’s the IT model you’re leaving behind: a project request comes in with specific technology or capacity requirements. You procure the infrastructure and build a custom environment and then turn that over to the development team (which is often really a back and forth affair between Dev and Ops, where the final solution doesn’t really look like the initial request). When the new capability is moved into production, you take over the management and maintenance of that application and underlying infrastructure environment.

Here’s where you’re going: well before you get any requests, you build an environment that can be reused across many different development teams. You deliver that environment as a highly standardized service that’s a best fit for all the teams you serve. They request and deploy on demand with little or no IT Ops involvement in the deployment. Developers can customize their deployment to some degree, by selecting from a small set of highly standardized service options or configuration choices.

Leaving the one behind and moving to the other requires new software tools, as well as hardware that can handle the demands of a pooled resource environment. But the real transformation is a shift in mindset. And it’s one that can be hugely challenging for an IT group to both make initially and sustain over time.

I’ve seen this at many IT groups I work directly with. The fact that “It’s just not the way we’ve done things in the past” in itself becomes the obstacle to change.

Breaking Structural Bonds

Team A, for example, has always done their thing and then handed it off to team B who does their thing, who hands it off to the next team. Even with carefully crafted swim lane diagrams, phase gate checklists, and continuous process improvement – it can literally take months to deploy an environment for a development team.

Over time, large IT organizations build a series of silos that  develop deep expertise to facilitate that process: a network silo, a security silo, a storage silo, and so on.  They optimize the steps and sub-optimize the process.

But you’re now looking to move to a situation where everyone works in a much more integrated way: together and not sequentially. After all, with a cloud services-oriented operation, things happen so fast and in such an integrated way that trying to work within the context of these silos and linear processes does nothing but slow the process down, which defeats the whole purpose of making the change.

So for change to happen, the silos have to go.

Fear, Uncertainty . . .  a Plan

Propose ditching silos, though, and people immediately start fearing for their own job security. They won’t know what it will take to do well anymore – deepening expertise was a well worn path to recognition, certifications and a raise. Talk of breaking down this structure conjures in them that awful trinity: fear, uncertainty, doubt.

It’s an understandable reaction and it’s important to anticipate and plan for. But you now know 1) what you want and 2) what you’re up against. You’re ahead of the game.

It is time to own the problem!

In my next blog post, I’ll outline a concrete set of actions that will help you successfully change your organizational culture – reengingeering your Ops team to dynamically deliver services to end customers through a cloud infrastructure.

For future updates, be sure to follow @VMwareCloudOps on Twitter and use the #CloudOps and #SDDChashtags to join the conversation.

Additional Resources

View Kevin Lees webcast 5 Key Steps to Effective IT Ops in a Hybrid World for more information about specific changes that can help IT be more service-oriented.

What Do We Mean by IT Services in the Cloud Era?

By Kevin Lees

You hear it all the time from cloud evangelists: instead of delivering based on projects, IT should now be delivering around a common set of services.

It’s not a new idea—but cloud computing promises to finally make it a reality.

Before we get too excited, though, we should ask: what do we actually mean by cloud services? That’s not something cloud advocates always make clear.

So here’s an example:

The other week I was talking with a customer who runs a cloud that supports production dev test environments for a  government agency. These environments are in turn supporting mission-critical applications that play a major role in maintaining the public’s health.

From a service perspective, the tenant ops team is identifying and building a set of common development platforms as virtual applications. In this case each platform consists of three tiers, with each tier running a Windows operating system that’s been pre-built to meet government security policies. The composite platforms all have monitoring drivers already installed, and also feature commonly-used development environments – in this case they’re either a Microsoft dot-net type environment or Java-based.

Collectively, that creates a common virtual dev test vApp pre-built with a lot of the core capabilities and requirements to do this type of mission-critical application development. My customer’s team is then offering this multi-tier stack as a “service” via self-service on demand provisioning.

In the past, it could have taken two to three months to stand up something like this for a new round of development and testing. Now, with these prepackaged, common services, a new development environment can be deployed in less than an hour..

It’s a great example of how quickly you can provision, not only from infrastructure perspective, but so that developers don’t have to repeatedly start out with raw infrastructure and build-in all of their own environments.

This standardized, pre-packaged development environment can also be used across multiple development teams and even across multiple departments. Each may need to do some tweaking for their particular area, but it saves everyone an enormous amount of work.

For future updates, follow @VMwareCloudOps on Twitter and join the conversation using the #CloudOps and #SDDC hashtags.