Discover our blogs

45° Blog

The honeymoon weeks of Cloud computing are over – part 1

How to start with a Cloud transformation journey that will last a lifetime.

Cloud computing brings about incredible opportunities. The technology enables scenarios for innovation that “BC” (before Cloud) were simply not possible. Unfortunately, every introduction of such promising technology does always come with additional marketing fuzz. Think of “installing SQL Server is just clicking next-next-next!”. That type of hype. But we all know: reality is different. It’s not just sunshine and rainbows, and it does take more than one click. And that’s not different for Cloud computing.

In a two-part blog post, we will shed some pragmatic lights on how Cloud introduction works in large(r) corporations. What did we learn in the last couple of years? How do you get started with your Cloud transformation journey? We’ll take you through it!

(c) Rod Long – Unsplash

Step 1: Organize your IT capabilities for a hybrid world.
Step 2: What is an accountability model and what does yours look like?
Step 3: What does your operating model look like in this hybrid world?
Step 4: Bringing it all together.

Step 1: Organize your IT capabilities for a hybrid world.

Let us be honest: none of our enterprise sized customers will be “Cloud only” any time soon.  All of them are in some kind of state of Cloud adoption. But the reality is hybrid, and that has a significant impact on your operating and/or organization model.

At 45 Degrees we have been designing and updating a model for a Cloud Center of Excellence for the last years. One of our customers recently pointed out that it’s not really a “Cloud” center of excellence, but rather a “transformation” center of excellence. And we have to admit: he’s not wrong. There are a series of topics you need to cover to get a smooth working IT division that serves both the business IT and business divisions in the best conceivable way. We call those topics “capabilities”, and they are not so fundamentally different from running a pre-Cloud, on-premises IT division. The difference lies underneath the surface of these capabilities. A couple of examples:

  • The way you handle reference architectures is something you also do in an on-premise world. But what needs to be done, how dynamic it is, all of that is quite different in a Cloud/hybrid world.
  • The way you deal with licensing is something you obviously already did. But in a Cloud world, this is a very different exercise.

When structuring these capabilities, we look at 6 categories:

  1. Strategic capabilities
  2. People capabilities
  3. Governance capabilities
  4. Platform capabilities
  5. Security capabilities
  6. IT Operations capabilities

Each category covers a set of capabilities. At 45 Degrees, we usually start by an assessment based on our “best practice” set of capabilities. First, we only did this at the start of Cloud adoption journeys, but now it’s integrated in our way of working. We also “customize” these capabilities to the specific customer situation. By doing that exercise, we get a clear understanding of what the customer needs to make it work.

This is a crucial step, but only the beginning. With our capabilities defined, we can get to deciding the accountabilities.

Step 2: What is an accountability model and what does yours look like

News flash: autonomous product teams that will do everything themselves, including 24/7 IT operations are NOT going to work in an enterprise environment.

Remember the famous Spotify accountability model that we wrote about? The one that Spotify themselves never used? AKA one of the biggest myths of the IT business. So let’s get realistic and pragmatic, and stay far away from the Spotify model.


So what is an accountability model?

“An accountability model is a framework that defines the roles, responsibilities, and processes for ensuring that individuals and teams within an organization are held responsible for their actions and decisions related to IT.”

Basically, it helps to establish a culture of accountability and transparency and ensures that there is a clear understanding of who is responsible for what within the organization.  

To use an accountability model to create the operating model in the next step, we focus on the part of roles and responsibilities. Therefor, we look at the IT reality in four dimensions:

  • Platform Engineering: the work done to prepare the IT platform towards the users.  (This used to be the infrastructure team in an on-premise environment.)
  • Platform Operations: the work done to support the existing IT landscape.
  • Applications Engineering: the work done to develop applications.
  • Applications Operations: the work done to support applications.

All of the IT processes run across these four dimensions, typically covered in an Information Technology Infrastructure Library (ITIL) or IT Service Management (ITSM) like the one below:

Diagram

Description automatically generated

However, in a real-world enterprise, the traditional accountability model looks something like this:

Timeline

Description automatically generated

As you can see, there is:

  • a platform engineering team (often called the infrastructure team)
    crosses over towards operations and towards applications (e.g., deployments…)
  • an IT operations team
    will also cover part of the application operations, until it is clear it is a coding problem
  • and there are application teams.
    who support the coding problems

You can obviously design as many variations to this as you want depending on your organization. A typical “Cloud” model that is often referenced is this model:

Chart

Description automatically generated

This model is often referred to as “The DevOps model”, but fits within a Cloud environment as DevOps is a key concept there. However, it looks a lot like the Spotify model that shows it won’t work across complex enterprises. The word “across” here is important. At some of our customers we see that some specific teams, with a specific scope can operate like this. But not the majority of the organization.

With our accountability model in place, we can get to defining the operating model that we’ll use to actually get to work! 

How we do that and why you should use one, you’ll discover next week in the second part of this series!

Stay tuned!