Let’s get this straight right up front, the thought of reading a novel that’s about IT is so repellent, so repugnant, just so horribly wrong, that it’s kind of hard to fathom why I would even attempt it. What’s even more difficult for me to fathom is how much I enjoyed this book. Which is a novel. About IT. I can’t figure it out. Maybe I need to start reading more IT novels… no. Let’s hope that’s not actually a thing. On with the review…
The Phoenix Project is a story about a mid-level manager in a large company who has been running part of the IT organization that is a bit of a backwater, maintaining old big-iron systems, VAX, that type of thing. He gets called into the CEOs office and is made VP of IT Operations. But it’s a company that, from what I can tell, has done just about everything it possibly can do wrong in IT. It’s actually quite frightening to read through. I kept flashing back to some of my own experiences and some of the “interesting” choices made by the people running them. I won’t bore you with the entire plot. The gist of it is, things are awful, our hero goes on a quest, vanquishes a dragon and gets the girl. Well, anyway, the IT operations management version of a quest and a communications & process dragon and he was already happily married so there was no girl to woo, but hey, the good guys win, eventually. I won’t reveal anything else about the novel itself. Go read it.
The Phoenix Project is not simply a book though. This is meant to be an introduction to a concept. That concept has a name, frankly, one I hesitate to use because it outright smacks of catch-of-the-day marketing speak, but it does have a useful shorthand ring to it: DevOps. That’s right. This is a book about getting developers and system administrators and DBAs and support people and auditors to hold hands and sing songs. Well, or, just maybe work together in a more efficient and useful fashion. The thing is, it makes sense.
The book lays out all the issues that come about when IT & Devs don’t get along. Each side feels as if the other side is just simply out to get them. Weird rituals get established to hand off software between groups rather than working with each other right from the start of development. The book really rings true. You get a sense that the people who wrote it have been there, and done that, in regards to watching IT shops suffer. Fact is, they have. Gene Kim, Kevin Behr and George Spafford are IT pros and consultants. They’re coming from knowledge and understanding of the suffering that occurs daily within lots and lots of IT shops. They’re making an effort to reach out, to help out. The Phoenix Project is part of their efforts to grab the attention of as many IT people as possible.
It works.
I spent years at my previous job trying to do a better job interacting with the development teams (I’m sorry to say, to mixed results). But I recognized that was what was needed (even if I wasn’t the right person to make it happen). Since starting my other job, we’ve been even more aware of just how important it is for developers and DBAs and all the other IT specialists to find mechanisms to create a straight path from development to production. It’s something we have to do in order to make our businesses that we support more able to respond to the shifting business environment in a (pardon the word) agile fashion. It’s about working towards Continuous Delivery (another book I’m starting). It’s about, until we get a better word for it, DevOps.
This was a good read. It was also a quick read. I finished all 300 pages in about two days. I liked the characters and enjoyed the storyline. Yes, it’s a little simplistic at times. I also got extremely irked at the Yoda character on several occasions (mostly for acting too much like Yoda). No, it’s not SF, but you’ll know the character I mean. I also thought the villains of the book did a little too much mustache twirling. But remember, this is more of a parable than a novel. As a parable, it works. You’ll get the message, and I think it’s an important one for IT people to get.
