I know people have many opinions about what DevOps is, and I have read so many definitions.
For many people it might just be a word, but when you have experienced it, it is really a revolution.
For some it is about culture , for some it is about process, yet for others it is about tools .
To me, DevOps shares a lot of the principles and ideas that revolutionized manufacturing. DevOps is about optimizing the delivery chain, from idea to end user.
DevOps is a revolution for IT.
Revolution might be strong words, but this is not just talk. There is recent research that shows for the first time in the IT industry, that given the right mix of technology, practices and culture, organizations can be 2x more likely to exceed profitability, market share and productivity goals. Even resulting in a 50% higher market cap over 3 years.
This mix is DevOps.
When we optimize the delivery chain, it is about flow. This makes flow one of the fundamentals for DevOps. Flow is what chains everything together into value – the value chain. And the value chain has to be optimized holistically, not locally, but end-to-end.
Flow is about keeping things moving, so to achieve better flow, we need to find ways to optimize how we move between tasks.
Lets think about this for a minute:
Flow is throughput. It is different from capacity. We often look at optimizing for capacity more than throughput.
Compare this to a highway. If the highways capacity is filled to max, it is still. The cars are not moving. So definitively, it is not about capacity by itself.
Based on the analogy to the highway, we understand that to achieve throughput we need to limit the number of cars we let enter the highway at any given time.
A key to limiting capacity, is to put in place Work-in-Progress limits (WIP). This is of essence to be able to control flow.
This is linked to a theory called Theory of Constraints.
The theory of constraints assumes that all organizations can be measured AND controlled by three key measures:
THROUGHPUT, OPERATIONAL EXPENSE and INVENTORY.
Throughput is the rate we generate money (or, we can say, value)
Inventory is what we intend to sell (or, as I like to think of it in DevOps, create, deploy)
Operational Expense is what we spend to turn inventory into throughput.
To optimize the end-to-end flow the theory has identified the following steps:
- Identify the systems constraint(s)
- Decide how to exploit the systems constraint(s)
- Subordinate everything else to the above decision(s)
- Elevate the systems constraint(s)
- If in the previous steps a constraint has been broken (i.e. removed), go back to step 1, but do not allow inertia to cause a systems constraint
For sure, this sounds simple, and in the real world, we often need to work through layers of resistance to achieve this. To work through the resistance, a common approach is the following steps:
- Gain agreement on the problem
- Gain agreement on the direction for a solution
- Gain agreement that the solution solves the problem
- Agreement to overcome any potential negative ramification
- Agree to overcome any obstacle to implementation
You might say all this sounds great – but how do I start in my organization to try this out?
I am glad you asked, and here is some tips based on experience to get you started:
- Start small
- Solve a problem that really matters
- Don’t think too much, but do a lot. Learn. Validated learning.
- Start with a small footprint, but a long leg. (make sure all layers of management is involved)
- Stay safe. You will make errors. Things will break.
- Don’t wait till you have enough time. You never will.
Until my next article on DevOps, remember to keep CALM and remember DevOps is not about just one particular thing, it is a combination of people, process, culture and technology.