How to Prepare Your Team to Leverage Cloud Operating Models

Cloud operating models are essential elements in a successful cloud environment. They are so important, I'd argue, that they can often stand between you and your enterprise’s ability to successfully adopt a public cloud. This is one of the areas of IT that is often difficult to define and contextualize. This article intends to bring some clarity around cloud operating models, including the features of a successful model, its layers of functionality and the keys to building a successful cloud operating model.

Let’s start with the features of a successful operating model. They include:

• Democratizing technology via cloud native and bringing it closer to the end users.
• Gaining agility and the ability to run fast.
• Eliminating duplication while enabling economies of scale.
• Providing clarity around the lines of demarcation between various functions within the cloud environment.
• Providing communications paths between various functions (adding more functions is great, but there is a tradeoff between specialization and efficiency).

Contextualizing an effective operating model

You can break down the average cloud stack of an enterprise into three layers, including:

1. Application layer: This is where your application or business logic lives. It’s effectively the platform on which your end users consume your services. 
2. Shared services layer: This is made up of various components, depending on the technologies adopted by your company. Technologies that commonly sit in the shared service layer include your container orchestration mechanisms (e.g., Kubernetes® clusters), shared messaging buses (e.g., Apache Kafka or Amazon Simple Queue Service), cloud identity and access management patterns (e.g., AWS Single Sign-On), and networking landing zones.
3. Infrastructure layer: While there should be a bias toward using shared service platforms where possible, there will be occasions where bespoke deployments are needed, such as running an off-the-shelf product within an Amazon EC2 instance. Infrastructure that sits outside this shared services layer will commonly fall into the infrastructure layer.

Within each of these three layers, there are two functions:

1. Building and deploying: The layers should be producing standard deployment patterns. For example, using standard CI/CD pipelines and deploying applications.

1. Ongoing operations: This is known as the “feeding and watering” of infrastructure to ensure that it is being operated in an effective, secure and efficient fashion.

Below is a visual depiction of how these functions could be structured.

As shown above, an operating model delivers six separate functions (the yellow boxes) within your cloud environment. Depending on your organization, you could have six separate teams or use a small number of teams and overlap functions. For example, the team building the applications could also be the people responsible for the watering and feeding of the application. This could include things like monitoring the application availability 24x7x365, as well as being responsible for code updates and release application changes. Alternatively, you could split these actions into separate teams and functions.  

Keys to building a successful cloud operating model

• The right skillset: Ensure you have all the functions covered in the image above and your team possesses the right skillsets. An anti-pattern that we have seen is having infrastructure teams on call for the application. But that rarely yields outcomes much better than simply restarting the application. This means the root cause is never particularly well understood.
• Fill skill gaps: Document which teams exist and who makes up the teams. It is common to see gaps within the operating model when walking through the actual teams and individuals who fulfill each function. Plugging any gaps is a quick way to improve your cloud operating approach.
• Function agreement: Agree on where the lines of demarcation exist within your organization between these functions.
• Streamline teamwork: Understand and record how the teams interact. Frequently, we see different teams using different IT service management (ITSM) tools, languages or terminology. This creates chaotic interactions and should be avoided.
• Embrace cloud native: For example, go serverless to eliminate any heavy lifting on your end.

This can seem like a daunting journey. Defining one’s own processes and organizational structure is often harder than anyone expects. Then there are the numerous cloud service providers from which to choose. Will you self manage and try to DIY or bring in hired hands to help guide the way? There is no ideal one-size-fits-all approach. IT environments are complex, business requirements rapidly shift and few of us have guaranteed budgets. Trust me when I say, take your time, do your research — and please don’t just move your existing problems to the cloud.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.