At this event, I spoke alongside Carsten Brandt from SAP about DevOps in theory and practice. While I presented the theoretical foundations of DevOps and showed how companies can move from projects to products, Carsten brought the practical perspective from over 21 years at SAP. His honest message: the theory has been well established for years, but execution is anything but easy, especially in complex enterprise landscapes.
From Projects to Products#
A core problem I see at many companies is the so-called “Walls of Confusion.” Business teams write requirements in Word documents or Jira tickets and throw them over the wall to the development team. The development team implements what they understand and passes it to testing. Testing finds that the specification and code do not match, tests something anyway, and operations wonder how they are supposed to run any of it.
The root of this problem often lies in project thinking. Projects have a defined start, a defined end, a budget, and a requirements document. The focus is on output: maximizing the number of features, user stories, and code. But our customers actually want products. They want us to solve their problems. The focus must shift to outcomes, not output.
“DevOps is a mindset, a culture, and a set of technical practices that allows us to organize around the value stream and continuously deliver value.”
DevOps helps with this shift by bringing all people, processes, and technologies together. The term “DevOps” is not ideal because it only names Development and Operations. We would actually need a term like “DevSecBizArchCompQAOps,” but at its core, it is about bringing everyone together to continuously deliver value.
The Science Behind DevOps#
The scientific data is clear. Companies practicing DevOps have 208 times more frequent deployments to production, are 106 times faster at delivering features, are 2,604 times faster at restoring services after failures, and have a 7 times lower change failure rate per deployment. Between 2019 and 2021, this acceleration intensified even further.
I also showed the Tesla example: On October 7, 2021, Elon Musk rolled out Autopilot version 10.2 to a thousand car owners with a perfect safety score. This demonstrates canary releases, monitoring, and modular software in driving cars. On October 24, he performed a software rollback on cars driving on the road. Many companies cannot even do this with their regular software, but Tesla does it with vehicles on the street.
Understanding Continuous Delivery#
An important part of my presentation was explaining the Continuous Delivery pipeline. Continuous Integration means: a developer commits code to the source code repository, the code gets reintegrated, built, analyzed, and tested. Feedback arrives within minutes, not hours. With Continuous Delivery, the artifact is automatically installed in a staging environment. With Continuous Deployment, it goes fully automatically into production, with automated tests and rollback on failure.
Equally important is quality. In traditional V-model testing, three to six months can pass before a feature gets tested. In agile testing with Behaviour Driven Development, we write acceptance criteria in “Given-When-Then” format and derive tests from them. This way, we always have the test before we write the code. This is the “Shift Left” we want to achieve.
The Practice Perspective: Why Execution Is So Difficult#
Carsten Brandt brought the sobering practical view. His honest message: “The theory has been there for years. It’s all logical. There are examples that show the way. So we just need to execute. But exactly this ‘just execute’ is the hard part.”
He cited a Gartner study showing that 75% of all DevOps initiatives do not deliver the expected results. A main reason: poor or nonexistent expectation management. Teams say “we want to deliver faster,” but speed alone has no value. Carsten illustrated this with the Monty Python sketch of the 100-meter dash for people with no sense of direction: everyone runs in different directions. Speed is useless without the right goal.
“The real goal is happier end customers. And in software development, you achieve that with better software. Faster delivery is merely a means to that end.”
Systems Thinking and the Uniqueness of Every Organization#
Carsten’s most important message: you cannot simply copy what Netflix, Google, or Spotify do. Every organization is a unique system. The parts of a system influence each other, and the system has properties that its individual parts do not possess. You cannot transplant a part from System A into System B and expect it to work the same way.
He used the beautiful analogy of the human body: the heart has no life on its own, the lungs have no life on their own, but together they form a system that lives. Organizations work exactly the same way. What you can do is learn from others and adapt, but not copy one-to-one.
Lehman’s Law of Software Evolution also came up: software systems must be continuously adapted, or they become progressively less satisfactory. At the same time, complexity grows exponentially with the system’s lifetime. This dilemma requires a clear focus on the mother of all software engineering questions: What brings value to the customer?
Key Takeaways#
- From projects to products: The shift from output focus to outcome focus is essential for successful software development.
- Understand the value stream: Value Stream Mapping makes the entire value stream visible and uncovers bottlenecks that can then be addressed systematically.
- Quality before speed: Without trust in quality, you cannot deliver faster. Test automation and Shift Left are the starting point.
- Every organization is unique: There is no blueprint that can be copied from one company to the next. Learning and adapting is the way forward.
- Expectation management is critical: Most failed transformations fail because of wrong or missing expectations, not because of technology.
- Customer value as the North Star: The central question must always be whether the software solves a real customer problem.