I just finished reading The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford and it is one of the most thought-provoking IT books I’ve read in recent years.  For those who are not familiar with the authors, Kim, Behr, and Spafford are well-regarded luminaries in the DevOps world and co-authors of another book, The Visible Ops Handbook.  Gene Kim, in particular, is well-known as the founder of It security software vendor, Tripwire, and as a conference speaker, as well as author.  Kim’s website and blog is a great resource for anyone interested in DevOps.

The Phoenix Project is actually a novelization of DevOps principles rather than a strict how-to book on transforming IT Operations.  It is written in the tradition of IT Novels such as the Stealing The Network series, which I read voraciously when I was learning about Information Security.  I find the idea of using the genre of fiction to teach IT theory to be extremely effective, especially the concepts of DevOps, which are foreign to so many who are in the “traditional” IT space.  The Phoenix Project provides a vivid use case that describes the dysfunctional relationship which exists, not only between traditional IT and the Lines of Business, but between different groups within IT itself.  But not only does the book describe the problem, it offer a path to follow in order to transform IT into a true partner to the Business.

The protagonist in The Phoenix Project is Bill Palmer, newly promoted to VP of IT Operations for Parts Unlimited, a leading automotive parts manufacturer and retailer.  The problem is that Palmer has been promoted because his managers were fired due to the failures of the IT department, particularly in completing a software initiative, called The Phoenix Project.  This Phoenix Project is a software suite, developed in-house, designed to integrate manufacturing and retail while allowing Parts Unlimited to be more agile and nimble in accommodating to changes in market conditions.  The project is intended to save the company, which has missed earning consistently and has fallen behind its main competitor; unfortunately, the project is millions of dollars over-budget and years late in delivery.  Palmer is thrown on to the proverbial sinking ship and quickly caught up in one emergency after another and soon realizes that unless something quickly changes, The Phoenix Project is doomed to failure and along with it, Parts Unlimited.  However, Palmer finds himself ill-equipped to understand and to implement the necessary changes to right the ship, especially when there is so much distrust and infighting within the IT organization and with the Lines of Business.

Then Palmer meets the enigmatic Erik Reid, a potential board member with some very unusual ideas for how to run IT Operations.  Palmer is understandably skeptical but is soon drawn in as Reid takes him down the rabbit hole; through a series of encounters and events, Reid enlightens Palmer as to what is the true mission of IT and what must be done to make IT work as a partner to the Business.  The truths that are discovered not only change Palmer but the entire culture of IT at Parts Unlimited.

I had two different reactions as I was reading The Phoenix Project.  The first half of the book often made me reflexively reach for the Maalox as I found myself standing in Palmer’s shoes, reliving outages caused by buggy code and miscommunication between IT departments.  The second half of the book reads like the script from The Karate Kid, as we see Erik Reid, Aka. Mr. Miyagi, guide Bill Palmer, Aka. young Daniel, down the path to enlightenment about not only the methodology of DevOps but the cultural shift that is required for change.  Sometimes the lessons involve seeing tasks that seem to have little value to sound IT Operations, but Reid is able to masterfully walk Palmer through the process until he sees the proper connections between Manufacturing Plant operations and IT Operations.

That relationship between Manufacturing Plants and IT was, for me, the key insight provided by the book.  As Erik Reid succinctly states to Bill Palmer, “If you think IT Operations has nothing to learn from Plant Operations, you’re wrong. Dead wrong.  Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service.”  This is one of the best definition of IT Operations and also one of the most insightful statements on resource management that I’ve read to date.  After all, what can be more basic to resource management, rather it be a data center, software development team, Cloud, or people, than ensuring they deliver value through the completion of planned work?  Yet I would argue that because this is not the ultimate goal of many IT shops, they are easily sidetracked by the urgent and prevented from doing what is important.

The rest of the book shows how Palmer, with help from Reid, is able to inculcate a new culture in the IT department at Parts Unlimited so they can focus on the mission of saving the company by enabling the business of the company.  Along the way, they learn about the four categories of work (business projects, internal IT projects, changes, and unplanned work), the Three ways, and the importance of Kanban.  Each new discovery by Palmer and team is a call to action for IT departments that know they cannot maintain the status quo and must transform themselves to meet the demands of the current business environment.  This includes adopting operational practices from less “glamorous” disciplines such as Manufacturing Plant Operations. It means having Software Development teams working in true collaboration with the Operations teams.

I found the Phoenix Project particularly helpful as I think about how best to help VCE customers who want to move to an IT-as-a-Service model but do not understand that the change is not only technological but cultural.  My challenge is to appropriately advise customers on both the technological and cultural/procedural changes that must occur in their organizations.  Both are important – enabling technologies such as the Vblock, CIAC, the vCloud Suite, the vFabric Suite, CloudFoundry and OpenStack are critical; but even more critical is the changeover to a culture that demands accountability and cooperation between Development and Operations and sees IT as a true business enabler.  I  look forward to learning more and applying the principles from books such as the Phoenix Project; I hope to share, via this blog, my insights on the applications of these principles to ITaaS and tools such as Kanban and Scrum.  Now if I could only find a portable version of a Kanban Board!

Related articles

• imabonehead: Why We Need DevOps Now | Puppet Labs (puppetlabs.com)
• Book Review: The Phoenix Project (andrewhay.ca)
• Book Review: The Phoenix Project (pauldotcom.com)
• The Phoenix Project: Make business, security, and ops work together (tripwire.com)
• The Phoenix Project, a Novel for Today’s IT Professional (brandenwilliams.com)
• The Phoenix Project, a Novel for Today’s IT Professional (blogs.rsa.com)
• Why DevOps Matters (To Developers) (architects.dzone.com)