The increasing interest in DevOps gives rise to the question of whether it makes process management redundant. A logical question given the ambition of DevOps: a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes. Is there more or less need for processes in this new collaborative approach?
According to Wikipedia, a business process is “a structuring of the work that has to be carried out within an organization”. This does not have the emotional charge that many workers and their managers feel when they use the word ‘process’. Processes are often seen as being synonymous with bureaucracy, unwieldy and stifling. Although a process can also be used to clarify, accelerate and organize (especially when there is a need for a new process). It will be clear that while order may be a blessing for one person, it may prove a hindrance to another.
The big question is therefore whether DevOps represents more structuring, less structuring or perhaps just a different kind of structuring of the work. The latter is the case. The playing field changes, as do the rules, but they don’t disappear. At first glance, DevOps requires less structuring within teams, which together take on responsibility for development and management of new applications. People work well together and there is no need for restrictive arrangements. On the other hand, useful rituals emerge in most DevOps teams, such as daily kick-offs, the use of scrum boards and strict rules for development sprints, which an outsider might classify as a process. Similarly, the SAFe-model (http://www.scaledagileframework.com/) also looks like a great process diagram.
Apart from cooperation within the DevOps team, cooperation will be needed between teams. For this cooperation, we expect the now classic ITIL, ASL and BiSL frameworks will still be able to add value. However, they may become less necessary as teams become less dependent on each other, but in the case of dependence a set of rules will be necessary. And the auditors of this world, who want to ensure the effectiveness of the work on behalf of clients and shareholders, will expect agreements on processes and certainties for the same reason. However, it is necessary that a simple process framework is adopted in which only the necessary elements are included and the infrastructure (ITIL), application (ASL) and business (BiSL) elements are included. This is because process cooperation throughout the entire chain is needed.
Let’s take a closer look at the core processes of IT Service Management: incidents, problems and change management. These processes can be carried out within the DevOps teams without any further procedures. Incidents are processed by the team on an hourly, daily or weekly basis and large and recurring incidents (referred to as problems) are placed on the backlog to be resolved. When the team decides that a new version is good enough to be released, it can then go live. However, the team will have to make arrangements between themselves about incidents, problems and changes that affect multiple teams. These too have to be resolved in time (without passing them from pillar to post), investigated in multidisciplinary teams and verified for impact on each other so that the change can be moved safely into production. This will cause a change and we can offer a number of examples:
This too will also result in a reduction of the importance of operational processes.
The introduction of DevOps will therefore definitely have an impact on the organization, whether they lack structure or are highly structured, as well as on the processes. Process management will ensure cohesion in the organization when DevOps principles are applied. In organizations with too few rules, which we often call immature, DevOps will first have to be used to avoid a situation in which clear arrangements have to be agreed between teams. But to be really effective, they will also have to agree process arrangements among themselves. This is because in DevOps teams, the task is to maintain the health of the managed service. On introduction of DevOps, tightly organized organizations will be able to accelerate how they create customer value and, in particular, relax the process agreements within the teams. This can be done because many of these rules will be automated. And that is one of the reasons why DevOps is becoming popular: automation of operations, testing and release work.
Written by: Ronald Israels and Hans Smorenburg.