At the Conf42 DevSecOps 2024 conference, I presented my approach to architecting for continuous delivery. After more than 21 years at Zühlke, working across industries on DevOps transformations, I keep seeing the same fundamental problem: value streams broken by walls of confusion. In this talk, I walk through how organizations can move from project thinking to product thinking, build in quality and security from the start, architect for operability, and use platform engineering to scale it all.
The Broken Value Stream#
When I visit companies as a consultant, I almost always see the same pattern. The business has bright ideas, writes them into Word documents and Jira tickets, and throws them over the wall of confusion to the development team. The developers implement something and throw it over to testing. The testers look at the requirements (which never quite match what was built), test something, and throw it over to operations. Operations says “this will never work in production,” but somehow they manage. Finally, the customer sees the result and says: “What is that? This does not solve our problem.”
The blue line running through this picture is the value stream, and it is broken by these walls of confusion. The root cause is silo organizations with different goals, no alignment, legacy systems, inflexible processes, and cultural resistance.
These challenges originate from how we have historically done software development. In the past, we delivered in large waterfall batches with fixed scope, budget, and time. Then around 2000, we moved to agile with smaller increments. But we are still doing projects when our clients actually want products.
From Projects to Products#
A project focuses on output: deliver these 10 features in six months for 200,000 euros. A product focuses on outcome: solve the customer’s problem and change their behavior. DevOps supports this shift because it is a mindset, a culture, and a set of technical practices that allows teams to organize across the value stream and continuously deliver value.
The term “DevOps” itself is not perfect. It implies just development and operations. Some people suggest DevSecOps, BizDevOps, or other variations. I always say we would need something like “DevSecBizArcCompQAOps” and I am sure I would still forget someone. The point is: DevOps means bringing all people, processes, and technology together to continuously deliver value.
“DevOps is a mindset, a culture, and a set of technical practices that brings all people, process, and technology together to continuously deliver value.”
Why DevOps Matters: The Science#
The book Accelerate (The Science of DevOps) identifies 24 key capabilities that drive improvements in software delivery performance. These capabilities span five categories: continuous delivery, architecture, product and process, lean management and monitoring, and culture.
The research also maps the relationships between these capabilities. I consider this one of the most important pictures for anyone doing a DevOps transformation: it shows what you need to invest in (left side) to achieve the outcomes you want (right side).
The State of DevOps reports compare low performers with high performers. The numbers are massive in deployment frequency, lead time, time to recovery, and change failure rate. The benefits translate to what every CIO wants: faster time to market, more value for money, higher quality, higher customer satisfaction, and top qualified employees.
Building in Quality: Shift Left Testing#
Quality is essential for continuous delivery. When you look at companies like SpaceX and Tesla, Elon Musk invests roughly 50% of new product budgets into automated testing. That is how they can deliver fast innovation to the market. Most companies invest far less.
Traditional testing follows a V-model with delayed feedback. A requirements engineer writes a feature, another writes a story, a developer writes code, and if we are lucky, some tests. Then months later, a tester tests the story and another tester tests the feature. The feedback loop can be three months, six months, or even a year.
The alternative is to shift left with Behavior Driven Development (BDD) and Test Driven Development (TDD). Define acceptance criteria in Given/When/Then format upfront, write the test first, then implement the code. This inverts the traditional test pyramid: instead of many slow, expensive end-to-end tests, you get a massive amount of fast, cheap unit tests. The focus shifts from finding bugs to preventing them.
Building in Security: DevSecOps#
A continuous delivery pipeline is more than CI/CD. It starts with continuous exploration (ideation, backlog management, requirements engineering) and ends with release on demand (feature toggles). Within this pipeline, security must be built in at every stage:
- Planning: Threat modeling to analyze attack vectors and mitigate risks
- Coding: Merge requests and pull requests with peer review
- Building: Static application security testing, software composition analysis, license compliance, container scanning, secret detection
- Testing: Dynamic application security testing
- Production: Penetration testing and continuous security monitoring
Architecting for Operability#
When we practice “you build it, you run it,” operability becomes a first-class concern. Proactive detection means our monitoring systems alert us based on tolerance thresholds before customers notice problems. Disaster recovery procedures need to be in place and rehearsed regularly.
Monitoring has evolved significantly. Two-tier systems needed basic metrics and logs. Three-tier applications required application monitoring with traces. Today’s distributed service-oriented architectures demand full observability, often enhanced with AIOps to make sense of the massive amounts of data.
“When architecting a system, a subsystem, or a microservice, you always need to think: how is this going to be operated in production?”
Platform Engineering: The Key to Scaling#
Modern software development requires teams to handle infrastructure, runtimes, CI/CD pipelines, monitoring, security tools, supporting tools, cost management, maintenance, and access management. Oh, and they also want to build an application. When you scale this across multiple teams, you get inconsistencies, redundancies, reinvented wheels, and crushing cognitive load.
Platform engineering solves this. A platform team builds a product (the platform) that provides standardized application runtimes, DevSecOps capabilities, access and identity management, monitoring and observability, and CI/CD pipelines. The product teams build, run, and maintain their products on top of this platform.
This is not another silo. The platform team creates a product that other teams want to use. The teams still own their products, still operate them, still monitor them. The platform just enables them to do DevOps without reinventing the wheel.
Gartner, BCG, and McKinsey all agree: platform engineering will be critical in the next five years.
Key Takeaways#
- Move from projects to products. Put the customer in the center and solve their problems instead of delivering feature lists.
- Build in quality from the start. Use BDD and TDD to shift testing left. Write tests before code to prevent bugs instead of finding them.
- Build in security from the start. Apply DevSecOps across the entire delivery pipeline, from threat modeling in planning to continuous monitoring in production.
- Architect for operability. Think about how every component will be operated in production, and invest in full-stack observability.
- Use platform engineering to scale. Build a standardized platform so product teams can focus on delivering value instead of managing tools.
- We are entering the age of industrialized software development. Platform engineering is the foundation that enables teams to practice DevSecOps and continuously deliver value.