The Phoenix Project: A Novel about IT, DevOps, and Helping your Business Win
Revised Edition, 2014
By Gene Kim, Kevin Behr, George Spafford
I recently finished the book, The Phoenix Project – in this post I’ll go over a summary of the plot, and the useful Resource Guide towards the end.
This novel helps paint the picture of a company named Parts Unlimited, in desperate need of adopting the “DevOps” – collaboration between their development team and the operations team. Example after example is given on how the old traditional siloed model is no longer an effective method to conduct business as the main character of the story – Bill Palmer, walks us through how he comes to realize this and unknowing implements a DevOps in Parts Unlimited, along with other members on his team.
There is the elusive “Mr.Miyagi” type figure named Dr. Erik Reid – he’s the eccentric mysterious character that seems to know all the answers to Bill’s problems. Erik leaves breadcrumbs for Bill and lets him figure out on his own instead of giving him the answers outright. He meets Bill Palmer early in Chapter 7 where he is considering whether to join the Parts Unlimited board. After meeting with Bill and speaking to him regarding the horrible state Parts Unlimited is in – Erik senses that Bill is still a “young grasshopper” in training, gives him a small piece of paper with his contact info.
Later in Chapter 15, after (kinda) resolving the botched rollout of the company’s new super application dubbed “The Phoenix Project”, Bill starts to put together the pieces of the words of wisdom spoken by Erik earlier in the book. Bill along with his team, puts together a card system to track the progress of all projects and change requests coming in. Patty McKee, tried her best to implement an ITIL standard at Parts Unlimited, but no one ever used it (either it wasn’t user friendly, took too long to do, etc), and now the auditors are flagging issues left and right. Bill unknowingly puts together a Kanban system of keeping track of all requests coming into his team. The Kanban method is a hint to Erik’s “…First Way, which is creating fast flow of work through Development and IT Operations.” (Chapter 15, page 161).
He also brings up Dr. Eli Goldratt’s book – The Goal, apparently something popular in business school. Briefly skimming through this book, it is also written in as a fiction novel, similar to The Phoenix Project.
Erik called them “works in progress – WIP”. By visualizing all WIPs, Bill realizes there is a bottleneck in his team – a single senior engineer named Brent Geller. He finds not only there is a bottleneck in his team, but there is a ton of unplanned work which takes away time from getting Phoenix rolled out.
If anyone has worked in any IT shop, many of the issues and events shown here will bring a smile to your face, or you’ll nod your head to yourself saying “Oh yeah, I’ve seen this before”.
There is a turning point in Chapter 26, where Bill’s team (along with input from Erik), start to interview the business sponsors in the company. This is where Bill sees that IT directly affects the business needs for non-IT positions like Ron Johnson, VP of Manufacturing Sales, and Maggie Lee, Senior Director of Retail Program Management. Although they dont know, Bill sees that although the company sells mechanical parts, it is actually now an IT company. Without having the underlying infrastructure in place – business suffers. And when business suffers, the entire company does.
Towards the end of the book, Steve Masters, CEO – tells Bill that due to the many issues in IT, the board is considering to outsource IT, essentially ensuring all in house IT staff will lose their jobs. It is now a race on Bill’s part to ensure they can prove to the board that Phoenix can get rolled out properly. Bill talks with the Developers and they end up breaking off the Phoenix code (hint hint – QA, Test, Prod) so they can do testing in this sandbox – they’ve dubbed “Unicorn”.
In the final chapters of the book, the DevOps model really comes out as Parts Unlimited starts to do incremental rollouts of new code, getting initial feedback, and having the ability to rollback if necessary – instead of the Waterfall model of doing the entire application in one go. Patty even suggest a “Dark Launching” technique before the Thanksgiving Day weekend. When it is successful, Parts Unlimited green lights it for the entire user base (hint hint, Continuous Development, Continuous Monitoring and Continuous Deployment).
Finally, at Chapter 34, The team realizes the Dark Launch was such as success that they are dangerously close to maxing out their onprem physical infrastructure, and would need to purchase more equipment to handle the spiked load. A nice plug here for Cloud offerings – although not named (AWS, Azure, GCP, Softlayer, Digital Ocean, etc), the team starts to offload services into the Cloud and all’s well in Parts Unlimited world again.
The last chapter of the book, has the entire team coming together celebrating their success in turning the company around. Bill is now promoted to CIO in training with Erik being there to mentor him. They are now a full DevOps shop, with John Pesche – CISO, now implementing the “Evil Chaos Monkey”, trying to break their apps and now allowing them for regular working hours instead of weekend work being the application is so resilient and fault tolerant, work can be done in the middle of the day. The book ends with the team’s phones ringing — perhaps another issue has come up?
The Phoenix Project – Resource Guide
The last 20-30 pages of the book is dedicated as a “DevOps Quick Start” guide. Some takeaways here is how back when DevOps term was coined back in 2008 at the Velocity Conference session called “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” given by John Allspaw and Paul Hammond. That talk has been recorded and you can view it on YouTube here!
Top DevOps Myths
- DevOps replaces Agile – it does not, they can work together.
- DevOps replaces ITIL/ITSM – same as Agile, they work together, not replace
- DevOps means NoOps – book says this does not mean IT Operations is entirely eliminated, but I think its close to it! I’ve personally seen this initiative in my career, where Ops is the bottleneck for a lot of Developers, and other stakeholders in a company. I’ve seen tickets stay in queues for weeks with either understaffed or under trained admins, holding up projects. DevOps helps making Ops tasks more “self-service”, only requiring Operations if something is out of the box or the self service portal is not working as expected. At the end of the day, this can help Devs can bypass Compute, Storage, and Networking teams.
- DevOps is only for open source software
- DevOps is just “infrastructure as code” or automation
- DevOps is only for startups and unicorns – this one is an eye opener, all unicorns (DevOps shops) started out as horses (traditional enterprise shops). And as the book states, quoted by Christopher Little – “If there is anything that all horses [enterprise IT organizations] hate, its hearing about unicorns [DevOps shops]. Which is strange, because horses and unicorns are probably the same species. Unicorns are just horses with horns.” I’ve personally seen this time and time again as to why organizations cannot adopt a certain model, or cannot rise to an occasion. I’m sure many of the experience readers here can attest to this.
Overall, the book presents great points for someone new to DevOps and/or someone who has light experience in the field. Although some of the book could of been shorten, I get it is trying to be a novel, not a textbook. For those who’d like to skip the fiction and get straight into the “textbook” part of the book, I’d recommded reading the Resource Guide towards the end of the book, and reading up other DevOp resources like Edureka!. They seem to be the go-to CBT provider for DevOps, programming, Spark, Hadoop, etc. Check their YouTube Channel here.