- Hardcover: 345 pages
- Publisher: IT Revolution Press; 1st edition (January 10, 2013)
- Language: English
- ISBN-10: 0988262592
- ISBN-13: 978-0988262591
- Product Dimensions: 7 x 1.2 x 9.8 inches
- Shipping Weight: 1.4 pounds
- Average Customer Review: 2,041 customer reviews
- Amazon Best Sellers Rank: #279,001 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win Hardcover – January 10, 2013
An Amazon Book with Buzz: "Ghosted"
Seven perfect days. Then he disappeared. A love story with a secret at its heart. Learn more
Customers who bought this item also bought
Customers who viewed this item also viewed
"A must-read for anyone wanting to transform their IT to enable the business to win. Told through an absorbing story that is impossible to put down, the authors teach the essential lessons in an accessible way. Every business leader and IT professional should read this book!" -- Mike Orzen, co-author of the the Shingo Prize winning book Lean IT - Enabling and Sustaining Your Lean Transformation
"This book is a gripping read that captures brilliantly the dilemmas that face companies which depend on IT, and offers real-world solutions. As Deming reminds us, 'It is not necessary to change. Survival is not mandatory.' The Phoenix Project will have a profound effect on IT, just as Dr. Goldratt's book The Goal did for manufacturing." -- Jez Humble, co-author of the Jolt award-winning book Continuous Delivery and Principal at ThoughtWorks Studios
"This book is the modern day version of The Goal. Today, our constraints aren't robots inside our factories, but it's how we manage technologies like Tomcat and Java that power our most critical projects and applications. This book continues the journey that began with Shewhart, Deming, Ohno and Dr. Goldratt, and shows us how to diminish our modern constraints to help the business win." -- John Willis, VP Client Services and Enablement, enStratus, Host of "DevOps Cafe"
"This is the IT swamp draining manual for anyone who is neck deep in alligators." -- Adrian Cockcroft, Cloud Architect at Netflix
"This insightful walk through the pain and success of business will trigger deja vu for anyone who has ever run afoul of their complete reliance in their IT organization. I see my own experiences in every stage of the story." -- Dr. Thomas Longstaff, Program Chair, Computer Science, Engineering for Professionals, The Johns Hopkins University
About the Author
Gene Kim is a multiple award winning CTO, researcher and author. He was founder and CTO of Tripwire for 13 years and has worked with some of the top Internet companies on improving deployment flow and increasing the rigor around IT operational processes. In 2007, ComputerWorld added Gene to the "40 Innovative IT People Under The Age Of 40" list, and was given the Outstanding Alumnus Award by the Department of Computer Sciences at Purdue University.
Kevin Behr is the founder of the Information Technology Process Institute (ITPI) and the Chief Strategist for the CIO and Board Advisory Practice at Assemblage Pointe, where Kevin has built a unique consulting practice that mentors and coaches IT organizations to increase their business effectiveness and competitive advantage now and over the long term through the application of improvement sciences.
George Spafford is a Research Director for Gartner covering process improvement in IT operations that leverage best practice references. He is a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall service improvement in the U.S., Canada, Australia, New Zealand and China.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
One of the best parts of the book was actually after the fictional plot ended, and the authors took the extra time to collect the concepts presented and revist them in a brief summary at the end. I hoped for this, as going back through The Phoenix Project to find each in turn, and learn more would have been difficult. If I could suggest to the authors an improvement, it would be to break the 4th wall during the fictional telling of the plot, and provide footnotes or references to the reader referencing where in the summary section they can read a bit more about a given concept. Nothing would be lost by this approach, as the reader quicky realizes the point and purpose of the plot anyways.
Overall, The Phoenix Project provides an easy way for non-business people to get their feet wet with process improvements, without making the explanations and concepts too burdensome. I find myself quoting passages with co-workers who've also read the book, realizing that all too many of the scenarios presented are real life problems we face everyday (though perhaps less severely than in the Phoenix Project.) As such, I know I've already taken something away from the book, even if I won't have a chance to master every improvement, or even experiment with them all. It provides a new way of thinking about software development, and all the organizations it impacts. Four stars.
DevOps is this mythical assembly line of progress that gets code from point A to point B in record time, and by record time, I mean no time. Coded, auto-tested, out the door, bing, bang, boom. The book was an entertaining read (and/or listen) and the authors cleverly couch the concepts of DevOps into a story about a failed delivery system (The Phoenix Project) built ala WaterFall, versus a new system hastily assembled (heh, see what I did there?) on an impromptu assembly line and delivered in record time, performing brilliantly - when compared to the failed behemoth Phoenix Project.
So... here's the problem with DevOps, and the problem with this book.
Companies with a nightmarish legacy code base (delivered or not as-of-yet out the door) that are attempting to build DevOps are using the same people that created their behemoth nightmare in the first place. As does the company in the hypothetical story in the book. Worse. The CEO in the book is a horribly bad boss, making wrong decision after wrong decision (I am sure to ramp up the tension to illustrate the saving graces of DevOps). So, I can tell you definitively that ANY company with leadership like that would lose their brilliant techs almost immediately. The market is in desperate need of brilliant techs so there is zero possibility that they are going to stick around a cess pool of politics when they can get a signing bonus and a raise from a company already doing it better and faster, and all without the drama. I'm just saying. And in order to pull off a DevOps operation, you absolutely need brilliant techs. You need tight, well executed product code with sufficient testing hooks so you can automate as you go. So you need brilliant QA that can understand and/or code the hooks right along-side the devs.
In short, you need a whole lot more than a single Brent. You just do. And to imagine that there are a room full of brilliant techs writing broken down shoddy bloated code for Phoenix, but then can turn around and write the brilliantly architected code you need for the DevOps project... well... I am able to suspend belief when called upon, but this was more like taking it out back, shooting it, and burying it six feet under. I'm just sayin'.
And with that being said, I am a huge, ginormous fan of DevOps (and the book was a FUN read / listen, thus the 4 stars instead of 3). It just takes an incredible talent pool to pull DevOps off and books like this makes companies think they just have to implement this process with the talent they have and poof! instant quality software that can be delivered instantaneously! Woohoo! <sighs> They would be better served facing the reality of the mess they have, caused by (possibly) a lack of reasonable process, yah, but almost certainly by lack of talent as well. That's basically how they got where they got.
Off soap box now. Doing the tango. Eating Oreos. Feel free to join!