Change goes away

What does IT operational production change management look like in a highly DevOps-driven organisation? It doesn't. It vanishes.

We discussed how to transform IT Change Management from a change control function to a change facilitation function.

Ultimately IT operational change management goes away entirely. This is a very challenging concept for traditional IT but if you are changing production every few days, hours, or even minutes, then what does ops change management look like? It doesn't.

  • Controls, risk management, and accountability all shift left: others do them earlier in the flow.
  • The build teams peer-review and then self-certify the change. We treat them as if they are over 18.
  • There is no need for the business to approve a change that they asked for a week or two earlier, and anyway we decouple RequireToDeploy from RequestToProvision *, so business CAB is obsolete.
  • Our architecture becomes service oriented, with high levels of independence of components, so we can release without impact on other teams - we don't need to ask, so technical CAB is obsolete.
  • Workflow is automated so there is no need for completion checklists on change tickets - all the steps and pieces have to be completed.
  • Any remaining change controls are automated.
  • Work is more predictable, and done in smaller increments, so scheduling of release is planned when we plan the work (if at all), not as we come to the end of it.
  • Quality is everyone's job. It should be baked in to the flow, everybody is accountable (including for risk management and security). We don't need a manual quality gate.

Did I miss any other "change killers"?

I'm not pulling these ideas out of the first available orifice. This is how some organisations work.

This doesn't mean we don't have a Change Management team, but they no longer function as gatekeepers for tickets. They watch the flow of change and assure quality.

[Update: it also doesn't mean that Change vanishes overnight. This is a journey to less constraints on value. It takes time and work to move along the spectrum of less Change Management. This post describes the extreme of that spectrum. ]

Here's a far better discussion of ITSM’s DevOps challenge than I'll ever write


* To understand R2D and R2P, See IT4IT

Syndicate content