More than a DevOps story
Published:
Content Copyright © 2013 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
It’s not often that I review fiction in here, but I think this book is worth a read – both by IT professionals and by the business managers who (hopefully) manage them. The book is The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Kim, Gene, Behr, Kevin, Spafford, George, and it’s available on Kindle here.
It looks a bit like a case study with added human interest (that’s because it is; I think the authors will sell you consultancy if you ask) but don’t let that put you off – even my wife (who is more often a victim of corporate IT than a perpetrator) says she enjoyed reading it (she, in fact, found this book for me and read it before I did).
Despite the DevOps billing, I think it is as much a story of business continuity (keeping the business going, despite disaster, even self-inflicted disaster). The touches of human interest – which you don’t often get in a proper case study – are vitally important. Business continuity, in practice, is all about people issues (as is implementing something like DevOps, of course). Although, for that matter, having a well-managed business system to keep going is also important, in part because if you don’t know what automated processes you have and how they relate to business outcomes, it’s going to be very hard to prioritise their recovery when disaster strikes.
So, it’s a disaster story set in a world I’m more familiar with than the usual war/crime/sinking pleasure liner/escaped snakes scenarios. It’s readable but it is just a story – for god’s sake don’t see it as some sort of Golden Way to follow religiously. I believe that Grimm’s Fairy Stories embody some real, and useful, insights into the way people work – but I don’t believe in gingerbread houses (nor do I have a religious belief in Lean, Kanban boards and the Third Way, useful as they may be).
But why am I reporting on the book here? Well, Bloor likes telling stories as a way of helping people see what really matters and not enough people tell stories as an aid to implementing change. Once you’ve read this one, for instance, I think it fuels a really important part of business continuity planning: thinking the unthinkable and putting some contingency plans – and good process – in place before circumstances force you to. Effective process isn’t something you only implement after you’ve nearly gone out of business and any process designed and implemented in a state of panic is a high risk process. Interestingly, some of the “unthinkable” parts of the Phoenix story include the possibility of the following of “accepted good process” actually adding to your problems. I’d want to go through all the scenarios in this book, abstract them away from the story, and perhaps ask 3 questions: “could that happen here”; “if not, why not”; and “if the unthinkable isn’t so unthinkable, what can we do to stop it happening, before it does”…. And, yes, I think that business continuity planning is just another part of business governance generally, not another special silo.
A single takeaway from this book? Well, perhaps that success implementing changes comes from all stakeholders in the changing, automated, business (including auditors, security, C-level management as well as IT and Operations) collaborating and communicating from the earliest stages of a development or enhancement. This is instead of playing “blame games” and building defensive silos right up to the point were the business goes under.
Nevertheless, the only bit of the Phoenix book I find entirely unbelievable is the happy ending! Sometimes, once you’re in the tarpit (there’s a description of just one kind of IT tarpit here), you just can’t get out, no matter how much you struggle and even if you can see the firm ground. And managers don’t usually “see the light” overnight except in stories; and you almost never have an enlightened guru to point the way to firmer ground when you want one. Which is why you need to think about contingencies in advance and about why having a good process (such as DevOps) might help. Perhaps telling stories around the fire (with drink taken) is as good a way of doing this today as it was for our ancestors.