An operating model for Enterprise DevOps

Publish date:

DevOps is seen as the digital foundation for improving time to market and launching innovation initiatives to respond to dynamic and disruptive market scenarios.

The year 2018 was proclaimed the year of Enterprise DevOps by industry experts. Over the past few years, the DevOps concept has rapidly evolved from being just an enabler of “development efficiency” to being a driver of “business agility” for enterprises. DevOps is seen as the digital foundation for improving time to market and launching innovation initiatives to respond to dynamic and disruptive market scenarios. Organizations across domains such as automotive, life sciences, healthcare, and manufacturing are creating or aspiring to create their own “Enterprise DevOps” strategy.

Based on my experience, I am listing key ingredients for a successful Enterprise DevOps strategy:

  1. The ability to run agile teams at scale across the entire business and technology portfolio of an enterprise

An enterprise portfolio should ideally be structured in a logical hierarchy of value chains and products, with the sprint teams being aligned to products. Sprint teams operate seamlessly across the service areas of business, development, and operations to deliver speed, quality, and innovation. Sprint teams take end-to-end responsibility for product(s) within a value chain. “Product orientation” is a trend many enterprises across sectors are adopting.

  1. A single agile team construct for addressing both development and maintenance activities for applications

This means managing projects, enhancements, fixes, L2, L3, and operations through an integrated product backlog and a common agile governance. A certain capacity of agile teams needs to be reserved for maintenance and operations work. In addition, service management aspects such as SLAs, 24/7 support, and emergency fixes need to be handled through synergy and rotation within the same agile teams.

  1. A multi-technology DevOps strategy that is attuned to the unique needs of different technology platforms and business domains

The typical considerations for a DevOps target model include the nature of skills, tooling, release speed, the platform being used, and the extent of automation. These considerations are quite different (and unique) for different technology clusters such as SAP, digital, and middleware. Moreover, they vary based on whether the application is a system of records, system of innovation, or system of differentiation. DevOps continuous integration/continuous delivery (CI/CD) is very specific to the technology platform that is used. For example, we need specific tool chains for Java, .NET, ETL, or BI applications. Packages such as SAP have their own tooling that is native to the platform.

Image Source

  1. A centralized DevOps guild

Setup a central DevOps team to steer the overall DevOps strategy and way of working for the sprint teams working across the enterprise. This function is also responsible for strategic decisions on standardizing the stack, automation, and scaling across the enterprise. 

  1. Automation everywhere

Drive automation across the entire lifecycle of a service: continuous integration (code quality, build, and unit test automation), continuous testing (UI test automation, regression test automation of end-to-end scenarios spanning digital to middleware to ERP), continuous monitoring (flow and feedback – user telemetry, proactive diagnostics), continuous deployment (deployment strategy integrating application, database, environment configuration aspects across application and infrastructure, infra as code)

  1. Shared KPI framework across partners

This is a multi-partner collaboration model defined and driven by the central DevOps guild – the roles, responsibilities, and shared objectives focusing on end-to-end KPIs.

  1. New-age Infrastructure as an enabler of business agility

Modern enterprises choose infrastructure platforms with cloud-native capabilities enabling the creation of “application services” and not merely “infrastructure services.” This means highly agile applications running on microservices and powered with native CI/CD can be easily setup on such platforms.

Enterprises have started incorporating these ingredients into their way of working. Hence it has become imperative for IT vendors to incorporate these characteristics into their sourcing models, delivery approaches and contractual constructs.

Amarendra Deshpande is an Enterprise Architect helping enterprises with modernization and adoption of new age solutions. You can contact him at or 91-9870369690.’

Related Posts


Delivering faster with better use of micro-frontends in financial services

Date icon September 21, 2021

What works well is multiple SPAs owned by specific DevOps teams that can decide what happens...


No one likes waiting. With Continuous Delivery, now you don’t have to!

Venky Chennapragada
Date icon March 22, 2021

Automated and on demand – here’s how, why, and when you should adopt Continuous Delivery...

cloud services

Product-oriented delivery, enabled by POD models

Rishi Kulkarni
Date icon November 26, 2020

Why POD models are the future