Modern application delivery in the company Organizational aspects of the DevOps culture
DevOps combines processes, technology and employees. In order to optimally enforce the DevOps idea, it makes sense to realign the organizational structure in companies and to ensure a real “DevOps culture” in the company.
Companies on the topic
A solid DevOps team is cross-functional and equipped with expertise from a wide range of business areas.
The keyword DevOps refers to a much closer cooperation between software development and IT operations. Instead of previously clearly separated departments, it is important to create as large an intersection as possible between the individual areas in order to achieve maximum synergy effects.
In many companies, however, it remains with the mere buzzword bingo: one speaks of DevOps, but actually means only a better product quality. Especially in Germany, it is often not easy to change the structures in companies or departments – but that is exactly what is necessary to introduce an efficient DevOps culture.
There are various approaches to establishing the DevOps culture in the company. However, these are often doomed to failure if the traditional corporate structure is not completely re-conceptualized.
Existing divisions of the departments must be torn down, the organizational structure optimized, hierarchies rethought and processes revised. This is often a painful process. Especially in software companies that have existed for a long time, the DevOps idea therefore has a harder time than it should be.
DevOps in practice: Something from everyone
Ultimately, DevOps means that the integration of the Development and IT Operations departments, i.e. development and operations, will be significantly improved. However, DevOps is much more than just an interlocking of these two areas. A solid DevOps team is cross-functional and equipped with expertise from a wide range of business areas.
In addition to development and IT operations, knowledge from the areas of quality management, marketing and business development should also be on board in order to create a holistic environment. Its goal is clear from the outset: to develop the best possible product.
Use synergy potential
Unfortunately, it is still common practice in many companies to pass products from A to B to C. This creates unnecessary loops during development and thus causes costs. In addition, and this weighs more heavily, this “classic” approach can prevent or at least delay a really good end product.
After all, the proverb “many cooks spoil the porridge” also applies to software development – and when every specialist department regularly chews existing ruminants, there is a big patchwork of compromises in the end. A well-maintained DevOps culture, on the other hand, uses existing synergy potential.
Breaking up old hierarchies
It is not only essential to set up a DevOps team or merge two existing Dev and Ops departments into one. Rather, the organizational structure and hierarchy system must be reconsidered and revised. This is only possible if the hierarchies are as flat as possible-and the entire DevOps team is working towards a common goal.
The structure should be kept as simple as possible, because the so-called Conway’s Law plays a certain role in software development: organizations tend to develop systems that reflect their own communication structure. If a product is to be as simple and logical as possible, complex hierarchies and structures often cause the opposite.
Creating the right environment
So that the desired synergy effects do not wear off in communication, it is of course important that a DevOps team also has certain freedoms and is not “disturbed” by other departments. This means that the DevOps team must be considered as a whole, which in turn must have the necessary infrastructure available as a service.
Departments that are not directly involved in DevOps, such as corporate IT, need to ensure that the DevOps team can work smoothly, for example by providing the infrastructure needed to develop and test software. These can be virtual machines, for example, which can be copied and used quickly and easily.
Especially stale safety guidelines can prove to be a stumbling block here. A functioning DevOps team should also be able to” play ” and not be forced to communicate with external departments again for every small change.
Alternative possibilities of the organization
For this to work, different models of DevOps exist in the free economy: DevOps does not necessarily mean that development and IT operations need to be merged, but this model is very popular because it is efficient.
Instead of the merger, however, a “mandatory collaboration” of the departments is also conceivable: For this purpose, the departments are encouraged to a close horizontal cooperation, in which both areas play the developments back and forth so long, each with feedback until they are “ripe” to be passed through to the top.
Likewise, it is conceivable to collect only the team leaders in a kind of mini-DevOps team, which then coordinate existing classic departments. Such a structure has the advantage that all organizational structures can be maintained initially, which of course saves costs. In case of doubt, this is of course not a pure interpretation of the DevOps thought.
Use Site Engineers?
Also conceivable – and already practiced by some very large organizations such as Google – is the use of so-called site reliability engineers (SRE). These are developers with experience in the field of operations, who work with the previous developer and IT teams and virtually review them.
A team from SREs automatically works as a DevOps team, because the employees have both areas in mind. This team can be used as a bridge between existing operations and development departments or as a completely new DevOps department.
(ID:47333598)
