If the culture works, so does the technology

The DevOps movement - a combination of culture, practice and tools that help companies deliver applications and services at very high velocity - is heavily influenced by the CALMS concept, which stands for Culture, Automation, Lean, Measurement and Sharing.

Culture and exchange - one could and should perhaps rather say communication in the case of the latter - are at the beginning and the end; they form the framework of the entire concept, so to speak. But why do both sides - dev and ops - need to learn to talk to each other more? The question may seem naïve at best, superfluous or even silly at worst.

And yet it has been coming up again and again since the collapse of the Internet hype in 2000 and 2001. As a result, there was a lot of talk about the industrialization of IT, including at SAP. Since then, technology was no longer considered an end in itself, but had to serve the business and subordinate itself to its requirements.

Standards such as ITIL (IT Infrastructure Library; collection of best practices for service management) came into focus for many existing SAP customers, with the help of which IT was to be consistently aligned with the business.

And yet the discussion is flaring up again with full force since corporate IT has been challenged by the major cloud providers. It is primarily the users who are making their IT colleagues feel their dissatisfaction with their work.

After all, they expect the same level of availability, speed, simplicity and convenience that they have become accustomed to as consumers. Is it a coincidence that the Agile Manifesto, a kind of charter for agile software development, puts customer orientation at the top of the list?

It is thus becoming increasingly clear that ITIL has not fulfilled all or even very few of the expectations attached to it. But what is the reason? ITIL was indeed able to bring IT and business closer together. But the IT-inherent

The set of rules cannot resolve the contradiction between development and operation. After all, it is the fundamental task of developers to respond to changes in business requirements as quickly and as well as possible with their work and to implement them.

On the other hand, the fundamental task of IT operations is to ensure the stability and reliability of IT services that are compromised by changes to the program code. However, ITIL was never designed to resolve this fundamental conflict of objectives, while the major cloud providers seem to be succeeding in doing just that.

Trust instead of fear

Most companies are organized according to the principle of division of labor. Everyone is an expert in his or her field and knows the tasks in his or her area of responsibility inside out. But because only the experts in one and the same field speak the same language, invisible walls arise around them that go hand in hand with the language barrier.

Tiny doors between them allow the work results to be handed over. What happens inside the walls remains invisible to the others. Whoever has handed over their results is free of responsibility and does not have to worry about the overall result - the perfect waterfall model.

"In projects organized around this model, individual team members often focus almost exclusively on the success of their particular task, not on the success of the whole.

The more extensive and strategic the project, the more likely it is that the errors or delays that almost inevitably result will be accepted in order to meet the overriding goals and commitments to the specialist departments after all."

James Roberts, CTO at Basis Technologies, knows from experience.

"Unfortunately, we see this approach with SAP legacy customers again and again, and still quite often."

Where silo boundaries are part of everyday life, SAP developers and their colleagues in IT operations do not communicate with each other, or at least not enough. The former are responsible for changes, customizing, etc., and hand over the results of their work without understanding or checking whether they contain problems for their colleagues in server, storage or network administration, in quality assurance or in the management of the test environment.

If the software does not run as expected, the developers are not held responsible, while IT operations has its hands full finding workarounds to minimize the number and duration of disruptions.

The developers, in turn, are repeatedly interrupted in their work when they cannot test their artifacts immediately, but have to open tickets and wait until the appropriate test environment is ready for them technically and in terms of time. Both sides are only insufficiently satisfied with the work of their colleagues. Thus, silence slowly threatens to turn into mistrust.

In such a culture and the corresponding structures, user expectations cannot be met in the cloud age. Companies must find a way to move from a culture of mistrust to a culture of trust.

Suitable machine regression tests, by means of which quality assurance can be shifted back in the direction of development along the lines of shift-left testing, could go a long way towards remedying this situation.

Correcting errors and incorporating short-term changes to requirements even before a new release goes live is usually 20 to 40 times cheaper, especially in the SAP environment.

Model manufacturing

It may come as a surprise, but the idea of better collaboration because it is responsible and based on trust is much older than the IT industry. It was first applied in the manufacturing industry, some eighty years ago. After all, the problems of division of labor and specialization are obviously as old as these themselves - and not a product of new technologies and ways of working.

In response to these problems, physicist and statistician Walter Shewhart developed the PDSA (Plan-Do-Study-Act) control loop, which was expanded into a theory by Shewhart's student William Edwards Deming.

However, the management program developed by the engineer and doctor of mathematical physics initially found eager users not in the U.S., but in post-war Japan.

The Toyota production system, which turned the company into the world's largest automaker in just a few decades, exemplifies the influence of Deming's ideas, which were only noticed and partially implemented by a wider audience and especially managers in the United States in the 1980s.

Concepts such as Total Quality Management, in which quality is measured at all times and at every point in the process chain, in contrast to random sampling, or just-in-time production, which is now widely known and practiced, represent this change in perception.

The highlight and revolutionary aspect of this approach was that everyone was not only responsible for their own area, but the quality at every step was also made transparent to everyone and especially to management.

The principle behind it: Errors happen. But if they are not detected or are only identified at the end of the manufacturing process, it may be too late to take corrective action, or it may be very labor-intensive and costly, both in terms of time and money. In addition, the measuring points that enable evaluations to continuously improve the process are missing.

Continuous Everything

The methods of continuous quality assurance and improvement have long been standard in the manufacturing industry. Its basis is formed by responsibility, transparency, short cycles and team orientation, which are transferred to the world of IT in a very similar way thanks to DevOps.

Continuous Integration, Continuous Testing, Continuous Delivery and Continuous Improvement are all elements of a successful DevOps approach. This pursues the goal of making any change available as soon as it is available, without risk and ideally without human intervention.

Ways of working and roles need to be adapted accordingly in order to actually achieve the results that are possible with DevOps - as has already happened in manufacturing.

Silo boundaries must be torn down, clearly delineated areas of responsibility replaced by working in multidisciplinary teams. With only one goal in mind: improved collaboration. It is the key to achieving the defined business goals using DevOps.

Culture, as already mentioned, is indeed an essential part of the DevOps concept and concerns in particular components C, M and S in the CALMS approach. Don't miss the second part of the article in the upcoming issue, which deals with the impact of automation (A) and lean management (L) on work structures and processes. You will also learn more about the role that various tools play in making DevOps a simple standard even in complex SAP landscapes.