Lean management and automation

As shown in the E-3 February 2019 issue on page 66, the DevOps idea has numerous precursors and role models, which primarily influenced the C (Culture), M (Measurement) and S (Sharing) in the Calms concept. But the aspects of lean management (L) and, above all, automation (A) are at least as important.

While new approaches to developing software faster and more flexibly began to emerge as early as the 1990s, it took until 2009 before all the Calms elements were brought together in a single concept.

The aim of the approach is to make collaboration between development and IT operations just as agile and flexible as development itself: Since the first DevOps Days in Ghent, experience from development and other areas of the company has been pooled in the DevOps concept, as set out in the DevOps Handbook, for example.

Culture change at all levels

Implementing DevOps demands a lot from those involved. Everyone has to change their attitudes, expectations and ways of working. Thus, in DevOps times, the era of prestigious large-scale projects is over.

Instead, the business management of a development project comes to the fore. The basic question is turned around: Instead of asking what the project will cost, it is necessary to define which new or improved software functionalities can be realized for a specific, manageable budget.

If the answer is available, management must be satisfied with it and trust the project participants that these are realistic goals. At the same time, detailed control from above must be dispensed with.

"What counts from a management perspective is only the result compared to the plan, not the controlling of the individual steps. This is what is meant by lean in the DevOps concept. Both top managers and heads of specialist departments, who are particularly reliant on their colleagues in IT, must submit to this change of perspective."

James Roberts, CTO at Basis Technologies, recommends.

This also means a major change for release managers. They no longer derive their reputation from presenting and managing large construction sites, but from successfully completing many small projects, each only for selected user groups in the specialist departments.

Because the individual projects are manageable, their understanding of their role must change from leader to coach, motivator and trainer. They must also ensure that the composition of the team remains stable over time.

Team spirit arises not only from alignment with a common goal, but also from reliable and trusting relationships among team members. Since large strategic projects in the DevOps world are divided into many small, iterative detailed projects, this is structurally possible.

The team members, in turn, must be willing to step back a bit from their specialization and share their knowledge with all team members. Only in this way can understanding for each other's challenges grow.

It is only through team exchanges that developers learn what problems their artifacts pose to server, storage and other administrators, both in deploying the appropriate test environment and in committing changes to the production environment.

This institutionalized "sharing" (S) beyond silo thinking and boundaries is the aspect that creates trust through understanding and lays the foundation for standardization: Standardization of the approach, but also of the tools with which work is done.

By understanding exactly how a test environment works and why their colleagues from operations have chosen this one and no other, developers can avoid many repairs and risks in later production operation from the outset.

This corresponds exactly to one of the central ideas of the agile development method Scrum, according to which interdisciplinary teams are better and faster able to produce new and high-quality products.

This twofold standardization is the prerequisite for the essential DevOps component of automation (A). Only a standardized environment for monitoring, testing and quality assurance can be provided as a self-service with which developers can work independently.

If they want to test a code change to see whether it actually provides the desired new function and what impact it has on the overall system, they no longer have to wait for the operations team, but can get straight to work.

IT operations, in turn, can concentrate fully on quality assurance of the changes assembled into a release and their implementation in production.

In order to continuously improve the interaction between development and operation, the measurement (M) of parameters must also be automated.

These include evaluations of speed and punctuality or information on quality such as the number of errors found and their development over time.

Accelerated to SAFe SAP

It is the cultural change that brings about the structural change, not the other way around. On the contrary, it is usually the initiatives of the developers concerned and their colleagues in the company that are responsible for the DevOps revolution in the manner of grassroots movements.

This is shown time and again by studies such as the 2018 State of DevOps Report. These pioneers are all the more successful the more manageable the task they undertake and the more urgent it is from the perspective of the company or a key specialist department.

At this stage, existing SAP customers can fall back on the Accelerated SAP concept, which already describes agile working à la Scrum. Once they have demonstrated the new culture and its superiority, they can and must involve management at various levels and make them sponsors of the DevOps revolution.

This support from above is crucial to success. Because DevOps teams cannot live in two worlds at the same time, cannot work according to the waterfall model on the one hand and agile methods on the other; the friction losses would be too great.

In particular, this means that management releases the members of the DevOps teams to be formed from their previous tasks. They must be able to concentrate entirely on the new processes and possibly new tools.

In this way, more and more IT areas can be converted to DevOps piece by piece. Managers can find a description of their new role in the Scaled Agile for Enterprises or SAFe framework from Scaled Agile, which guides not only the individual teams but also all management levels above them in the direction of DevOps.

Trust and confidence are key, especially in the SAP environment, where mistrust of DevOps is perhaps greatest due to the complexity and internal and external dependencies of the various components of SAP environments.

More than almost any other group in corporate IT, SAP developers and administrators depend not only on personal relationships, but also on tools that can help build this trust.

They need tools that can reliably map all dependencies and put new releases through their paces, including their impact on production environments.

These tools include, in particular, tools for automated regression testing. Suitable tools cover practically the entire productive environment and therefore deliver results that are so close to reality that positively tested code can be implemented with a greatly reduced risk.

This is the prerequisite for delivering releases to productive SAP environments at short intervals. In DevOps jargon, this delivery chain is called the Continuous Delivery Pipeline or - in the SAFe framework - the Agile Release Train with the individual steps of exploration, integration and deployment.

However, should problems occur, such as noticeable performance losses or functional errors, such automation tools must also offer the option of rolling back the release without interruption - just as users are used to from the cloud.

Automation

If there is a lack of confidence in the automation of the Ops side, operations is and will remain the bottleneck that prevents the introduction of DevOps in a company's SAP landscape.

Is it any wonder that many existing SAP customers are already using DevOps in their IT today, just not in their own SAP landscape, but in third-party solutions?

Automation tools definitely play a greater role in SAP environments than in other areas. What's more, even though culture is at the beginning of DevOps, automation in SAP environments is just as important as culture.