In a word: automation.
The Change Advisory Board (CAB) is a significant component of Change Management in IT departments. Its promise? Minimize risk, speed up incident resolution and improve communication and collaboration. But in practice, the CAB significantly slows down Time-to-Market and is costly in terms of team mobilization and financial resources. It can also generate a false sense of security and lower the quality of delivery. 15 years of experience in Devops have taught me one thing: it's time to abandon your CAB in favor of automation.
The last decades have witnessed profound changes in the way applications are designed and managed. The two most significant ones are probably the generalisation of Agile and Devops approaches. At the crossroads of these two major transformations is Change Management, or how to ensure that the evolutions expected by the business are actually in production, in a secure way and without impact for the users.
One of the most visible aspects of Change Management is the CAB, which stands for Change Advisory Board, and at Alenia we work with many players, including the main investment banks. In these structures, the IT departments are made up of thousands of people, spread over the main financial centers (NY, London, Paris, Hong-Kong...) and are in charge of hundreds of critical applications. As in many large companies, the CAB culture is still very present. I have observed up to 4 instances of CAB for the same change request before it was authorized to go into production:
Each of these meetings often takes place on a weekly basis, lasting at least one hour and bringing together a significant number of participants (the business and their representatives, developers, business analysts, project managers, testers, integrators, application support, infrastructure professionals, change managers, release managers, managers, etc.)
Remember that CAB meetings are just the tip of the iceberg, and that it can take an hour or more of work upstream to draft and validate the workflow for each change request. On top of that, there is the CAB preparation and validation of each of these requests, often several hundred per week.
Why are CABs so prevalent?
We understand quite quickly that the process of making a new feature available to users is not going to be the easiest, but more importantly that it is going to take time! So why have most companies chosen to implement a CAB?
Once you get past human behavioral biases, which should not be underestimated, such as "we've always done it this way" or "if we don't have a CAB we don't have serious change management" or a corporate culture that generates more distrust than trust, the following reasons are mainly to be found:
In reality, what do we observe?
The CAB will mainly allow us to verify that each actor has correctly completed the change request. Given the volume, diversity and complexity of the changes to be processed, no one will be able to ensure that the actions have really been carried out correctly, or even to ensure that one change will have an impact on another. Worse, the CAB body, because of its position, often lacks the authority to really prevent a change. All of this creates a false sense of security and dilution of responsibility, where everyone thinks that what they do is validated by someone else, which contributes to a lower quality.
As far as traceability is concerned, there is often room for improvement. The slowness of the process means that the teams who are asked to go into production, generally under pressure from the business or management, prefer not to track or to make changes in a hurry.
Finally, regarding communication between teams, such problems are so deep that the CAB will generally become a battlefield, which is not the ideal place for collaboration.
The objectives of the CAB are therefore at best very partially achieved, and are in fact very costly:
Finally, the first reaction to a major incident will usually be to increase the control criteria of the CAB, or even to add an instance, which will accentuate this vicious circle.
In this case, why continue?
This observation is often shared by the different actors of Change Management, but it is still too rare to see CABs disappear. I think the main reason is that abandoning the CAB can be perceived as a reckless risk-taking and a signal that everyone can do what they want because the police will no longer be there.
In reality, the best answer to combine speed and quality can only be automation:
Can we really do without a CAB?
After more than 15 years in the delivery business, I think the only good reason to keep a CAB is to do so only when you have a clear strategy to get out of it. Here are 3 of the most common examples:
In the end, what should we remember? Change management and a structure to manage it are essential today. But to think that the CAB is necessary for the smooth running of the company is clearly a mistake, given its very relative efficiency and cost. The quality of the production process comes above all from automation. Automation that must be supported by a test factory that ensures with a high level of reliability that what goes into production will not cause regression or unexpected behavior. In addition to this, there are all the resilience levers, in order to limit the failure, or to make sure to be able to relaunch quickly if necessary.
If you are interested in this topic and want to extend the discussion, please contact me!