How DevOps succeeds

DevOps approaches date back to the late 1990s, so in principle they are nothing new. Nevertheless, many projects still do not lead to the desired result. Based on its own experience from numerous DevOps customer projects, Consol shows which five points should always be considered.

1. actively tackle cultural change

It is clear that there is initially a conflict of interest between development and operation. While creativity and flexibility are important for the developer, the main criteria for IT operations are stability and availability.

If, as part of a DevOps strategy, developers and those responsible for IT operations now work together in teams on the design, development, testing and operation of applications, this requires not only organizational changes but also a cultural change.

This also means, for example, that the team members have to deal with the respective requirements and processes of both development and operations.

The topic of change in the corporate culture must be actively addressed with the involvement of management at the start of the DevOps project in order to reliably rule out future friction losses in the interdisciplinary teams.

2. consider investment volume

It is clear that successfully implemented DevOps projects bring numerous benefits in the medium and long term: from higher quality and flexibility to faster software release cycles and cost savings.

However, this can only be achieved if the necessary initial investment is made. This is often not the case. Every company must be aware that the introduction of DevOps is initially always associated with an increase in IT costs.

The company's management must therefore be involved in DevOps projects from the outset and provide long-term support for all necessary investment decisions.

3. use the simulation environment

The processes in development and production differ considerably. For example, applications in production are always integrated into a larger system environment.

Developers, on the other hand, often work completely independently on software on their desktop PC or notebook, without it having the necessary connection to an SAP system, for example.

Providing the developer with an SAP single-user license in such a case is usually not a viable option for cost reasons alone, so it is usually not done and errors in the software are virtually programmed.

The alternative is to use a simulation environment. However, many companies still do not do this, even though it is not necessarily associated with high costs.

There are also inexpensive open source products such as Citrus from Consol (www.citrusframework.org), a platform-independent framework that can be used flexibly for a wide variety of technologies and protocols.

4. eliminate manual process steps

In order to take full advantage of DevOps, all processes must of course be automated as far as possible. However, manual activities are still often the order of the day, especially in the area of testing.

It is not uncommon for specialist departments to check the functional integrity of an application manually, which is labor-intensive. However, this contradicts the DevOps approach, which is intended to contribute to the faster provision of software.

Some companies remain loyal to the manual approach because a number of testing tools are associated with not inconsiderable costs. However, this is clearly not enough, as there are also open source solutions in this area that offer comprehensive testing functionality: from functional, load and performance tests to end-to-end tests.

5. reduce system breaks

Even in DevOps structures, development, integration and production environments are often viewed in isolation. Separate tools are used in each area, but these are not linked together as isolated solutions.

This also does not correspond to the actual integrative DevOps concept. The aim must be to ensure centralized networking. Here too, many companies - often out of ignorance - do not see any possibilities.

However, this is also a fallacy; you only have to think of tools in the OpenShift or Ansible environment.