Fragmented DevOps = Minimal Value | Blog

Enterprises are increasingly embracing DevOps to enhance their business performance by accelerating their software time-to-market. In principle, DevOps covers the entire spectrum of Software Development Life Cycle, SDLC, activities from design through operation. But, in practice, only ~ 20 percent of enterprises are leveraging DevOps end-to-end, according to our recent research, DevOps Services PEAK Matrix™ Assessment and Market Trends 2019 – Siloed DevOps is No DevOps!


That means the remaining ~ 80 percent that are taking a siloed approach to DevOps are missing out on the many types of values it can deliver.

Types of DevOps fragmentation

Instead of adopting DevOps in its intended end-to-end fashion, many enterprises in different verticals and at different stages of maturity are tailoring it to focus on siloed, distinct portions of the SDLC. The most common types of fragmentation are: 1) Apps DevOps, applying DevOps principles only across the application development cycle; 2) Test Ops, using DevOps principles in testing; and 3) Infra Ops, applying DevOps principles only to infrastructure.

Why fragmentation delivers minimal value

Pocketed adoption makes it tough to realize the full value that DevOps can deliver. The primary reason is bottlenecks. First, workflow throughout the SDLC is impeded when DevOps principles and automation are only applied to certain phases of it. Second, lack of end-to-end adoption makes it more difficult for enterprises to gain a full view of their applications portfolio, spot bottlenecks, incorporate stakeholder feedback in real-time, and make the entire process more efficient.

Additionally, when DevOps is used in a siloed manner, it focuses primarily on increasing the technical efficiency of processes. This means that DevOps’ ability to support the enterprise’s broader business-oriented objectives is severely restricted.

Finally, fragmented DevOps adoption creates a disintegrated culture in which teams work independently of each other, in turn leading to further conflicts, dependencies, and stretched timelines. All this, of course, defeats DevOps’ main purpose.

Moving to end-to-end DevOps adoption

To successfully adopt DevOps end-to-end, enterprises should place automation, culture, and infrastructure at the heart of their strategy.


  • Automation: Automating various elements of the SDLC is extremely beneficial; doing so helps reduce implementation timelines and increase team productivity by standardizing processes and diminishing the scope of errors
  • Culture: A collaborative culture is essential to a successful DevOps implementation as it involves the development, operations, and business teams working together in an iterative fashion to achieve cross-team and business-oriented KPIs
  • Infrastructure: Increasing adoption of cloud-native technologies like as infra-as-code, microservices, serverless, and containers helps maintain configuration consistency in deployment, eventually leads to an increase in developer productivity, and saves on cloud computing costs.

DevOps has the ability to deliver significant value to enterprises. But implementing it in a siloed manner quickly dilutes a lot of that potential value. To realize all DevOps’ benefits, enterprises should implement it end-to-end, invest in automation, robust and modular infrastructure, and tools and technologies to ensure agility, and develop a culture that helps them improve cross-team collaboration.

What has been your experience in your DevOps adoption journey? Please share with us at [email protected] and [email protected].

Digital Transformation: the Future of SDLC is not DevOps, it is “no SDLC” | Sherpas in Blue Shirts

One of the keys to successful digital initiatives is quick release of better application functionalities. Enter DevOps, the philosophy of automating the entire infrastructure set-up, quality assurance, environment provisioning, and similar processes to quicken the pace of application delivery. Everest Group research suggests that 25 percent of enterprises believe that DevOps will become the leading model for their software development lifecycle (SDLC) in the next three to five years. While this number appears small, I am quite upbeat seeing it.

But, let’s step back for a moment. What if SDLC was no longer a lifecycle with different demarcated teams but instead a point in time that kept repeating itself? This “no SDLC” concept would make discrete processes within the traditional SDLC disappear or collapse (not compress) into one. Enterprise shops wouldn’t have to fret over these processes anymore.

I believe a no SDLC future will come faster than we expect. Here are four key indicators:

  1. Serverless: Amazon’s introduction of Lambda a few years ago and now Microsoft’s introduction of Event Grids to enhance Azure functions, has brought serverless into the spotlight. Everest Group research suggests that 10-15 percent of new application projects leverage serverless architecture to a certain extent. The philosophy behind serverless – getting the required infrastructure as and when needed rather than provisioned initially – is very strong. So, if we don’t need long-drawn infrastructure set-up, why would we need DevOps? The developers can focus on coding rather than managing the infrastructure their applications will run on. True that this is a strong theoretical argument that needs to be tested. However, the value it brings to enterprises cannot be ignored.
  2. Artificial Intelligence: Why can’t applications create themselves and drive everything on their own? Most software projects begin by understanding business requirements. What if AI systems could understand past user behavior and automatically predict the requirements, making the traditional phase redundant? These AI systems could also manage the underlying infrastructure in an event-driven manner, instead of architecting the applications for specific infrastructure.
  3. Automation: Automation across the SDLC is becoming pervasive, moving into previously unexplored areas. Enterprises are experimenting with automation to convert business requirements to technical specifications, Agile teams are automating user stories, and IT operations teams are automating the provisioning, configuration, and management of infrastructure. Adding cloud, the old hat, into the mix creates a fundamentally different SDLC. Given the application infrastructure (middleware), infrastructure management, and updates, moving to the cloud fundamentally reduces an application team’s need for downstream activities.
  4. Lowcode: Companies such as Appian, K2, and Outsystems have made a strong case for low-code development. This has less to do with making SDLC a point-in-time activity, but it is still very relevant. If developers (or business users with less coding experience) can leverage these platforms and rapidly deliver applications, the functionalities will be created and deployed at run time. The key reason we have downstream management is that once features are built, they are protected and managed by the IT operations team. Low-code allows developers to deliver functionalities rapidly, even possibly on-the-fly, and reduces the need for large-scale management.

All the above will eventually tie to the nirvana of the as-a-service economy. It’s the software development equivalent of buying a car and maintaining it for years, versus getting a new, worry-free car every day (sounds like Uber, right?).

The current no SDLC wave is about compressing the processes to blur the lines between the different phases. Once the above future is achieved, no SDLC will expand to make the processes unnecessary, rather than shifting responsibilities outside the enterprise. Organizations that really want to succeed in the digital world must strive towards this goal and commit to a no SDLC world.

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

"*" indicates required fields

Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.