I just finished reading The Phoenix Project, a book in the style of Eliyahu M. Goldratt’s The Goal. I’ll try to cover the main ideas without going into too much detail. If there’s interest I can dig more into a specific theme or idea.

The Premise

Probably the main idea is that the software construction process is alike to a manufacturing plant line of production. If you have never been into the manufacturing process there are some concepts that you need to understand before going further.

Bill of materials

The Bill of Materials (or BOM) is a list that contains all the components needed to create a product, all the way down to the raw materials. An example could look something like:

• Product X
  • Component 1
    • Sub Component 1
    • Sub Component 2
      • Component 3
  • Component 2
    • Sub Component 3
      • Raw Material 1
      • Raw Material 2
  • Component 3
    • Raw Material 3
    • Sub Component 4
      • …

The BOM also includes the amount of each component or material needed.

Work Center

The work center as it name implies is a specific place where a specific activity takes place. Ie. in an automobile manufacturing plant, there could be a work center where the doors are attached, another where the motor is inserted in the vehicle and another one where it’s painted. In the phoenix project there are 4 elements in any work center: the machine, the man, the method and the measures. A work center also has a wait time: the time it takes to start working on an assigned task. The more tasks are pending to be executed by a work center, the more wait time it’ll take to start working in the latest assigned task. This is represented by the following formula:

Wait Time = % busy / % idle

Bill of Resources

The Bill of Resources = BOM + Work centers + routing, where routing specifies which work centers are needed to finish a product and in which order. Basically it list all the steps needed to complete a product.

The software feature release as a production line

According to the book, there are some work centers where certain activities take place when we are releasing a software feature/patch/update. Consider the following example:

Code -> Build -> Test -> Package -> Release -> Configure -> Monitor

These are all activities that take place on its own environment, and that need its own people, with its own techniques and procedures and its own metrics.

The 4 types of work

According to the book there 4 types of work:

1. Business Projects.- These are business initiatives to reach the company goals.
2. Internal IT Projects.- These are mostly infrastructure improvements that may or may not be derived from Business Projects.
3. Changes.- Different activities derived from Business and Internal IT projects that can severely affect the production systems.
4. Unplanned work / Recovery work.- Production bugs fixing

The idea here is to find where the unplanned work it’s coming from and fix the source ASAP, while accelerating the other types of work that really add value to the business. To do this the book proposes 3 improvement phases called The 3 Ways.

The 3 Ways

The First Way

The first way focus on accelerating the types of work that add value to the business. It does this by streamlining the work flow of the work centers, using techniques such as those from lean manufacturing: identifying value streams and using kanban boards, among others, limit WIP and the theory of constraints: identifying bottle necks and exploit them to the maximum. It relies on mechanisms such as continues build, integration and deployment, automating the creation of environments on demand (using tools such as Vagrant and Docker) and so on.

The Second Way

The second way focus on getting rid of the unplanned work ASAP. It does this by creating faster feedback loops from the work centers down the stream back to the previous control work center until it reach the responsible work center. This allow detection of anomalies and errors earlier int the deployment cycle. It uses techniques such as improvement katas, creating shared goals between departments and creating a production telemetry to make sure that 1) the systems are working fine, 2) the environments are working fine and 3) customer goals are being met.

The Third Way

The third way focus on creating a culture that fosters 1) continual experimentation and 2) repetition and practice. These are requirements to Innovation and Quality which are a must for any business survival these days.

Aligning IT to the business Goals

One of the things that happens a lot to us tech guys, is that we get so focused on technology that we paid less attention to the business it serves. We simply choose to learn technology over domain. This is comprehensible since tech skills are more transferable than domain knowledge for us. But one of the points remarked on the book it’s that first we must understand the goals of the business we are working for. This will give us the criteria to discriminate which projects and changes are important and must receive most of our resources. To me this sounds like the 80/20 rule. Only aligning to the business goals, can IT become a real advantage to the business.

Impressions on the book

I found the book very easy to read. While not as captivating as The Goal, the story line and writing styling weren’t boring. After reading the whole novel, I found some food for thought in the Phoenix Project Resource Guide and later chapters. The DevOps umbrella comprises a lot of tools and practices and Gene Kim and friends have done a very good job organizing those in the three ways. I very much recommending reading the book.