DevOps: Where does the continuum begin?

DevOps is not a quirk of some freaks. Rather, DevOps is a concept and a method in one. It is a concept because it calls for a different corporate culture, away from excessive division of labor and toward interdisciplinary teamwork.

method, because the approach follows clearly defined and proven principles and procedures that must be supported by an integrated tool chain including automated test procedures, especially in the SAP environment.

DevOps is about functionality that drives the business. And its development adheres strictly to the budget, without detailed controls by superiors. Which brings us directly to the topic of lean management: Confidence and trust instead of maximum documentation requirements, manageable and goal-oriented projects instead of large construction sites that bring a lot of prestige but are twice as expensive as planned.

But IT teams themselves also need to be "lean" and agile, following the same principles for lean practices as management. But what does that actually mean? The Lean Enterprise Institute provides the answer:

No DevOps without agile principles

The overriding principle is customer orientation, the benefit of a new functionality for the users. Once those responsible have determined its value, they should next examine the processes to see whether they contribute positive value. Those that do not should be removed.

Third, processes should be (re)designed to shorten the average duration of a cycle from development to go-live (sprint).

This makes it possible to deliver functionalities on a continuous basis - and thus to check and measure their quality and value contribution more precisely. Fourth, the business should determine what value IT should contribute, and not the other way around.

You have to think of these four principles like the pearls in a necklace, the fifth of which closes the circle: "Continuous Improvement", thanks to repetitive loops, allows insights that can be used to optimize the overall process with each sprint.

But improvements are only recognizable as such if they can be measured. The DevOps concept even recommends continuous measurement, i.e., collecting key figures at many different points in the development process.

For example, SAP inventory customers should count the transports and changes delivered to an SAP system in specific time periods.

How long does it take for requirements to be cast into new software code? How many corrections are there per sprint? Is this number increasing or decreasing? Are the required new functions delivered on time?

These are all relevant metrics that can be continuously improved if DevOps teams regularly reflect on, discuss, and optimize their work.

Existing SAP customers who want to implement DevOps should be guided by the lean principles mentioned. Which of these is easiest to implement or is already a reality?

The starting point could be the Requirement-to-Deploy value stream. Create key figures and measure where the greatest potential for improvement lies dormant in this value stream.

Is it the scope and size of projects and teams? Reduce them and increase their number at the same time! Bring developers, administrators and quality managers to the same table and you are already in the DevOps world. Small but powerful teams that work autonomously and across departments add up to a higher value proposition.

The concrete reason for the DevOps introduction in the coming years will be the changeover to S/4. New methods are needed for a project of this magnitude and relevance.

SAP is also taking this into account with its SAP Activate implementation method (see also page 62), which follows agile principles. In our next column, we discuss approaches to migrating to S/4 Hana and the role that automation plays in this.