DevOpsGroup has joined Sourced, an Amdocs company. Read more about this partnership and what this means for the future in our blog.

DevOpsGroup Blog So, you’re doing DevOps. But what about self-service?

So, you’re doing DevOps. But what about self-service?

The big question for any tech scale-up is how to grow revenue without a parallel increase in underlying costs. Boosting teams’ productivity levels is the simple answer. But achieving this without risking burnout, system instability and high levels of technical debt is not so straightforward.

This is where DevOps ways of working come to the fore. And a shared self-service approach to modern operations is the jewel in the crown.

On-demand self-service has long been considered an essential characteristic of cloud computing, as per the National Institute of Standards and Technology (NIST) definition. But it can be one of the hardest cloud-based capabilities to implement. This blogpost looks at why it deserves to be a priority.

DevOps and on-demand self-service

The DevOps toolchain ecosystem is vast. The (formerly XebiaLabs) ‘periodic table of DevOps’ includes more than 120 tools in 14 separate categories. Expecting each team to navigate such complexity for themselves risks duplication and wasted effort. Combine this with the growing number of cloud vendor services (175+ for AWS and 600+ for Azure) and the challenge becomes even greater.

What’s needed is curation – selecting an agreed set of tools and offering them to delivery teams as self-service platforms.

This doesn’t mean some central team buys an ‘Enterprise DevOps Platform’ then mandates and enforces its use. Platform selection (curation) and build requires close collaboration between consumers (the delivery teams) and producers (the platform teams). We’ll explain later how InnerSource thinking can be critical here!

From the delivery team perspective, this approach offers huge benefits. They don’t have to reinvent the wheel each time they need to integrate a core service or capability. They don’t even need to post a request to another team. Instead, they should simply take what they need, when they need it, paid for on-demand. Better still, key organisational concerns like security, governance and compliance are ‘built-in’ to the platform itself.

So, does this mean you don’t need operations engineers on a DevOps team? Possibly not. DevOps is a philosophy, not a team structure model. It doesn’t necessarily equate to development and operations colleagues working on the same team.

In any tech scale-up, success hinges on the ability to accelerate software development while ensuring systems are stable and resilient.

To achieve this, developers need to be mindful of operability and operations engineers need to facilitate rapid innovation. They might sit on the same multidisciplinary team. But they don’t have to. A separate operations team can provide platform-based services via an overarching Platform as a Service framework.

Take the Google Site Reliability Engineering model. It relies on Application SREs to manage the application and Platform SREs to build the shared tooling. They work in separate teams to the application delivery (product) teams.

Benefits of platform-based services

Consistency and quality

A platform-based approach standardises a curated set of shared toolchains. This reduces margin for error and makes operability and security more consistent across the organisation. Platforms make it quicker to build new features or applications and simplify ongoing management.

Smaller teams

With shared self-service operations provisioned independently, it’s easier to achieve the ideal team size of seven plus or minus two. This fosters better cohesion between team members, whether they’re focused on product delivery or the operations platform. Smaller teams are also more conducive to psychological safety. 

Fewer dependencies

Automatic self-service operations mean delivery teams don’t have to raise tickets or wait for their requirements. Eliminating dependencies is central to modern ways of working, enabling autonomy, accelerating progress and reducing waste. 

Building a shared self-service platform

The below diagram shows a high level design of a typical shared self-service platform for operations.

Product delivery teams have direct access to enablement services covering everything from security and compliance to test automation and continuous delivery. All these core services are provisioned as code and managed by a dedicated platform team. Handling them in this way ensures better consistency, cost management and governance.  

For scale-ups, this offers a way to enhance products’ operability, resilience and security while increasing velocity of development. It will also reduce the risk of new technical debt being incurred.

Overall standards are controlled and optimised at the organisational level. Which means delivery teams can focus on creating meaningful customer value that drives loyalty and competitive differentiation. They can adapt and iterate products safe in the knowledge that the underlying infrastructure has been taken care of.

Self-service platforms can also encompass reference architectures to guide best practice.

Blending self-service with InnerSource

When the self-service model is combined with an InnerSource strategy it can be improved further. (Check out our recent blog How DevOps helps with technical debt for an intro to InnerSource).   

In short, this approach enables platform services to evolve over time in close alignment with delivery teams’ needs.

The platform team builds the self-service platform, then shares the source code via a code repository (repo). From here, they hold responsibility for overall maintenance of the repo, but anyone can contribute to it.

So, if a delivery team needs to extend something a platform team has created, they can build it themselves. As with an open source project, the required change is coded, then submitted to the platform team as a pull request. Once reviewed and approved, the change can be merged into the main codebase.

In many ways, this represents the gold standard for DevOps. Development and operations colleagues work synergistically and collaboratively. Everyone strives for the same goal: value-driven customer experiences via reliable digital products that meet of-the-moment needs.

The end result is dynamic, rapid and secure innovation that gives your business commercial edge.

Shared self-service operations is a critical enabler for any tech scale-up. Are you ready to take your DevOps capabilities to the next level of maturity?

For more advice on how tech scale-ups can operate with speed and stability, check out our whitepaper: Accelerating growth with Cloud and DevOps.

Leave a Reply

Your email address will not be published. Required fields are marked *