Ensuring Business Benefit from DevOps

DevOps is an area of focus for everyone these days. DevOps is expected to be a solution to many problems ranging from IT responsiveness to customer satisfaction. However, one common expectation from DevOps is to reduce Time to Market or increase Speed at which organizations can change/adapt/deliver new features to their customers. This capability can be defined as “Agility” or “Business Agility” that is required for a business to meet its goals.

However, unfortunately most who attempt to adopt DevOps are unable to realize tangible business benefits from its adoption. This stems from an assumption that DevOps is primarily about implementing a DevOps toolchain with an eye on increasing automation levels spanning the development and operations lifecycle. However, DevOps, is much more than automation and tool-based interventions. Its adoption requires organizational change affecting several dimensions of which tool usage is just one of them.

If you’re looking to avoid wasted investments through half-hearted attempts at DevOps implementation replete with multiple duplicating toolsets, here are 3 top recommendations to make your DevOps implementation a true business success.

# 1 Define and Articulate What Constitutes DevOps Success

It is critical for management to define in business terms what benefit is expected from DevOps adoption. This is the most important prerequisite for DevOps success. For example, A Retail Bank can have a goal of increasing the % of mobile transactions to 70% in 2 yearsor an airline expect an ability to launch digital ancillary within 4 weeks, a Health insurance provider can aim for an ability to launch a new micro insurance product within 2 months or an e-commerce firm’s goal could be to add a new supplier within 5 days on their SaaS platform. Once we have such a goal defined, it needs to be visualized, explained to various teams as to why this is important for the business. Creating such a shared goal across various teams (whether traditional or cross functional) goes a long way in laying the foundations of a DevOps success story. 

# 2 Leverage DevOps Success Criteria to Drive Downstream Goals

Once the overall business agility objective is defined, it can then be used to drive downstream agility objectives at the platform, process or team level. Taking an example of the objective of “Being Able to add a supplier within 5 days”, we can define downstream objectives as:

  • Platform Level: Being able to have plug-n-play integrations with suppliers so that we can add or remove suppliers without having an impact on other integrations. This capability has implications on the architecture of the integration solution, technology choice and infrastructure on which it is deployed and subsequently monitored.
  • Process Level: Being able to do feature based releases where change to a specific supplier integration or its addition/deletion can be released independent of others.
  • Team Level: Enable the development teams who are doing the actual code changes, deliver integrations that are production ready. This requires developers to take full ownership of the code they deliver right up into production.

In reality, what most organizations adopting DevOps, do is simply identify areas where automation is lacking. Mostly, this happens to be in various forms of functional & non-functional testing, environment provisioning, deployment, release management and straightaway start adopting toolsets which address these gaps. On the process side, they implement various forms of Agile processes and start delivering iteratively. This bottom up approach may or may not meet the business objective defined initially or worse, it may end up being an overkill.

# 3 Establish a Clear Roadmap Spanning Process, People, Automation, Infrastructure, and Architecture

What is really required is to not rush into various tool implementations. A DevOps success always needs holistic change across the dimensions of Process, People, Automation (or Tools), Infrastructure and Architecture. The extent of change required across these will be determined by what are your end objectives. For example, changes required to enable a release cycle of 3 days will be very different from if a release cycle of 4 hours is desired. 



Difficulty/Resistance to Change


  • Kanban adoption
  • Feature based releases
  • Limit work in progress
  • Easy if organization has already embraced agile. If not, then things can be challenging due to cultural elements mentioned below


  • Remove silos of dev/test/operations
  • Teams have ownership of delivering code to and managing it in production
  • Organize by products instead of projects
  • Extremely difficult and may need training, reskilling and even changes in people and structure of organization

Automation (Tools)

  • Full lifecycle automation with Application Lifecycle Management integration
  • Continuous integration, testing, deployment and monitoring
  • Easy as compared to other dimensions and primarily requires investments in tools and effort 


  • Self-service infrastructure
  •  Infrastructure-as-a-code
  • Cloud (lift and shift)
  •  Easy as compared to other dimensions


  • Loosely coupled and discoverable components
  • Micro-services
  •  Cloud Native and serverless 
  • Difficult as may need huge investments in reengineering of monolithic architectures

Organizations should identify gaps across all these five dimensions and prioritize them based on the business need, investment requirement and appetite and then move ahead with the adoption. During the journey, continuous inspection and adaptation of the roadmap is required depending upon what is working and what is not.

Anti-Patterns to watch out for

  • Starting on DevOps journey without a business linked success criterion
  • Consider DevOps as being limited to implementation of tools and rushing into their implementation
  • Ignoring the people aspects in terms of skills and aspirations. This is one of the most difficult dimensions to address
  • Ignoring the architectural limitations of the application(s) in scope. If the architecture is monolithic, then tools, process and automation can only get you so far
  • Attempting a big bang approach. DevOps is a journey and not a project.

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
10 + 9 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.