In September 2024, I had the privilege of delivering a keynote at the Roche DevOps Conference in Poland. The topic: how to architect for continuous delivery. This is a subject close to my heart, because after more than two decades of working in software delivery, I keep seeing the same fundamental patterns that separate high-performing organizations from those that struggle.
The Broken Value Stream#
When I visit companies, I often encounter the same picture. The business has big ideas and writes them into Jira tickets and Word documents. Then they throw them over a wall of confusion to the development team. The developers implement something and throw it over to testing. The testers look at what was specified, compare it to what was built (which is never quite the same), test something, and throw it over to operations. Operations asks “How can we operate that?” and somehow, with many late nights, they get it running. Then the business or the customer sees the result and says: “What is that? We cannot use it.”
This pattern is driven by silo organizations with different goals, no alignment, and legacy systems. The value stream is completely broken by these walls of confusion. DevOps is the answer: a mindset, a culture, and a set of technical practices that allows teams to organize across the entire value stream, moving from project thinking to product thinking.
Build the Right Thing Right#
One principle I always emphasize: DevOps is not just about building things faster. It is about building the right thing right. Building the right thing is about effectiveness. Building the thing right is about efficiency. You need both.
The science backs this up. The book Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim identifies 24 key capabilities that drive software delivery performance, organized into five categories: continuous delivery, architecture, product and process, culture, and lean management. What makes this research powerful is the map showing how these capabilities influence each other. When you want to achieve the outcomes on the right side of that map, you need to invest in the capabilities on the left side. For decision makers, this is an invaluable guide.
Measuring Software Delivery Performance with DORA#
The DORA metrics are the only scientifically proven KPIs for measuring software delivery performance:
- Lead Time for Changes: How long from code commit to production. Elite performers do this in less than an hour.
- Deployment Frequency: How often you deploy to production. Elite teams deploy on demand, multiple times per day.
- Time to Restore Service: How quickly you recover from a failure. Elite teams recover within an hour.
- Change Failure Rate: What percentage of deployments cause a failure. Elite teams stay between 0 and 15%.
The important thing: you do not need to be elite. Think about your context, define what matters for your products, and measure accordingly.
Value Stream Mapping: See the Whole System#
Before optimizing anything, you need to understand your whole value stream. Value stream mapping is a simple but powerful technique. Bring all the people working on a product into a room, give them Post-its, and ask them to lay out every step from idea to production. Then identify who is responsible for each step, and measure three things:
- Process Time (PT): The actual value-adding work time
- Lead Time (LT): The total elapsed time including all waiting
- Percentage Complete and Accurate (%C&A): The quality output of each step
When you do this, bottlenecks become visible immediately. For example, a testing step might have 8 hours of actual work but 336 hours of lead time, meaning massive waiting. With the whole system visible, teams can improve the entire stream rather than optimizing one part at the expense of another.
Shift Left: Quality and Security#
Building quality in means shifting left. Instead of the traditional V-model with delayed feedback cycles of three to six months, you want Behavior Driven Development (BDD) with testable acceptance criteria from the start, and Test Driven Development (TDD) where tests are written before code. This flips the testing pyramid: many fast, cheap unit tests at the base, fewer integration tests in the middle, and only a small number of slow, expensive end-to-end tests at the top.
“50% of the money a Musk company invests in a new product is in automated testing.” Think about your own product. Is it even close to 10%?
The same shift-left principle applies to security. Your continuous delivery pipeline should include static code analysis, software composition analysis, container scanning, secret detection, and dynamic application security testing. And even when nothing changes in your code, scheduled pipelines must regularly check for newly discovered vulnerabilities.
Architect for Observability#
As systems evolve from two-tier applications to distributed microservice architectures, monitoring evolves into full observability. You need tracing, metrics, and logs, all built into the application from the start. This means architecting for observability, not bolting it on after deployment.
Infrastructure as code, staging environments congruent to production, feature toggles for canary releases, and cross-team collaboration on monitoring are all essential components.
Platform Engineering: The Enabler#
All of this creates significant cognitive load for teams. This is why the industry is moving toward platform engineering. Gartner predicts that by 2027, 75% of organizations will have created an internal platform.
The model is straightforward: a platform team builds and maintains an internal developer platform as a product. The customers of that product are the product teams. The platform provides the tools and capabilities that product teams need to practice DevOps. The platform team enables; the product teams build, run, and maintain their products.
For example, the platform team provides observability capabilities. The product teams use those capabilities to monitor their own applications. The platform team does not monitor the applications for them. This clear separation of concerns generates value at every level.
Key Takeaways#
- Build the right thing right. Do not focus only on speed. Ensure you are building what customers actually need, and building it with quality.
- Map your value stream. Understand the entire flow from idea to production before optimizing any single part.
- Use DORA metrics wisely. They are proven KPIs, but apply them to your context rather than chasing elite status blindly.
- Shift left on quality and security. Invest in test automation, BDD, TDD, and pipeline security from the start.
- Architect for observability. Build telemetry into your applications, do not add it as an afterthought.
- Invest in platform engineering. Enable your teams to do DevOps by providing them with a self-service platform that reduces cognitive load.
We are clearly entering the age of industrialized software development. Platform engineering is the key enabler, and architecting for continuous delivery is how we get there.