Mr. von Kielpinski, what exactly is DevOps?
von Kielpinski: DevOps is not a technology and perhaps not even a method, but a concept for intensive collaboration and collaborative thinking with the aim of becoming faster and better in the long term.

For a long time, specialization in individual tasks was propagated in the industry, whether for reasons of cost, efficiency or training. In principle, this development began with assembly line work and also reached IT professions. DevOps is the dissolution of these specialized islands in favour of a collaborative approach.

IT currently requires development cycles that can no longer be mapped in the classic waterfall model. Agile development models are now the standard rather than the exception. However, faster development only has added value if it also reaches production quickly and in high quality.

To ensure this, as many obstacles as possible need to be removed between development (Dev) and operations (Ops). This is done with the help of technologies such as containers, suitable development environments and means of rolling out the software, but at least 50% of it involves adapting the company's processes, which also has an impact on the mindset of the employees involved. This is because DevOps primarily means communication and collaboration across departmental boundaries and responsibilities.

Similar to IT, the challenges are therefore the close networking not only of machines, but also of people in different roles who in the past had hardly any points of contact and who were also strictly formalized. The DevOps concept makes it possible to deepen this collaboration and provides ideas and possibly even templates on how to master these challenges in the company.

What specific measures does DevOps involve?
von Kielpinski: The specific measures of DevOps are based on the CALMS rules, with a lot of parallelization taking place here. The acronym CALMS describes the foundations of DevOps well. Namely Culture, Automation, Lean, Measurement and Sharing. As you can see, the soft elements such as culture, information sharing and a lean approach are in the majority here. However, monitoring also refers to the mechanistic monitoring of parameters on the one hand and explicitly calls for feedback on the other.

First and foremost, company management must support DevOps. Due to the need for cross-departmental and cross-divisional collaboration, the use of hierarchical shortcuts must not be a problem, but should rather be encouraged in a controlled manner. It is also important to position the topic broadly within the company. This does not have to mean introducing it everywhere immediately, but as many employees as possible should understand and support the concept.

Hennig von Kielpinski: "Companies need to focus on networking and standardizing their technologies in order to promote automation. In addition, soft and hard measuring points must be determined and jointly evaluated and a culture of open communication established."

© Consol Consulting & Solutions Software

Parallel to these corporate culture and process topics, an inventory of the technologies in the company should be carried out. In the next step, companies can think about how these can be combined or, if necessary, expanded and replaced in order to achieve a high degree of process automation. The idea behind automation at this point is to increase efficiency and, above all, the repeatability of a process. If I repeat an activity several times, the same result should be achieved several times in order to be able to implement measurability and improvement later on. Manual processes always involve a lack of clarity in implementation, which is something you want to avoid here.

In order for collaboration to be efficient, care should be taken not to include excessive ballast in the processes and meetings. This means involving only those people who can contribute to improving results and not people who have always been involved for historical reasons.

The results should be measurable; automation also helps in this case. Measurability should be designed with DevOps principles in mind. This means that the quality of production and customer satisfaction play just as important a role as the number of units produced and employee satisfaction. Determining the measurement points is therefore a collaborative process, whereby the ultimate goal should be to achieve a sustainable business advantage.

Everything accumulates in insights that need to be shared. DevOps means sharing knowledge with all parties involved and avoiding knowledge silos. If something works, it should be shared with everyone. But the same also applies when there are problems. In companies, there are often still gaps in communication and a culture of withholding information. DevOps, on the other hand, requires a lot of openness. For example, feedback about problems with software should be addressed directly to the development team - along with tips on how to do things better. This also helps to build an understanding of each other's problems.

Why is the concept predestined for Industry 4.0?
von Kielpinski: Many dev-ops ideas are by no means new or IT-specific. In the automotive industry, the ideas have long been associated with concepts such as Kaizen or Kanban, which have now found their way into software development departments. In this respect, there is already a direct link in terms of ideas and terminology between software development and industry.
While in industry these terms have long been used within production chains, the rapid development of new business areas and the networking of a wide variety of data sources and systems is one reason for the increasing attractiveness of DevOps ideas. Industry 4.0 is the networking of existing digital systems into a coherent system landscape with further advantages and opportunities. The development of such cyber-physical systems is the step in which systems and things that have been separated for years are connected to create added value. This requires IT departments to coordinate with machine development. Business models go beyond the sale of a device and also include services.

All in all, it can be said that DevOps is predestined for Industry 4.0 because the original ideas came from industry, are successful and can leave production with the DevOps concept to create added value in the company.

Can you give us a specific example of how DevOps is used?
von Kielpinski: A mechanical engineering company has the specific challenge of offering additional services for its customers alongside the classic Industry 4.0 topics such as the networking of systems and thus expanding its business areas.

In one specific case, this led to the introduction of DevOps concepts in two steps. The first was the introduction in the IT area, starting with agile development concepts and a consolidation of the tool landscape used. On the other side of IT, there was the previously separate development of machines and their industrial control. Here, the company had to adapt the development cycles, whereby this was planned as a second, separate step.

The biggest challenge was creating a basis for communication and promoting trust between the two groups. Terminology was also a barrier, as were management tensions. Only after these had been largely overcome through many meetings was it possible to consider a cross-departmental introduction of development tools and processes.

In the next step, machine data had to be made visible on a customer portal and passed on to the accounting department to enable usage-based invoicing. Previously, these areas were individual, largely separate IT islands without communication standards or communication paths. It was also necessary to take account of existing structures and technologies. Changes had to be driven by management, but not decided over their heads, in order to avoid backlash as far as possible.

Finally, a support infrastructure had to be set up. When a mechanical engineering company offers customer portals, the next step is to deal with customer contacts that previously only existed in areas such as sales, maintenance or installation. The mechanical engineering company had not previously acted as a service provider, so a great deal of effort was required at this point to provide the appropriate structures and employees. Aspects such as data security and data protection as well as high availability of services added to the complexity.