I was invited to deliver the keynote at the Baloise OpenX Day, an internal conference where Baloise brings together their technology community. The session combined impulse presentations with interactive discussions, giving me the chance to share DevOps fundamentals and then hear directly from the teams about their real challenges. The conversations with the Baloise engineers were incredibly valuable, especially around topics like continuous deployment in regulated industries and the role of platform engineering.
The Broken Value Stream#
I started by showing a picture that I encounter at many companies: the broken value stream. Business throws requirements over a wall to development, development throws code to testing, testing passes something to operations, and the customer receives something they did not ask for. These “walls of confusion” stem from silo organizations and a fundamental lack of alignment.
The deeper issue is the project mindset. Projects focus on maximizing output, meaning the number of features delivered within a fixed budget and timeline. Products, on the other hand, focus on outcomes: understanding the customer, solving their problems, and changing their behavior. DevOps enables this product mindset by aligning all people, processes, and technology across the value stream.
“DevOps is a mindset, a culture, and a set of technical practices which provides communication, integration, automation, and close collaboration among all the people in the value stream.”
Understanding and Measuring the Value Stream#
One of the most powerful DevOps techniques I shared is Value Stream Mapping. You bring all the people who work on the value stream into one room: business, architects, developers, testers, security, quality assurance, operations. Together you map every step from idea to production, identify who is responsible, and then measure three things: lead time (total time including waiting), process time (actual value-adding work), and percentage complete and accurate (how often the next step can use the output as is).
The results are often eye-opening. In my example, the testing step had a lead time of 336 hours but only 8 hours of actual process time. That means most of the time is spent waiting. The rolling percentage complete and accurate was just 5%, meaning only 5% of work flows through the entire process without rework. When teams see these numbers, they immediately understand where the bottlenecks are and can begin to address them.
Continuous Delivery: Getting the Terms Right#
A topic I always spend time on is clarifying the CI/CD terminology, because I see many teams using these terms incorrectly. Continuous Integration means every code commit triggers an automated build with code analysis, security analysis, unit tests, and integration tests, and feedback comes within minutes. The output is a deployable artifact.
Continuous Delivery takes that artifact and automatically installs it in a staging environment for further testing. Continuous Deployment goes one step further: the artifact automatically moves through staging into production, with automated tests at each stage and automatic rollback if something fails.
The important insight: you do not necessarily need continuous deployment. Continuous delivery is absolutely fine for many teams. But you need to be clear about which level you are at and what your business actually requires. The key is to always ask: how fast does the business need to deliver?
DevOps in Regulated Industries#
The most engaging part of the session was the discussion about DevOps in regulated financial services. A recurring concern was: “We need manual sign-off before production deployment. Is continuous deployment even possible for us?” My answer was clear: yes, it is.
The common argument in financial institutions is that segregation of duty requires a different person to approve deployments. But when you actually read the regulation, it says that a developer should not be able to directly deploy into production. It does not say a human must manually check every deployment. An automated pipeline with proper security checks, static code analysis, automated testing, and audit trails fulfills the regulatory intent far better than a human reviewing Jira tickets.
“Science says: if you have a manual release management gate, your software delivery performance will be hurt. The best thing, sorry to say, is to get rid of it.”
I recommended a revealing experiment: intentionally introduce a small piece of bad code through the organization’s release process. In most cases, the manual review gates will not catch it, which demonstrates that automation provides far superior protection.
Platform Engineering for Scale#
The later discussions touched on platform engineering as the key to scaling DevOps. When each product team builds and maintains their own CI/CD tooling, the cognitive load becomes overwhelming. New team members need months to become productive. Ordering a new Kubernetes cluster or database takes weeks.
Platform engineering solves this by creating a dedicated team that provides a shared platform. API gateways, CI/CD pipelines, Kubernetes clusters, repositories, security scanning, synthetic test data: everything teams need is available as a self-service product. The platform team is not another silo. They deliver a product that enables product teams to focus on feature development and customer value.
This concept turns an organization into a “digital factory,” not in the sense of repetitive assembly line work, but as a modern, automated foundation where all the boring infrastructure tasks are handled, and developers can concentrate on what truly matters.
The Three Ways of DevOps#
Throughout the session, I kept returning to the three ways of DevOps. First, optimize the flow of work through the value stream from left to right. Second, create fast feedback loops from right to left so that issues are caught and corrected quickly. Third, foster a culture of continuous learning and experimentation. These three principles apply regardless of company size, industry, or regulatory environment.
The Baloise teams were already making progress: they had moved from monthly releases to several releases per week. Some teams had platform teams running their continuous delivery tooling. The DevOps spirit was growing, even if not yet at every level of the company. As I told them, it is a continuous improvement journey, and every step forward counts.
Key Takeaways#
- Value Stream Mapping is one of the most powerful tools to visualize waste and bottlenecks in your software delivery process.
- Continuous Delivery vs. Continuous Deployment: know which level fits your needs, and do not confuse the terms.
- Regulated industries can adopt DevOps: automation meets regulatory requirements better than manual gates, if you read the actual regulations carefully.
- Platform engineering enables scale by reducing cognitive load on product teams and providing self-service infrastructure.
- The digital factory concept is about automating all the infrastructure work so teams can focus on customer value.
- Always ask: how fast does the business need to deliver? Speed is only valuable when it is directed toward solving real customer problems.