This article is based on analysis originally published at gigaom.com (2017) and expanded for a DevOps engineering audience.
Iteration Was Never a New Idea
When Barry Boehm formulated the Spiral Model of software development in 1986, he was not inventing iteration from scratch. Faster, incremental development cycles had existed in practice long before his paper. What Boehm did was present iterative delivery as a credible, formalised alternative to the exhaustive, sequential approaches — most notably the Waterfall model — that dominated thinking at the time.
The Spiral Model placed risk analysis at the centre of each development cycle, combining elements of both iterative development and the structured discipline of traditional engineering. In doing so, it set the intellectual groundwork for what would eventually become Agile methodologies, and later DevOps.
The Persistent Stigma of Moving Fast
Despite decades of evidence, fast and iterative approaches to software delivery still encounter resistance in many organisations. The perception — however unfounded — is that speed comes at the cost of quality or discipline. This prejudice is as logical as judging a developer’s competence by their dress code: it says more about the observer than the observed.
Boehm himself addressed this tension directly in his 2004 book, Balancing Agility and Discipline: A Guide for the Perplexed. The title alone captures the dilemma that engineering organisations continue to wrestle with today: how to move quickly without sacrificing reliability, security, or maintainability.
From Development Speed to Operational Bottlenecks
Over several decades, faster delivery has proven itself as a sound business strategy — not just an engineering preference. As development pipelines accelerated through Agile adoption, organisations began to notice that the bottleneck had shifted. Development teams could ship code faster than operations teams could safely absorb and run it.
This is the precise problem DevOps was designed to solve. By aligning development and operations around shared goals, shared tooling, and shared accountability, teams can eliminate the handoff friction that slows delivery and increases operational risk.
Anyone who has worked on both the development and operations sides of a production system understands how difficult it is simply to keep services running in a fast-moving technical environment — let alone to improve them continuously. The operational burden is real, and it is not going away. What can change is how much of that burden is carried manually.
The Two Pillars of Effective DevOps
Sustainable DevOps rests on two interdependent foundations:
- Cultural and process alignment: Development and operations teams must agree on a shared approach, a shared mindset, and a set of formalised controls. Without this alignment, automation simply accelerates dysfunction.
- Automation of those controls: Once the right controls are defined, automating them removes friction, reduces human error, and frees engineers to focus on higher-value work. Automation is how teams get the benefit of rigorous process without being paralysed by it.
Neither pillar is sufficient on its own. Excellent tooling applied to a broken process produces broken results faster. Equally, the right culture without supporting automation places unsustainable demands on individual engineers.
What the DevOps Automation Toolchain Needs to Deliver
Despite rapid growth in the DevOps tooling ecosystem, the market was still maturing at the time this analysis was written, and in many respects it continues to do so. Major platform vendors — including Microsoft, AWS, and IBM — had articulated a clear shared vision even where their implementations remained incomplete.
That vision describes a closed-loop delivery cycle:
- Requirements management — capturing and prioritising what needs to be built, informed by real operational data.
- Development and testing automation — continuous integration pipelines that validate code quality, security, and correctness at every commit.
- Rapid, reliable deployment — infrastructure-as-code, containerisation, and orchestration tools that make releasing to production a routine, low-risk event.
- Observability and feedback — monitoring, logging, and tracing that surface performance data and feed it back into the requirements process.
When these four stages are connected and automated, the result is a self-improving system: live performance data informs the next cycle of development, which is tested and deployed safely, generating more data. Intelligence flows around the loop rather than being trapped in siloed teams.
Should Your Organisation Adopt DevOps?
The question of whether DevOps is right for a given enterprise often reduces to a simpler question: does your business need to respond to change quickly? If the answer is yes — and in a technology-driven competitive landscape, it almost certainly is — then the follow-up question is not whether to adopt DevOps practices, but how to do so without introducing new risk.
The answer to the how question involves:
- Defining quality gates that are non-negotiable regardless of delivery speed.
- Investing in automation that enforces those gates consistently.
- Building observability in from the start, so that problems surface quickly and can be resolved before they compound.
- Treating DevOps adoption as an iterative process in itself — start with the highest-friction points and improve incrementally.
DevOps Will Keep Evolving
DevOps is a means to an end, not a fixed destination. Just as the Spiral Model gave way to Agile, and Agile created the conditions for DevOps, the practices that constitute DevOps today will continue to evolve. Emerging capabilities in analytics, machine learning, and AI-assisted operations (sometimes called AIOps) have the potential to further accelerate delivery pipelines and increase the sophistication of operational feedback loops.
What will not change are the underlying principles: iterate quickly, validate continuously, automate relentlessly, and use operational intelligence to drive the next cycle of improvement. Boehm’s spiral is not just alive and well — it has become a structural requirement for any organisation that expects to remain competitive in the digital age.
Original analysis sourced from gigaom.com (2017). This article has been expanded and updated for a DevOps engineering audience.