There is no way around DevOps. The recent "2016 State of DevOps Report" by DORA, the experts of the "DevOps Research and Assessment" leave no doubt that the new agile method offers enormous potential. Specifically, so-called "high-performance IT organizations" are more than 200 times more likely to roll out new releases, are 24 times faster in resolving software errors, have 3 times fewer failures due to unsuccessful changes, and 2 ' 500 times faster throughput times.
These figures are so impressive that one would like to read them as too utopian and shrewd. More and more often, however, we also hear and read from companies in Switzerland who have already been able to show their first successes with this new method. Organizations that have apparently succeeded in overcoming the Rösti ditch between the Developers and the operations and brought about bureaucratic silo constructions.
The operations people have good reason to protect the production and to avoid uncontrolled changes as far as possible. On the other hand, the developers want to take the pressure of the business into account and deliver new functionality as quickly as possible. A classic target conflict, which has dominated IT in the last decades and which has never been solved to the present day. An inherent target conflict, so to speak. The business is to choose between "fast and cuddly" or "slowly stable". Quality before time was given to the business because otherwise no warranty was taken.
One has to solve this stereotypical view, if one wants to understand the phenomenon "DevOps" better. It is by no means that the developer wants to force the production to its knees. Even the production manager does not want to prevent the further development of the business. Everyone wants to contribute the best for the company. This is an important basic setting for a new cooperation model.
Today, individual teams are already trying to optimize with scrum or CSI approaches in their workspace. But what are the benefits of software solutions developed with agile sprints when they are restarted during release planning in order to be tested and delivered as an integrated whole at a later date? Too rarely one considers the whole value stream from the idea to the conception, from the implementation in the development to the testing, from the deployment up to the hopefully utilizing enterprise. Everywhere new heads and tools are involved and make their "thing", as always has been done. In the end, no one dares to ask what the benefits to the customer are.
These figures are so impressive that one would like to read them as too utopian and shrewd. More and more often, however, we also hear and read from companies in Switzerland who have already been able to show their first successes with this new method. Organizations that have apparently succeeded in overcoming the Rösti ditch between the Developers and the operations and brought about bureaucratic silo constructions.
The operations people have good reason to protect the production and to avoid uncontrolled changes as far as possible. On the other hand, the developers want to take the pressure of the business into account and deliver new functionality as quickly as possible. A classic target conflict, which has dominated IT in the last decades and which has never been solved to the present day. An inherent target conflict, so to speak. The business is to choose between "fast and cuddly" or "slowly stable". Quality before time was given to the business because otherwise no warranty was taken.
One has to solve this stereotypical view, if one wants to understand the phenomenon "DevOps" better. It is by no means that the developer wants to force the production to its knees. Even the production manager does not want to prevent the further development of the business. Everyone wants to contribute the best for the company. This is an important basic setting for a new cooperation model.
Today, individual teams are already trying to optimize with scrum or CSI approaches in their workspace. But what are the benefits of software solutions developed with agile sprints when they are restarted during release planning in order to be tested and delivered as an integrated whole at a later date? Too rarely one considers the whole value stream from the idea to the conception, from the implementation in the development to the testing, from the deployment up to the hopefully utilizing enterprise. Everywhere new heads and tools are involved and make their "thing", as always has been done. In the end, no one dares to ask what the benefits to the customer are.
Internal value of IT4IT
DevOps is different. The success of DevOps goes beyond the development and the operation. As is often the case, it is not primarily a technical simplification, but a cultural change that needs to turn the cooperation from the idea to the value-generating services completely upside down. DevOps is an artistic name from development and operations, but should be called "value flow". The entire value flow is intended to be understood. This also includes common incentives and objectives. All teams put their minds together and look at the individual steps and processes involved to understand how the value develops and where unnecessary barriers lead to delays and waste.
It requires a questioning of existing patterns of thought. Since changes and stability are generally diametrically opposed, changes are postponed to transfer them into larger production batches as a release. Complex systems do not react well to such large changes. It would be more effective to implement the changes continuously over time in small steps. This results in the paradoxical realization that more frequent changes provide better stability.
Another point of view is the preservation of glass production. If the volatility of the changes is artificially suppressed, then production tends to react more susceptibly to changes. Risks are scarcely visible because permanent attempts are made to keep "any" damage from production. If something happens then it becomes critical for the business, because the error must be looked like a pin in the haystack of the big release. If you are growing up in a sterile environment, you will not learn to live in the "dirty" everyday life.
The developer must in the future build his software so that it is robust. The quality must be in the antifragility of the developed solution. This does not mean simply robustness or strength, but much more the ability to respond to faults in the system and to spontaneously changing boundary conditions in a suitable way, just antifragil.
DevOps can be very exciting, however, if you want to throw old visions overboard: Teams learn together, faster and at higher clock rates to deliver and at the same time better to the business. With DevOps the ditch between development and operation is added. Stability and high change density need no longer be a contradiction. As the DOSA report shows, with DevOps, IT delivers faster, better, and more robustly and more securely than traditional operating concepts.
Posts
