How DevOps Evolved and Why It Became Confusing
Product & Delivery
IT Architecture
In this blog, Opencast Practice Lead Scott McCarthy explores how DevOps has evolved from a response to the challenges of modern software delivery into a widely adopted approach. Drawing on experience working with complex delivery teams, he reflects on how the original intent of DevOps has sometimes become less clear as organisations focus on tools and structures alongside culture and outcomes.
This is Part One of a two-part series, focusing on how DevOps emerged, why it can be perceived as confusing, and where organisations commonly face challenges when putting it into practice.
Why DevOps Had to Evolve
We are firmly amid the Fourth Industrial Revolution. Software is no longer a support function; it is central to how organisations deliver services, generate value, and respond to change. From government services and financial systems to energy, healthcare, and transport, software underpins almost everything we rely on. As expectations increased, traditional IT operating models struggled to keep pace. Long lead times, rigid handovers, and siloed accountability slowed delivery and increased risk. Organisations needed a way to move faster without sacrificing stability.
I’ve seen this first-hand in programmes where delivery teams were under pressure to accelerate, but were constrained by manual processes, fragmented ownership, and unclear accountability. In these environments, improving flow wasn’t just about efficiency — it was essential to reducing risk and enabling teams to respond to change with confidence.
When software becomes the business, slow and fragmented delivery stops being an inconvenience and starts becoming an existential risk. In several organisations I’ve worked with, this resulted in delivery teams becoming dependent on central DevOps teams, slowing down delivery and increasing bottlenecks rather than removing them.
Cloud Didn’t Create DevOps — But It Accelerated It
DevOps principles existed before cloud computing, but the cloud created the conditions for them to scale. Programmable infrastructure, elastic environments, and on-demand resources fundamentally changed how teams built and deployed software.
Applications evolved alongside this shift. Monolithic systems gave way to distributed, cloud-native architectures composed of microservices that could be deployed and updated independently. This increased speed and flexibility, but it also introduced a new level of complexity. That complexity made it clear that isolated development and operations teams were no longer viable.
Agile Was a Step Forward — Not the Final Answer
The Agile movement had already transformed how software was developed by encouraging small batches, fast feedback, and close collaboration with users. However, Agile largely focused on getting software built, not on how it behaved once it reached production.
In many organisations, this created a new tension: teams could develop features quickly, but releasing and operating them remained slow and risky. DevOps evolved to bridge this gap, addressing the full lifecycle from idea to operation.
What DevOps Was Originally About
When the term “DevOps” was coined in 2009, it was never intended to describe a new department or job title. It was an attempt to address systemic friction in software delivery by encouraging shared ownership, improved flow, and continuous learning.
Early DevOps thinking emphasised that real improvement started with how work was organised and owned. Tools and automation were important, but only as enablers. Without changes to culture and behaviour, technical improvements rarely delivered lasting value. DevOps was always about changing how people work together — not just how software is deployed.
Culture Was Never Optional
As DevOps gained momentum, it quickly became clear that tooling alone could not create meaningful change. Some organisations invested heavily in CI/CD (Continuous Integration / Continuous Delivery) pipelines and cloud platforms while leaving underlying behaviours untouched. Frameworks such as CALMS (Culture, Automation, Lean, Measurement, Sharing) reinforced that DevOps depends on culture, automation, lean thinking, measurement, and sharing. Without trust, collaboration, and a willingness to learn from failure, DevOps practices struggle to take root. This is why DevOps has always been described as a journey rather than a destination.
How DevOps Became Confusing
As DevOps adoption accelerated, so did the tooling ecosystem. Thousands of products entered the market, each promising to “enable DevOps” in a slightly different way. At the same time, organisations began creating “DevOps teams” to centralise responsibility for automation, pipelines, and infrastructure. In many cases, this recreated the very silos DevOps was designed to remove. Development teams still built software, operations teams still ran it, and a new DevOps team sat uncomfortably in the middle.
This sometimes resulted in delivery teams becoming dependent on central DevOps teams, slowing down delivery and increasing bottlenecks rather than removing them. In these scenarios, DevOps didn’t fail, but it was often implemented in ways that contradicted its original intent.
DevOps: Breaking Down Barriers and Navigating Complexity
DevOps fundamentally changed the way software was delivered by eliminating the traditional divisions between development and operations teams. This shift empowered organisations to deliver software at greater speed and with improved reliability. As DevOps principles gained traction, the benefits of enhanced collaboration and streamlined workflows became evident across many teams.
However, widespread adoption brought its own challenges. Misunderstandings and misapplications of DevOps practices began to surface. With each new business challenge, the industry responded by introducing fresh acronyms—such as FinOps for financial operations, SecOps for security operations, BizOps for business operations, GreenOps for sustainability, and most recently, AIOps for artificial intelligence operations. These new terms frequently emerged as attempts to address specific organisational needs but often led to confusion and a drift away from the original intent of DevOps.
Conclusion
This article explored the origins of DevOps, the role cloud computing played in accelerating its adoption, and how many organisations lost sight of its original purpose as specialised practices and terminology grew.
In the second part of this blog series, we will look at how the future of DevOps is likely to unfold, particularly as artificial intelligence becomes more embedded in engineering practices. We will explore the trends shaping the next phase of DevOps and what AI-enabled engineering could mean for organisations aiming to deliver reliable, efficient, and innovative solutions.
OpenPerspectives is our platform for Opencast people to share their thoughts and perspectives on modern digital delivery. It offers practical insight into user-centred design, engineering excellence, product leadership, data-driven decision making and building expert capabilities, grounded in real-world experience.
