DevOps is grounded in the Theory of Constraints that focuses on identifying and improving the weakest link in an organization’s value chain. Yet DevOps only improves part of the IT value chain. What about the functional requirements, value realization by the users, and the relationship with IT’s business partners? What is your biggest bottleneck? Is an investment in DevOps just sub-optimization?
Theory of Constraints
To quote Wikipedia, the theory of constraints is a management paradigm that views any manageable system as being limited in achieving more of its goals by a very small number of constraints. There is always at least one constraint, and the theory of constraints uses a focusing process to identify the constraint and restructure the rest of the organization around it. The theory of constraints adopts the common idiom “a chain is no stronger than its weakest link.” This means that processes, organizations, etc., are vulnerable because the weakest person or part can always damage or break them or at least adversely affect the outcome.
The theory of constraints was introduced by Eliyahu M. Goldratt in his 1984 book titled The Goal. Although the theory of constraints is closely associated with Goldratt, he acknowledges precursors, some of which date back to the 1950’s.
Application of the theory of constraints helps to identify the organization’s goal, the chain of interdependent activities that achieve it, and the weaknesses in the chain. By strengthening the weakness, the flow through the weakest link is improved, which in turn increases the throughput of the whole ‘system’.
Suboptimal IT practices
Many familiar IT practices just cover part of the end-to-end chain. Take Scrum. This Agile approach defines “potentially shippable software increments” as its end product. From a theory of constraints perspective, these increments are just inventory, waiting for another fragmented practice to deploy them into production. After which the new software will be used to support business processes that in turn, are used to market, sell and deliver products to customers in return for revenue, which is an important part of the goal.
Although the scrum team may be proud that they have produced the software in record time, it’s self-evident that until they are used for a business purpose, no value has been created. While it is useful to measure the rate with which software increments are produced, it is suboptimal and often contra-productive to set this as a goal.
DevOps’ technical practices
DevOps is based on bodies of knowledge such as Lean, the Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, and human factors, and can also be seen as the logical continuation of the Agile software journey that began in 2001. [source: DevOps Handbook]
I’m fond of Gene Kim’s definition of DevOps: “the set of cultural norms, technical practices and architecture that enable organizations to have both a fast flow of work from development to deployment, as well as world-class reliability, availability and security [of information systems and IT services].” Gene is one of the co-authors of The Phoenix Project and the DevOps Handbook. The Handbook builds on Gene’s definition and describes 67 technical practices in four categories: (1) flow, (2) feedback, (3) continual experimentation and learning, and (4) integrating information security, change management, and compliance into the software development lifecycle. I’ve analysed these technical practices and have mapped them as best as I can to three areas that they support: infrastructure engineering (including DevOps tooling), application development, and IT operations. 22 technical practices support infrastructure engineering, 40 support application development, and 21 support IT operations. Some of the 67 practices support more than one area and have been counted twice.
The technical practices are aimed at improving speed of delivery of software to production, operational behaviour (reliability, availability, security), cost, and the well-being of those who work in IT. None of the practices concern themselves with determining what functionality is required. This seems to define the ‘upstream’ boundary of DevOps: once the functional requirements have been established, then DevOps’ technical practices can be applied. It should be noted that many of DevOps’ generic cultural norms can and should be applied to activities beyond the scope of the technical practices, but the technical practices themselves start after requirements have been formulated, and end with ensuring that the information systems and IT services are available for use.
Zoom out
Let’s place these activities in a broader context. Taking an investment perspective on IT, we can say that there are 5 phases:
- Identification of a potential opportunity for investment in IT
- Justification that it is a worthwhile investment (business case)
- Realization of the solution (improvement)
- Exploitation of the solution (operations and use)
- Evaluation of the previous four phases against benefits and costs
[source: Information economics life cycle, Nijland and Berghout, 2002]
DevOps’ technical practices focus on realization (mainly the ‘continuous’ parts), the operations part of exploitation, and evaluation of these parts (there’s lots of emphasis on fast feedback in DevOps). In order to apply the theory of constraints, DevOps needs to be positioned in between a ‘prequel’ and a ‘sequel’. Referring to the phases of the investment lifecycle, the prequel starts with identification followed by justification, and the requirements part of realization, after which the majority of DevOps’ technical practices can be applied. The sequel concerns the use of the information systems and takes place in parallel with operations. Operations ensures that the information systems are up and running and supported from a technical perspective. Use comprises the use of the information systems, and use of information and technology in the business processes and products. The weakest link can manifest itself anywhere in this chain. It’s no good having perfect applications if the users are misinterpreting the information and taking the wrong decisions.
But it’s not only in this lifecycle that there’s more than realization and operations to think about – there’s also the stack of components to consider. The ‘solution’ comprises not only the applications and infrastructure, but also the organization that uses the information systems to process information in their business processes that support the marketing, sales and delivery of products to customers. Increasingly, information and technology are not just ‘production resources’ but are also a significant part of the organization’s products. So, in parallel with the development of applications and the engineering of the underlying infrastructure, business products, processes and organization are (re)designed and the users are prepared for the transition when the new or modified information system goes live. These business activities are not addressed by DevOps’ technical practices but need to be taken into consideration when applying the theory of constraints.
Figure: the investment lifecycle and the ‘stack’ of components that are needed to realize return on investment in IT. Yellow denotes where DevOps’ technical practices add value.
Weakest link: IT or the business?
This bigger picture shows the scope that has to be analysed when applying the theory of constraints.
If your weakest link is the speed of delivery of new functionality, or the systems’ operational behaviour, then DevOps has considerable benefits to offer. But if your weakest link is elsewhere, an investment in DevOps could be sub-optimization. So where is your weakest link, in the IT function or in the business? Are the right investment decisions being made, and is the user organization achieving return on investment? If not, start there before you go down the DevOps route.
