(ITIL® is a registered trademark of AXELOS Limited)
Are DevOps and ITIL® incompatible?
According to some people, DevOps and ITIL® are incompatible.
First of all: It is definitely not a „Free Lunch“ to establish DevOps in an ITIL®-orientated IT service organization – possibly still in combination with agile procedures – conversely, as shown in my book „DevOps Strategies„, it can be advantageous for traditional IT service organizations to be open to DevOps-driven changes and thus long overdue.
What is incompatibility?
You should ask yourself what exactly this incompatibility may be before embarking on the mission of introducing DevOps in an organization structured according to best practices described in ITIL®.
One could argue that DevOps addresses the same area as the ITIL® Service Lifecycle Stage „Service Transition“. While ITIL® describes the processes, functions, roles and KPIs, DevOps & Continuous Delivery deal with the soft factors (CALMS) and the automated integration and delivery of software. However, DevOps does not treat software development as a black box, but considers software already at the source code stage, which is at the beginning of every continuous delivery.
For ITIL®, software exists – roughly speaking – only as a deployable and hopefully well-documented software package that needs to be installed and operated, including periodic maintenance releases.
From the sole viewpoint of (especially agile) software development, change management processes can and will be much simpler than described in ITIL®. Or, to put it another way: The process steps and functions described in ITIL® can be streamlined and cleared out in terms of software development to such an extent that they also meet agile software development processes.
Under no circumstances an incorrectly understood „ITIL® compatibility“ should led to the reproduction of every singleprocess step and every operational function mentioned in ITIL® – It is like a disease for the author if organizations are desperate to implement the processes, functions and roles described in i ITIL® 1:1.
These points alone seem to argue for compatibility, but at least for a possible coexistence of ITIL® and DevOps. This would be the mentioned transition lifecycle phase.
But there is another aspect:
DevOps originates from the agile software developer scene, while ITIL® focus only on IT operations.
Although ITIL® recognizes the problem of silo structures, it still assumes that there are functionally separate teams – cross-functional teams, as propagated in the agile world, are foreign to ITIL®.
However, the best practices described in ITIL® are just these – best practices that have no claim to adaptation and change.
Antipattern for the introduction of DevOps in conventional companies.
The fact that functionally separate teams and structures have been established to ensure proper IT operations does not necessarily mean that this must always remain so. This separation sometimes goes far beyond the ITIL® Best Practices, e. g. when DNS entries and IP addresses are assigned and managed in different departments. Such structures have nothing to do with efficient organization, but are not as rare as the author knows from his own experience.
They do not only stand in the way of agile procedures, but also of the efficiency of conventional organizational structures and procedures. Several IT service organizations are also known, in which the defined workflows only function if the representatives of the departments/teams involved meet unofficially for short meetings in which:
- The status of the respective task is recorded
- All the involved departments/teams renew their commitments
- And the various impediments are identified and tackled.
If, in spite of defined processes and workflows, it only degenerates into a „hidden process“ on the basis of unofficial communication, the organization can introduce SCRUM into Service Management anyway – exaggeratedly said ….. Let’s give it a try… The organization could now focus on the areas of greatest suffering caused by excessive functional separation.
DevOps antipattern 1: retention or re-introduction of functionally separate teams
But even without the introduction of agile procedures in parts or in the entire „ITIL® organization“, there will be the creation of (new) teams of software developers, DevOps engineers and operators in the life cycle stage Service Transition.
I. e. some teams must give up or lose persons, especially if the functional separation between teams is to be abolished. In order to limit this „loss“ and to continue to provide long-standing employees with management positions, new silo structures are regularly set up. e. g. in the form of DevOps teams – a contradiction by itself.
Stopping such „crazy“ management actions is difficult, because it is about influence, money and face preservation.
Unfortunately, higher salary classes are automatically accompanied by personnel management tasks. However, it often seems to be irrelevant how bad personnel management is. Outstanding professional or technical performance does not earn as much money as bad leadership. Such companies have significant problems attracting motivated specialists for DevOps and agile development, while the management adheres to inefficient structures and team leaders.
Societies with less rigid, highly hierarchical structures should have it easier to implement such changes than societies of emerging countries with an even stronger hierarchical character. However, I see this competitive advantage waning.
DevOps Antipattern 2: Missing sourcing strategy
Another antipattern in the DevOps introduction is to assign the title of the DevOps Engineer or „DevOps“ to existing persons, without or before they have acquired the necessary qualifications – instead of giving these employees the necessary training measures.
I. e.: When introducing DevOps, additional personnel must always be built up, at least temporarily as external employees:
- Either these are already qualified DevOps employees.
- Or conventional skilled workers, so that existing employees have the time for further training.
Software developers and software architects who are interested in business processes often already have the majority of the necessary prerequisites for a DevOps Engineer, while „old“ service management specialists and administrators have to master a much steeper learning curve when it comes to acquiring knowledge in software development. I would ask for the reader’s indulgence if this statement sounds very generalizing – but in many cases it points into the right direction.
Employees with potential must be encouraged and challenged in a targeted manner, regardless of existing team sizes and areas of responsibility.
- The introduction of DevOps has far-reaching consequences, is not for free and leads to changes to personnel structures. Affected members of the team and department head level often reluctantly accept these changes as they are associated with disadvantages for the respective persons.
- The integration of DevOps into conventional IT service structures often fails due to a lack of willingness to purify processes structured according to ITIL® and to eliminate unnecessary functional separations.
- Another impediment in the DevOps rollout is a failed or half-hearted sourcing strategy – as well as for existing and new staff.
If an organization can overcome these and other obstacles to DevOps deployment, it is not impossible to successfully establish DevOps in ITIL®-influenced IT service organizations.