How to build Operating Model and DevOps Platform

In BlueSoft we believe that it is better to plan and execute the DevOps Platform Strategy than leave it to chance – and together with careful selection of technologies building it, we also prefer to design the responsibilities boundaries and agreements between teams building the platform and teams using it. This is what we call DevOps Operating Model, which needs to be tailor-made for the Organization.

Designing DevOps Operating Models

There is no one, universal DevOps Operating Model which will fit every company – because it needs to reflect delivery maturity, culture, technology stack and teams’ organization. Combined, those factors create a unique landscape of Software Delivery for every organization – where Operating Model should simply fit. So, to plan DevOps Operating Model, we need to first discover Organization Culture and Delivery Practices.

Understanding Delivery Practices

We start planning DevOps Operating Model by understanding the as-is and to-be state of how the Organization delivers the Software. We combine market-proven techniques (like Flow Framework, Value Stream Mapping) with our own techniques (BlueSoft Delivery Maturity Assessment, DevOps Maturity Profiling, DevOps Platform Capabilities Investigation) to understand how Delivery Teams are building Software, which supporting technologies they use – and where lays their current responsibility for the Software Architecture components they are running. It also gives us a chance to understand the structure and cooperation practices between the Teams.

BlueSoft Delivery Maturity Assessment workshop allows us to understand, which tools Teams are using – which are they responsible for, and how they support their delivery processes.

Understanding Teams Cooperation & Architecture Boundaries

Once we understand, how teams are working and which tools they are using – we go one step further and discover the model of cooperation between teams, with their responsibilities, ways of interacting, provisioned services and value streams.

Each organization is unique – so we aim to discover the current and the desired state which will fit the organization. We start with a review of reference models of cooperation, which gives us a chance to select the one closest to reality – upon which we define the as-is state of organization. Then – we go through the reference models again, and mapping responsibilities and architecture components into the Teams, we build a desired state with our customer. This desired state becomes our target, on which we build a strategy and backlog to achieve it.

Sample Reference Models for Delivery Teams. By comparison and desired outcomes, we are tailor-designing the target model for each organization.

Designing DevOps Platform Team Services

Having a desired state of Teams cooperation and responsibilities – we can focus on DevOps Platform Team and shape the services they will be providing to other teams. At this point the DevOps Platform already have the technical design – so we can shape the services around technical capabilities which our architecture will provide. Based on the results of BlueSoft Delivery Maturity Assessment (and Flow Framework), Platform Team can prioritize on delivered services – and based on target state of Teams Cooperation and Architecture Boundaries, we define how the services will be provisioned.

Example: High-Level Services & Responsibilities part of Operating Model for DevOps Platform Team as a single point of contact for Software Delivery Teams – utilizing other IT Teams Services.

Our approach is a practical implementation of Team API pattern (https://github.com/TeamTopologies/Team-API-template), well defined in “Team Topologies” by Matthew Skelton and Manuel Pais. In this article we focus on DevOps Platform Team, but the same approach can be applied to Data Platform, API Management and Teams serving technical capabilities (like OCR or Voice Recognition) to others within the organization.

Implementing DevOps Operating Models

Operating Model is not something theoretical – because it directly impacts the way how DevOps Platform Architecture is shaped and cooperation between Platform and Delivery Teams looks like. It also influences technology selection and DevOps toolset delivery methodology. Alike each implementation – Operating Model also requires a low level design and delivery backlog.

How the Operating Model impacts technology selection and DevOps architecture?

Let’s have it on example – with mature organization and teams which have DevOpses within their Product Teams, DevOps Platform Team can allow Product Teams to have own k8s cluster with cluster admin rights. It means that each Product Team have own cluster, with own runners for delivery pipelines and ability to optimize their Product on the cluster level. However, the same approach can bring harm to the organization with central DevOps unit, lacking such capabilities within Product Teams – here a better fit can be one cluster with dedicated namespaces for the teams (and taking over delivery pipelines by central DevOps Unit – making it possible to use less flexible CI/CD technology in terms of user permissions)

DevOps Operating Model should be reflected within DevOps Platform Architecture – by definition of responsibilities for each component and setting-up delivery pipelines for agreed scope of changes for each responsible party. In short – implementation of DevOps Operating Model should have a reflection in backlogs and delivery done by Platform and Business Applications Teams.

It is easier to be explained by the example. Let’s take the Operating Model with central DevOps Platform Team, which is responsible for providing and maintaining infrastructure, observability & deployment components (so the Business Application Teams can only focus on delivering and maintaining their software). In such a case, Platform Team will be responsible for delivery and operations around the cluster, deployment pipelines creation, infrastructure, serving database & storage space and observability toolset. Business Application Teams will be responsible for delivery and operations around their Software – so they will have permissions to customize build pipelines, create dashboards, alerts and filters within logs and traces, manage database and provide operations around Business Applications. Those responsibilities translates directly to the delivery backlog of teams – where DevOps Platform Team will serve all technical components necessary to build and run business applications; and Business Applications Teams will conclude their backlog with business features.

An example on how Central DevOps Platform Operating Model is reflected within Architecture Boundaries

A result of Operating Model implementation is working set of services which teams are provisioning to each other; clear communication and requesting rules for those services; teams oriented within their target value streams and responsibilities; SLA/SLOs around those services – and architecture components with rules and permissions supporting the agreed Operating Model. In one sentence – technology components operated by teams within agreed responsibility scope.

Scaling the Model: Services Automation & Responsibility Distribution

Once the Operating Model is implemented – the journey is not over! Organization is changing, and well-defined and working Operating Model will only speed-up the positive trends. It is crucial to observe and adjust the model to those changes. One of the biggest challenges here is scaling the existing model to serve a fast-growing company (and trust me – well defined model with boost this growth more than you expect).

To scale the Operating Model, we need to boost the service provisioning processes by the teams. Here comes the automation – but we need to carefully select what exactly we want to automate – because automating each service may not be the best approach. Let’s discuss that on example which we had in one of the Banks we are co-delivering the DevOps Transformation. Knowing the growth strategy of the bank, and observing service provisioning demand, we knew that the first automation to be done within the Platform needed to be delivered for onboarding process. Within less than half a year ten business domains started using our Platform – so the demand for providing new delivery teams with resources were huge. Automating this process ended up with serving the environments within hours (where we started with the days). Scaling this part up, we were able to focus on building more flexible permission model for each Platform tool and scale the model with new services being provided in standardized way.

A way to scale Operating Model is distribution of responsibilities within the Platform. This approach for scaling we have played in parallel to the service automation in the bank we already mentioned. After some time while the Platform was operating, we noticed a growing maturity and awareness of DevOps practices in Business Applications Delivery Teams. It allowed us to enable DevOps Onboarding service being provisioned – where selected engineers in the most mature teams started to have more permissions for changes which normally had been done by DevOps Platform Team. Scaling had been played by changing the model into more distributed approach for managing DevOps Platform, flexible depending on the Delivery Team maturity. This small change in Operating Model, done by limited number of teams, allowed us to test how the organization will perform in target, more mature model we were planning – a more scalable one, combined with mature, DevOps-aware and skilled Delivery Teams. In other words – scaling the model for organization growth changed the very model itself – but it had been driven by the growth, which had been planned and carefully executed.

How to start with DevOps Operating Models?

We hope that you have just done the first step – by realizing what the Operating Model is and why it needs to be designed. The topic is often dimmed by technology & architecture of DevOps Platforms – while it should be a driver for any DevOps related discussion! We have seen many DevOps Platforms, which stopped their developments with technology, producing a lot of capabilities which no-one (besides DevOps Teams) knew how to properly used. A car without a steering wheel. We have also seen Operating Models growing organically, without any strategy and plan – and we saw the difficulties and failures such approach creates. You don’t need to fail ten times to have a best-fit Operating Model – we experienced this process to be smooth when it starts with a design phase. And we have combined our own Framework, described briefly in this article, which reduces mistakes and speeds up creation of tailor-made Operating Model.

Operating Models within DevOps Platforms (and DevOps Platforms in general) is only a part of a bigger topic – full scale DevOps Transformation. In BlueSoft we have concluded all our technical toolset, know-how and analytical frameworks under one Starboost Framework, which we are developing since 2017. Multiple Customers trusted us not only with Operating Models, but also Digital Transformation, Platforms and Applications delivery with Starboost. Don’t hesitate to contact us, allowing Starboost to became your tailor-made transformation approach!

Starboost is our Digital Transformation Canvas. Definition and implementation of Operating Model is only a small – it works the best combined with platforms, culture and technology strategy.