Skip to main content
How to Architect for Continuous Delivery: From Silos to Digital Factories
  1. Blogs/

How to Architect for Continuous Delivery: From Silos to Digital Factories

Author
Romano Roth
I believe the next competitive edge isn’t AI itself, it’s the organisation around it. As Chief AI Officer at Zühlke, I work with C-level leaders to build enterprises that sense, decide, and adapt continuously. 20+ years turning this conviction into practice.
Ask AI about this article

At The DEVOPS Conference, I presented on a topic that has been at the heart of my work for over two decades: how to architect for continuous delivery. This talk covers the broken value stream I see in most companies, why product thinking matters more than project thinking, the science behind software delivery performance, and how platform engineering enables organizations to scale DevOps through digital factories.

The Broken Value Stream
#

When I join companies, I consistently see the same pattern. The business and the clients have bright ideas. They put these ideas into Word documents and Jira tickets. Then they throw them over the wall of confusion to the development team. The development team says “sure, we can implement that” and throws the result over to the QA team. QA says “doesn’t match the requirements, but it is green” and throws it to operations. Operations says “how should we operate that?” and somehow manages to get it running. Then the business looks at the result and says: “What is that? That does not solve our problem.”

This picture is driven by silo organizations with different goals, a complete lack of alignment, and a lack of software engineering excellence. The experience for everyone involved is bad.

From Waterfall to Agile to Products
#

To understand the root of this problem, we need to look at history. First we had waterfall, where we planned, designed, developed, tested, and deployed big chunks of software. Time, scope, and budget were all fixed. Many projects failed.

Then smart people said “let’s go agile” and deliver in smaller increments. Time and budget are fixed, scope is variable. This was a very good improvement. But we were still working in projects.

The shift that matters is from projects to products. A project has a start and end, a set of resources, and a deliverable. It focuses on output: maximizing the number of features. A product focuses on outcome: solving the customer’s problem. The customer does not care about ten features. They care about that one feature that solves their problem.

“DevOps is a mindset, a culture, and a set of technical practices which provides communication, integration, automation, and close collaboration among all the people needed to plan, develop, test, deploy, release, and maintain a product.”

The Science: Accelerate and the DORA Metrics
#

The book Accelerate scientifically examined why some companies excel at creating products while others fail. They identified 24 key capabilities organized into technical practices, culture, and mindset that drive software delivery performance.

The DORA metrics are the scientifically proven way to measure this performance:

  • Lead Time for Changes: From code commit to production. Elite is less than an hour.
  • Deployment Frequency: How often you deploy. Elite deploys on demand, multiple times per day. The key principle: deployment (code in production with feature toggle off) is not the same as release (toggle on).
  • Time to Restore Service: How fast you recover from a failure. Elite is less than an hour.
  • Change Failure Rate: Percentage of deployments causing failure. Elite is 0 to 15%.

The State of DevOps reports show the difference between low performers and elite performers: 208x more frequent deployments, 106x faster lead time, 2604x faster time to restore, and 7x lower change failure rate. The benefits are clear: faster time to market, more value for money, higher quality, and higher customer satisfaction.

The Challenge of Scaling DevOps
#

When companies try to scale DevOps, a common mistake is creating a “DevOps team,” which is just another silo. The correct approach is to bring development and operations together into cross-functional product teams.

But then each team reinvents the wheel. There is inconsistency, redundancy, lack of operational experience, and huge complexity in tooling. When you look at a continuous delivery pipeline, there is an enormous amount of tooling, and all those tools need to work together and be maintained.

Even platforms like GitLab, GitHub, and Azure DevOps do not cover everything. You still need to replace or add components. The cognitive load on teams is high. Onboarding takes months. Provisioning a new database or Kubernetes cluster takes months. There is a real lack of standardization, and the result is slow time to market and low quality.

Platform Engineering: The Enabler
#

The solution is platform engineering. The target picture is a digital factory with a conveyor belt of high automation, where teams can focus on the real work.

The organizational architecture looks like this: product teams focus on building, running, and maintaining their products. The platform team provides the platform. The platform team is not another silo. They are a product team whose customers are the other product teams.

The platform team builds the CI/CD pipeline, the API decoupling layer, the Kubernetes infrastructure, the synthetic test data, and everything else the product teams need. The product teams use this platform to practice DevOps.

“The platform team generates value for the teams. The product teams generate value for the customer. Platform engineering enables product teams to do DevOps.”

This is how you architect for continuous value delivery. This is how you reduce cognitive load. And this is how you scale DevOps.

Thread Modeling and Security
#

During the Q&A, someone asked about integrating thread modeling into CI/CD. My answer: you need to architect for security, just as you architect for testability and operability.

Thread modeling works like this: gather your team and a security expert in a room. Draw the context diagram of your application. Identify the attack vectors and threats. Define mitigations, put them on the backlog, implement them, and test them in your pipeline. Include container scanning, software composition analysis, dependency scanning, and SAST. In production, continuously monitor for attacks.

Key Takeaways
#

  • Break down the walls of confusion. Organize across the value stream, not in silos.
  • Think in products, not projects. Focus on outcome for the customer, not output for the organization.
  • Use the DORA metrics. They are the scientifically proven way to measure software delivery performance.
  • Build digital factories. Create conveyor belts of automation that enable continuous value delivery.
  • Invest in platform engineering. The platform team enables product teams to do DevOps by reducing cognitive load and providing standardized, self-service capabilities.
  • Architect for security. Use thread modeling and shift-left security practices to protect your applications from the start.