The theory of constraints (TOC) is an approach for maximizing the throughput of a given system. It was proposed by Eliyahu M. Goldratts and has been applied in manufacturing as well as DevOps. Personally, I like the idea because of it's simplicity and iterative nature.
Let's first define what we mean by a system. A system is a directed acyclic graph with some sources (nodes that do not have any incoming edges) and some sinks (nodes that do not have any outgoing edges). Work in such a system enters the system at some source node and is processed at different nodes, representing workstations, until it reaches a sink node, marking its successful completion. Below you can find a simple system with four nodes. Work enters the system at the right, is split across two different nodes and the completed in the node on the left.
The throughput of a given system is defined as the rate of work units that can pass through the system per unit of time. For example in a car manufacturing plant, the throughput would be the amount of cars processed per day.
Any business tries to maximize the throughput of its systems, since this gives it competitive advantage.
The theory of constraints can be seen as an iterative algorithm that in each step increases the throughput of the system, and therefore maximizing the throughput eventually. It is based on one assumption:
- In every system there is at least one constraint: a part that limits and therefore defines the maximal throughput of the system.
In the system given above, the node with 100% utilization is the constraint of the system. Based on this assumption we can draw the following conclusions:
Any optimization not made at the current constraint of the system doesn't have any effect on the throughput of the system. If we optimize before our constraint, this will lead to more work piling up at the already overloaded constraint. If we optimize after the constraint, this only leads to more idleness at successor nodes. Therefore optimization should be done at and only at the constrained node. The first step in the algorithm is therefore to identify the current constraint in the system.
Once we are sure about the current constraint, we can in the second step make sure it is maximally exploited and has no idleness.
In the third step, everything else needs to be subordinated to the constraint: In order to reduce the work in process of the system and stopping things from piling up in front of the constraint, the input to the system is throttled to the maximal throughput of the constraint. You could ask why it is necessary to reduce the work in process. In the book "The Phoenix Project" Gene Kim et al. give a very nice explanation of why work in process is the determining factor for making or breaking in many systems.
In the fourth step we check, which of the work currently performed by the constraint can also be done by other nodes. We try to direct as much work as possible away from the constraint. For example if the constraint is an engineer in your company, he should focus on engineering tasks rather than meeting coordination. Try to take away that burden from the engineer and move it to the project manager instead. Additionally, we check if the work performed by the constraint can be done in a more efficient way. This could happen through guidelines, checklists or similar tools.
After performing these four steps, the throughput of the constraint should be higher than before. Since the constraint was the limiting factor for the throughput of the whole system, these steps should have increased the maximal throughput of the whole system. If not, the optimization was likely done in the wrong place.
To further increase the throughput, we simply start again at the first step of the algorithm.
Practical Considerations
I like the simplicity of the algorithm, even though in practice the single steps can turn out to be quite difficult. Moreover, the algorithm can only be applied to systems in which the flow of work is explicitly known. In software develop for example the flow of work is often almost invisible: Everyone is typing on keyboards the whole time. With the help of ticketing systems and Kanban board techniques the work can be made more visible, including the handover of tasks to new workstations. In recent years, the upcoming of DevOps principles has identified and optimized many workflows in technology driven companies. I'm very curious how these trends will be further adopted by companies and which optimizations we will see.
Further reading
- The book "The Phoenix Project" by Gene Kim et al.
- https://www.alldaydevops.com/blog/three-ways-a-principle-based-devops-framework
Comments