Review of: The Phoenix Project 


The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win


Gene Kim, Kevin Behr and George Spafford

It is not often that you hear of a novel which is part of some ethereal ‘required reading’ list for IT professionals. This is apparently one of those rare beasts. I was dubious. I mean who reads a NOVEL about DevOps and software?! Putting aside my cynicism, I downloaded it onto my Audible.

While obviously a somewhat caricatured scenario (well… in most cases…) this book does a remarkable job of putting the software delivery life-cycle under the spotlight while actually remaining readable, engaging and entertaining.

The story revolves around a newly promoted Operations Manager, a failing company, and its flagship ‘super-project’ all set against the familiar backdrop of a highly competitive market. Hampered by disassociated business, project and IT teams, single points of failure, a chronic blame culture, and significant technical debt, the ‘heroic’ Operations Manager and his team embark upon a journey of Agile and DevOps self discovery under the (slightly bizarre) tutelage of a ‘IT whizz’ who seems a strange cross between ‘Master Shifu’ and a rich, aging hipster.

It turns out I enjoyed this book. I found I was identifying with the protagonist; cringing at the situations I recognised (countless!), laughing at the jokes and nodding sagely at the thought processes (and occasional absolute confusion) of the main character. Everyone who has ever worked in or alongside IT Delivery would recognise these characters; everyone knows someone a bit like Brent, or Sarah or John.

If you can suspend your disbelief at the apparent ease of new process adoption in this company (only ONE team actively trying to get around the rules?… yeah right!), the astonishing lack of panicked attempts to backtrack on the new processes when the going gets tough, and a somewhat exaggerated ‘mentor’ – this is valuable book. It takes the idea of ‘telling a story’ to its ultimate endpoint – a full novel. Instead of a pseudo-rule-book of buzzwords tied together with dry examples of a finished product, this book takes you on a journey to show how you could get there… and even more importantly, WHY you should.

As someone whose entire role revolves around one of those ‘bottleneck workstations’ so accurately described in the book, I found the authors managed to succinctly put their fingers right onto about 80% of my daily challenges. I also found myself giving mental high-fives when I identified initiatives that I have introduced or been part of in my own career, and rubbing my chin thoughtfully over possible future opportunities.

This book touches on most of the main challenges and drivers of modern day software life-cycle management, alongside practical descriptions of various Agile, Lean, Devops, Continuous Delivery, Kanban, Continuous Improvement, and a whole host of other practices in between. It identifies the common misconceptions between IT and the business, and it demonstrates -albeit in a somewhat exaggerated way – the benefits to the whole business if everyone starts working as part of a cohesive system.

I thoroughly recommend this book for anyone that works as part of – or relies upon – business IT as part of their job. Ir might explain a lot and it could have some useful ideas for your own practice.

Alright then. What is a IT Environment?

Leading on from my first post, the next question to clear up is ‘well….what actually IS a environment?’ To paraphrase IF4IT:

A…repeatable Configuration or set of Configurations that…act as a contained, bordered or surrounding operational context and that allow one or more Entities such as Resources or Systems to perform one or more controlled functions or activities.

…phew!… Lets try putting that into something a bit more manageable shall we?

Imagine a big car insurance company – pick any you want. Lets pick a system they might hypothetically use – lets imagine a website to sell their policies. What does a website need to run? A database, some applications, a server or two? OK. But is that ALL it needs? No. It probably needs to connect to a bank for payments right? Do they connect to other insurers to verify No Claims Discount? Who is doing the premium calculations? How about that extra legal cover they are offering you? What looks simple and seamless from the outside can actually be made up of tens – or even hundreds – of configurations, components and integrations. To the business – this whole entity is the Production environment for this website.*

But wait! The insurance company wants to add or change something on their website – maybe they want to offer Home Insurance? No matter how much faith they have in their technical teams, no business is just going to let them tinker about with the Production environment.. What if they break it? No website = no new policies being bought = no money = someone is getting fired!

So you need to make a copy of all (or at least the relevant parts) of the functionality of the Production environment so that the Project team tasked with adding Home Insurance functionality to the website can construct, verify, and promote controlled changes through the various stages of readiness before they are considered ready for the Production environment. How big should those copies be? What data will they use? What other systems do they need to push/pull information to/from?

In  businesses that have a broad or complex IT systems or are running significant IT change programs,  an Environment Manager (or a team of them) are needed to keep a handle on building these ‘copies,’keeping track of what they are used for, what is in them, who is using them, and what to do with them once a Project has finished.

*For any technical bods out there that are shuddering in horror at my vast generalisations I apologise. I find it easier to ‘tell a story’ when trying to explain concepts, (and I would assume that you all would know what a Non Production Environment is anyway!)