So, as we left off, I had a first draft DevOps Casual Loop Diagram:
As always I appreciate feedback and hopefully Majid and Rob will further their ideas here - the questions I have are:
- Do we want improvements in Change Capability to lead to larger Changes?
- How do we precisely distinguish between Stability and Availability?
In further looking at the diagram, I also become uncomfortable with the semantics of Change Risk. Risk is classically defined as probability * cost of occurence. I think that the cost of occurrence does NOT belong here. Only the probability affects availability. So, let's go with Change Failure. (I thought about Change Success but stayed with Failure as it works better for the practical implication below.)
Other thoughts followed. While I am unsure about a feedback loop between Change Capability and Change Size, there are clearly other reinforcing loops I was overlooking: Change Capability also enables higher Change Frequency, so it is a bidirectional relationship. Ditto for Change Frequency and Change Size. And finally, I began to see that there was a need to quantify the change backlog as a distinct entity not yet represented in the system (with all due respect to Occam's prescription to avoid non-proliferation of entities....)
Definitional note: "Change" in these blog posts is very generic, encompassing Project, Release, "as-practiced" Change, and so forth.
Notational note: Classic CLDs use two arrows, sometimes adorned by a "B" or "R" encircled by an arrow, to indicate balancing/reinforcing loops. Since I have no humility, I have invented a new notation for loops that involve just two entities - a bidrectional arrow adorned with either a "-B-" or "+R+", which has reduced the number of edges in the graph substantially. Of course, loops can involve multiple entities; my notation doesn't address that.
The first thing I recognize when looking at a dynamic model like this: as a human being, I can't understand it. That's why we use tools like iThink to simulate across many runs and various tweaks to the parameters. It's one thing to say (ala Sterman) that chickens and eggs are in a reinforcing feedback loop. But quantified, one starts to understand that there will always be more eggs than chickens, and that's a point at which CLDs start to fail and one needs full systems dynamics.
I've been tweeting back and forth with Majid Iqbal as I put this second article together. He raises a number of interesting issues:
- are smaller changes better per se, all things being equal?
- would an ability to handle large changes be beneficial, all things being equal?
I simply don't know. I do think for most organizations that large changes are problematic, and given the the intersecton of computation and complexity, there will always be strongly diminishing returns as change initiatives scale.
Finally, what's the practical outcome of this analysis? I think that the problem, the evil to be countered, lies in a truly reinforcing loop between Change Failure, Change Backlog, and Change Size:
Failed changes increase the backlog, which leads to the temptation to increase the change sizes ("batching" the changes together, because the delays are leading to scheduling collisions), which leads to more failure and so the feedback amplifies.
So, how do you break this? By managing for change capability (through techniques like automation), by deliberately increasing change frequency, and above all managing for change demand and execution - what in manufacturing ERP is called "release to production."
This is all conjecture. It's consistent with my experiences and the experiences I see reported. Have I identified the right set of entities? The right drivers? Am I postulating the right causality and dependencies? It would first vary probably by organization; every organization's mental model is different. But I still think that the essential intervention has to be somewhere in these core concepts.
Background and commentary for those who are interested, and crediting my inspirations:
In the 2006-7 timeframe I found myself in a number of somewaht contentious debates on this blog and over on Rob England's itskeptic.org regarding the merits of value chains vs. value networks, especially in the context of the first edition of ITIL v3 Service Strategy. While I am still dubious of value networks , the exposure to systems dynamics was invaluable. I have emphasized system dynamics' importance to the EA community at presentations sponsored by both Troux and alfabet. I know of a few enterprise architects starting to dabble, but not nearly enough.
As I wrapped up my 2nd edition in early 2011, a version of that first diagram (the naive "change vs. stability balancing loop) was challenged by my friend Jez Humble, among a wide variety of excellent feedback he provided. Essentially, he said I had an outdated mental model and correcting it was essential to understanding DevOps. As he assisted me in this transition, I realized that there had to be a systems dynamics/CLD expression of what he was saying, an idea that I finally found motivation to document.