Designing and Adopting a Cloud Operating Model
As large enterprises increasingly adopt public cloud, they are asking the sensible question of how cloud fits into and changes their workflows and internal processes.
These organisations have recognised that the cloud has an impact on how they work. That it’s not just someone elses data centre. Also, they usually recognise that cloud represents an opportunity for improvement and efficiency, if they adopt cloud in the right way.
This exercise of defining the future state is often described as a cloud operating model, a set of key processes which explain how the organisations people, technology and resources come together to design, develop, deploy and run applications on public cloud-based platforms.
At Contino, we are currently involved in the development of a number of cloud operating models with large enterprise clients, and wanted to take this opportunity to share our thinking on what they are and how they are developed and adopted at scale.
What goes into a cloud operating model?
There’s no real accepted definition of the term 'operating model', and definitely not a widely accepted definition of a cloud operating model yet. For this reason, there is a lot of confusion as to what is included and what is out of scope.
Our guidance is to capture and document anything which is and should and modernised by an optimal adoption of cloud. Adopting cloud is a transformational opportunity to do things leaner and more efficiently, so we propose to take full advantage of the opportunity to remove bureaucracy and lean out the organisational processes.
To give it some structure, we split our operating models into infrastructure-level and application-level concerns.
- Infrastructure management: When operating on a cloud platform, the servers, networks and storage will change in nature and how they are procured and managed. No longer do we need to to raise a purchase order for a system integrator to set up tin in our data centre. Instead, we just provision via an API. The infrastructure offerings available might not map one-to-one with how the organisation have traditionally done things, so we will need to define how and what infrastructure can be deployed in certain situations. There are also concerns around managing the operating system such as patching, or middleware such as application servers as databases. We tend to think of these as a infrastructure concerns.
- Application management: Moving up the stack, applications should also be architected, deployed and managed differently in a cloud environment. This touches lots of areas such as deployment mechanisms, backups, information security, auto scaling etc. The cloud operating model will capture all of these key processes and guidelines so that when the cloud is adopted at scale, application teams are doing things in a consistent way.
We then think of cross-cutting concerns that span both infrastructure and applications. Some of the main areas of focus are:
- People model: Cutting across both infrastructure and applications, we want to articulate what people, skills and teams are needed to manage cloud-based infrastructure and applications. This will likely include a move to cloud architects and DevOps engineers, and cross functional DevOps teams who own more of the responsibility for deploying and running their applications.
- Support model: We also need to update the support model in a cloud world. More of the infrastructure will typically be managed by the cloud provider, so we need to identify which responsibilities are down to the provider, the support teams and the application teams.
- Financial model: When we are moving from CapEx-based infrastructure to OpEx-based cloud, the financial model by which infrastructure is paid for changes. We need to manage cost controls and then dynamically report on usage after the fact, and then create processes for cost optimising the platform over time.
- Security model: Security is also a key focus as we move from a private data centre to public cloud, so we would typically outline key processes to ensure that data sovereignty and data classification levels are maintained, and that applications and environments are developed to be as secure by default.
All of this basically outputs the governance model, which defines the cloud operating model design that will be consumed in the enterprise. The benefits of this exercise are huge, driving a consistent approach and accelerating the organisations ability to lock in the benefits of cloud.
On boarding
A second question for an enterprise who are going into the cloud is, which applications to move, in which order, and how to manage any remediation or migration effort.
We work with many organisations to determine their cloud organization structure by carrying out cloud readiness assessments and road-mapping exercises, which categorise and prioritise applications based the amount of effort that will need to successfully remediate for the cloud.
- Cloud laggard: Requires significant re-architecture and has barriers which prevent a move to the cloud
- Cloud lift and shift candidate: Possible candidate for migration as a lift and shift exercise
- Cloud optimisation candidate: Would benefit from small enhancements to make the applications more appropriate for cloud deployment
- Cloud native: Ready to take optimal use of inherent cloud features such as horizontal scalability, database as a service etc.
The cloud readiness assessment will also take into account data sharing and data sovereignty rules which the organisation is limited by. We may, for instance, find cloud native applications that are architecturally ready to move to the cloud but limited for regulatory reasons. These are flagged up to the leadership as holding back cloud transformation.
How are cloud operating models adopted?
For new, greenfield teams, we want to ensure that they are on-board with the cloud and adopt common processes and cloud operations best practices. As the organisation moves to cloud, new applications should be able to move straight onto the new operating model with support from centralised cloud centres of excellence that we would usually setup.
In enterprise IT, there will also be a large backlog of thousands of applications, which can potentially be moved over once they have been through the assessment and road mapping exercise described above. We generally recommend short enablement sprints where the teams are trained and supported in adopting the pipeline and cloud deployment, but ultimately take responsibility for the safe migration into the cloud themselves.
Like any large scale change in working practice, cloud transformation should also be supported with online and offline training, coaching, documentation, floor walking.
It will also need high senior level management support. New process change is difficult and in a large enterprise we will hit many doubters, so we need a significant degree of momentum to push through to being a cloud-first organisation.
