I haven’t been reading very many books lately. Most of my
training has been coming from videos, documentation, blogs, and, of course,
podcasts. In almost every podcast I’ve listened to in the past couple months
the book ThePhoenix Project, by Gene Kim, has come up at least once. I decided to put
it on my Kindle and then immediately forgot about it until one of my IT mentors
suggested I read it…so that I did!  I
went on to suggest it as good reading material to all my coworkers and then
about two days later, Nick Weaver, star guru of automation at VMware suggested
it in his keynote speech at the Indianapolis VMUG conference. That should be
enough to convince you people are liking this book!

The Phoenix Project is about a large public company that
just can’t seem to get things together. Their IT department is constantly
putting out fires in some chaotic way, the developers are putting out spaghetti
code, and the business is consistently falling behind their competitors. It’s
very much a case of the left hand not knowing what the right hand is doing. In
fact, for the first nine or ten chapters I would have laughed at the extreme
amount of failures and missed opportunities if I hadn’t also seen this first-hand
in real-life companies.

Kim presents all of this in such a way that you can actually
feel your heart rate increase because you remember going through some of the
issues he describes in the book. This is when the main character in the book,
acting VP of IT operations, starts learning about and implementing DevOps and
more efficient IT operations. He eventually learns to work not only within
operations, but also development, marketing, sales, etc., etc. He gains an
understanding that allows IT to enable all of the other departments in the
company.

What is DevOps exactly? The answer to that question is not
easy. According to Wikipedia,
“DevOps (a portmanteau of development and operations) is a software development
method that stresses communication, collaboration and integration between
software developers and information technology professionals.”  Through the use of DevOps developers can be
more agile and usually have more frequent releases of code, which according to
the book, increases the ROI on the code more quickly. From the IT operations
side, it requires standardization in the test and production environments,
along with automation of packaging the code releases, among other things
including standardizing processes and troubleshooting techniques.

Even though the book is about a company that heavily
utilizes development, in my mind this book applies to pretty much any company
with an IT department. Automation can be the key to efficiency in both large
and small IT departments. This, along with having processes and reasonable
change management policies, can make any IT department and maybe even entire
company run like a well-oiled machine. As much as I hate to use buzz words, the
ongoing trend of the software defined data center will also only increase the
need for DevOps within the IT department. If you’re a one man show or a
department of thousands, chances are you spend a lot of
your time dealing with unplanned work (aka “putting out fires”). This book can
help you think outside the box and understand business and IT operations in a
big picture kind of way.

Although the book can be a little frustrating, if not
depressing for the first half or so, it’s only that way because you can
probably relate to it. Once things start coming together for the IT department
as well as the company, you can’t help but think to yourself: “How can I apply
this methodology to my company?”  That’s
where the value of this book really lies. It doesn’t spell it out for you and
it’s definitely not a step-by-step instruction manual, but it makes you think. I
would highly recommend this book to anyone in and around the IT department.