Slides from

1. So what happens to The
Gatekeeper
The Future of Change Management in a
Continuous Delivery organization

2. 2 Copyright 2014.
Me! Me! Me!
▪ VP Products for XebiaLabs
▪ Lots of enterprise software development on high-performance
systems
▪ Been on both sides of the “Dev…Ops” fence
▪ Active open source contributor and committer:
jclouds, Akka, Gradle and others
▪ Cloud, PaaS & Scala fan
▪ Regular meetup, conference etc. presenter

3. 3 Copyright 2014.
Us! Us! Us!
▪ We build enterprise tools for DevOps and Continuous Delivery
▪ to solve problems around DevOps and CD at scale

4. 4 Copyright 2014.
Agenda
▪ What are we getting out of the CM Process?
▪ Rethinking CM & RM in a CD environment
▪ The Future of “The Gatekeeper”

5. 5 Copyright 2014.
What are we getting out of the CM Process?
▪ In many organizations, Change/Release Management policies require that
someone “approves” a candidate release before it can go live
▪ If you’re releasing once every 6 months, waiting a couple of days for approval
doesn’t seem like a long time
▪ If you can have the candidate automatically prepared, tested and deployed in
30min, waiting a couple of hours becomes a BIG (well, er, “narrow”, actually ;-))
bottleneck

6. 6 Copyright 2014.
What are we getting out of the CM Process?
▪ So…do we really need this approval?
▪ Sure, in some context (e.g. healthcare) there are requirements and regulations
that you cannot avoid. But do we need to wait so long for a manual approval to
be given?
▪ Think back: how many recent production failures have you experienced? How
many were prevented by approval reviews where it really was “the human
element” of the review that caught the problem?

7. 7 Copyright 2014.
What are we getting out of the CM Process?
▪ If you indeed have prevent failures using “the Zen factor”, the review may well
be worth it in your case. The reality, though, is that:
1. Approval processes are largely tick box exercises that could just as easily be
automated
2. Production failures still happen that were not prevented by the process

8. 8 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ So…what can we do?
1. Understand what the approval process is actually verifying and automate as
much as possible of that

9. 9 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ So…what can we do?
1. Understand what the approval process is actually verifying and automate as
much as possible of that
2. Ask ourselves: would we be prepared to accept responsibility for customer-impacting
failures that the approval process would have caught? If not, we
either don’t trust our automation enough, or our approval process may indeed
be adding value

10. 10 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ So…what can we do?
1. Understand what the approval process is actually verifying and automate as
much as possible of that
2. Ask ourselves: would we be prepared to accept responsibility for customer-impacting
failures that the approval process would have caught? If not, we
either don’t trust our automation enough, or our approval process may indeed
be adding value
3. Ensure we can rollback failed changes quickly and automatically

11. 11 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ Trade-off!
▪ It might make more sense to invest in better automated rollback than in
additional pre-release checks.
▪ Create an understanding that failed deployments do not matter, only failures that
noticeably impact your users do!

12. 12 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ Regarding The Zen Factor: human review has often proved useful in situations
where you are changing many parts of complex systems and knowledge and
experience is required to identify unimagined consequences.
▪ In a CD environment, the changes we make are much smaller and so the
likelihood of a butterfly effect is reduced.

13. 13 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ Regarding The Zen Factor: human review has often proved useful in situations
where you are changing many parts of complex systems and knowledge and
experience is required to identify unimagined consequences.
▪ In a CD environment, the changes we make are much smaller and so the
likelihood of a butterfly effect is reduced.
▪ I.e. CD encourages changes that are much easier to automatically verify.

14. 14 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ TL;DR: in a CD environment, the cost of waiting time incurred generally vastly
outweighs the Zen Factor Benefit of manual review and approval, especially if
you can quickly rollback should a failure occur in spite of automated checks.
▪ No matter how convincing the arguments, though, it’s not realistic to expect
someone to give up their Right to Check if they still have to take responsibility.

15. 15 Copyright 2014.
Rethinking CM & RM in a CD environment
▪ TL;DR: in a CD environment, the cost of waiting time incurred generally vastly
outweighs the Zen Factor Benefit of manual review and approval, especially if
you can quickly rollback should a failure occur in spite of automated checks.
▪ No matter how convincing the arguments, though, it’s not realistic to expect
someone to give up their Right to Check if they still have to take responsibility.
▪ Ask yourself: Would I be willing to take the pager?

16. 16 Copyright 2014.
The Future of “The Gatekeeper”
▪ So, er…what is the future of The Gatekeeper, then?

17. 17 Copyright 2014.
The Future of “The Gatekeeper”
▪ So, er…what is the future of The Gatekeeper, then?
▪ Let's take a bit of a CD detour for a moment...

18. 18 Copyright 2014.
The Future of “The Gatekeeper”
What is Continuous Delivery all about, actually?

19. 19 Copyright 2014.
The Future of “The Gatekeeper”
▪ Most of the time, you'll read about setting up delivery pipelines, and automated
environment provisioning, and deployment automation, and (well, sometimes)
automated testing
▪ Etc. etc.

20. 20 Copyright 2014.
The Future of “The Gatekeeper”
Blah. Blah. Blah.

21. 21 Copyright 2014.
The Future of “The Gatekeeper”
Blah. Blah. Blah.
Booooooring.

22. 22 Copyright 2014.
The Future of “The Gatekeeper”
▪ CD ≠ “gluing a bunch of tools together a bit better than we did it last time”

23. 23 Copyright 2014.
The Future of “The Gatekeeper”
▪ CD ≠ “gluing a bunch of tools together a bit better than we did it last time”
▪ CD ≠ “wiring up 10 Jenkins jobs with a nice Groovy DSL”

24. 24 Copyright 2014.
The Future of “The Gatekeeper”
CD = changing the way we deliver
IT services to our users!

25. 25 Copyright 2014.
The Future of “The Gatekeeper”
CD = making the delivery of new features and
functions a modern experience

26. 26 Copyright 2014.
The Future of “The Gatekeeper”
…the kind of experience we would want to use.

27. 27 Copyright 2014.
The Future of “The Gatekeeper”
▪ In other words, CD is about changing the way IT and the business interact to
allow you to:
▪ …spend more time building cool features for your users and
▪ …less time complaining that one side is too slow and the other has totally
unrealistic demands

28. 28 Copyright 2014.
The Future of “The Gatekeeper”
▪ In other words, CD is about changing the way IT and the business interact to
allow you to:
▪ …spend more time building cool features for your users and
▪ …less time complaining that one side is too slow and the other has totally
unrealistic demands
▪ The Gatekeeper is ideally positioned to mediate this change!

29. 29 Copyright 2014.
The Future of “The Gatekeeper”
▪ The Gatekeeper is ideally positioned to mediate this change:
▪ Used to interfacing with the business and the IT organization

30. 30 Copyright 2014.
The Future of “The Gatekeeper”
▪ The Gatekeeper is ideally positioned to mediate this change:
▪ Used to interfacing with the business and the IT organization
▪ Tasked with making sure new features actually get to the end users in a way
that doesn't break things really badly

31. 31 Copyright 2014.
The Future of “The Gatekeeper”
▪ Sure, The Gatekeeper needs to:
▪ …think more iteratively and in terms of smaller change sets where the
risk/reward ratio is different

32. 32 Copyright 2014.
The Future of “The Gatekeeper”
▪ Sure, The Gatekeeper needs to:
▪ …think more iteratively and in terms of smaller change sets where the
risk/reward ratio is different
▪ …take on board new operational capabilities to make new kinds of tradeoffs in
relation to confidence level required to go live

33. 33 Copyright 2014.
The Future of “The Gatekeeper”
▪ Sure, The Gatekeeper needs to:
▪ …think more iteratively and in terms of smaller change sets where the
risk/reward ratio is different
▪ …take on board new operational capabilities to make new kinds of tradeoffs in
relation to confidence level required to go live
▪ …understand delivery pipelines and see how automation can replace the
checkboxes in the Excel spreadsheet

34. 34 Copyright 2014.
The Future of “The Gatekeeper”
▪ If The Gatekeeper can do that:
▪ …they can become The Master of the Pipeline
▪ …and try to keep the business real, too

35. 35 Copyright 2014.
The Future of “The Gatekeeper”
Good luck with that ;-)

36. Thank You!