At EveryIT, our job is to not only solve customers’ biggest problems, but we hope to provide them with the tools and knowledge to continue making the right decisions for their business. This is why we decided to start a book review series with some of our experts. This week we sat down with EveryIT DevOps Architect, Jose Gonzalez and talked to him about The Phoenix Project, A Novel about IT, DevOps and Helping Your Business win.
You’re a DevOps Architect here at EveryIT. Can you tell us more about your role and why you choose DevOps?
I’ve just celebrated my two year anniversary with EveryIT in February. My role is focused on applying DevOps principles to projects to help accelerate delivery and increase the overall quality of client products and solutions. My aim is to ensure that we can truly shift-left and catch the problematic bugs and issues BEFORE we ever impact a real user. In a sense, I’ve been a DevOps enthusiast for a very long time and have always believed that IT is much more than a cost center to an organization, so I feel like DevOps chose me.
You recently read the Phoenix Project, A Novel about IT, DevOps and Helping Your Business Win. Can you give our readers a quick summary of the book from your eyes?
If anyone has ever been on an Operations team, worked on-call support roles, or simply been part of an IT initiative, you NEED to read this book. It all starts with a fictitious organization called “Parts Unlimited” that is being disrupted by its competitors and losing market shares very quickly. An internal business project (Project Phoenix) is the organization’s only hope for success. Project Phoenix has been in development for three years and there has been a twenty million dollar investment to bring this new product to market. The problem is that the organization is WAY over budget, they missed their delivery deadlines, and there is very low confidence that the IT department can ship the product to help close the gap with competitors and regain their competitive advantage.
The novel follows Bill Palmer who is promoted to the VP of IT Operations and tasked with making Project Phoenix a success. As Bill starts to realize that the Development team has taken all of the available time before the ship date, he does his best to persuade the CEO to delay the launch and paints a picture of disaster if the organization continues. It turns out the Marketing team has already purchased ads in the paper announcing Project Phoenix to the world, and a delay is now impossible.
As you can imagine, the executive decision to push forward without heeding the warning leads to a complete catastrophe during the release of Project Phoenix. Not only were the Operations teams ill prepared for deploying the code to Production, the Development team was still creating new “builds” to be shipped the day of the Production deployment. Things quickly head south as a critical database re-indexing job has slowed to a halt and the release has also taken out all of the Point Of Sale (POS) systems across all the Parts Unlimited retail stores.
The release, which should’ve completed in 6 hours on a Friday evening for a Saturday morning release turns into an extended deployment event, where Operations and Developers are working 24 hours into the middle of the following week before successfully deploying. But, the system is so frail that it requires Ops resources to constantly reboot servers due to a memory leak. And the product seems to be an overall failure because the features that were promised weren’t ready for the release and the organization encounters bugs in their product that end up displaying customer credit card information to other customers! It’s a nightmare from the start. The CEO tells Bill that IT is being held responsible for this entire disaster, and the Board members of the company are now considering outsourcing ALL of IT in the next 90 days. Essentially, Bill has 90 days to turn the company around before he and the rest of his teams are all out of a job.
Luckily, Parts Unlimited is currently courting a potential new Board member candidate named Erik Reid. After Bill and Erik are introduced, Erik quickly becomes an eccentric mentor that wants to apply manufacturing principles to the work of IT. While Bill is a skeptic (because there is NO way that IT work can relate to Manufacturing), Erik continues to impress the “Three Ways” upon Bill, slowly helping Bill realize that IT work is very similar to manufacturing. And optimizing the entire system’s flow only comes from assessing the “Four Types of Work” and applying the “Theory of Constraints” to identify and alleviate the bottlenecks that are preventing the IT organization to be viewed as a differentiator and an asset to Parts Unlimited. If you don’t already know, Erik is laying down the foundation for embracing DevOps as a methodology for delivering quality solutions and building capabilities that help excel the organization to a prosperous future. In the end, Bill becomes Erik’s student and completely turns around the organization with the ability to deliver features on a regular basis without fear of failure. Parts Unlimited can now respond to the market and customer needs as fast as those needs change.
What did you like most about the novel? Was there anything you read that you couldn’t wait to talk about?
Honestly, this book really sets the foundation for the DevOps movement that started in 2009. With references to many important pieces of literature as well as the iconic John Allspaw “10+ Deploys Per Day” presentation delivered at the O’Reilly Velocity conference in 2009, I can attest to the praise that this book has already garnered. It can turn skeptics into believers of the benefits that a DevOps transformation can begin delivering. It strikes a chord with anyone in IT, because I’m 100% sure that you will be able to identify with at least one of the many characters in the novel.
One of the biggest constraints in the book is a character named Brent, who is simply overworked because of his comprehensive knowledge of the entire organization’s IT systems. Essentially, no changes, projects, or improvements to the systems can take place without his involvement. He is a perfect illustration of the “Bus Factor” where if he was hit by a bus, the entire IT department and organization’s future might be in risk.
I have known a few Brent’s in my life, and I have been Brent in previous roles. One of the first realizations made by Bill is that Brent is a constraint to the flow of work because a single person cannot be in ten places at the same time. So he works to elevate his constraint and protect work that comes to Brent. Brent’s involvement in the real work to save the company is much too important to have his time completely consumed by so many different individual requests. The “Theory of Constraints” is definitely a subject matter that organizations should embrace and incorporate into their IT department.
How does the book relate to what you do for our customers every day? How did it change the way you approached your job?
Customers and clients typically deal with the struggles of Parts Unlimited. Technical Debt has made it difficult to make changes to existing code and fragile infrastructure has helped to pit the Developer and Operations teams against one another. Developers want to deliver new features for the business but the Operations team NEEDS to keep stability of their systems so there isn’t any impact to the business’s customer base.
By building a Continuous Delivery pipeline that keeps work flowing through the entire system and amplifying feedback loops for bugs and security vulnerabilities encountered, the Development team is empowered to iterate quickly on new features and the Operations team has confidence that the changes being made will NOT cause impact to their systems. The old adage of delivering quickly OR remaining stable is thrown out the window because you can now accelerate innovation AND remain stable.
That said, the only way to truly achieve this outcome is through collaboration. The Ops resources help automate their infrastructure provisioning, so environments can be created on-demand vs. having long wait times for the Dev teams. Developers get a set of quality gates that force them to deliver high quality solutions to production-like environments. The pipeline patterns are automated which reduce human error because code runs through a consistent, repeatable process. Implementing this is my primary objective on any project or at any organization. This the only way to deliver value to customers and stay on the cutting edge of market trends and customer demands.
So, now that you have finished The Phoenix Project, what book are you reading next?
Towards the end of “The Phoenix Project”, Erik asks Bill to do him one favor. He says, “I want you to write a book, describing the Three Ways and Parts Unlimited. Call it The DevOps Handbook and show how IT can regain the trust of the business and end decades of intertribal warfare.” It turns out that Gene Kim had already begun collaborating with Patrick Debois (who coined the term “DevOps”), John Willis, and Jez Humble to write “The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations”. So I guess you should keep an eye out for a future review of “The DevOps Handbook”.
Thanks to Jose for taking the time to explore The Phoenix Project, and to talk about how it applies to some of the real world scenarios he and his team face daily. If you’ve read the Phoenix Project, be sure to comment what you thought below! For more information on our DevOps service offerings, contact us today!
