I was lucky enough to be the host of a Google Hangout last week with some very smart folks who will be speaking at IBM InterConnect 2015. One of the topics that we discussed was Two-speed IT or as Carmen DeArdo of Nationwide called it, variable speed DevOps.
What is meant by this term is the realization of the fact that different parts of an organization, even different parts of an IT team move at different speeds. Rather than forcing everyone to move at one speed, how can you use DevOps to allow these different size gears to mesh into one smooth functioning machine?
Constraints and bottlenecks pop up when one part of the process is allowed to proceed untethered only to either be constrained from a lack of resources or data from a pre-requisite or to be wasted as the output then has to sit and wait around for another part of the process to proceed. It is almost right out of The Goal by Goldratt.
How do we achieve a “just in time” method of IT? This is a problem that agile has tried to tackle in the development world, but what about the larger canvas of IT? That is variable speed DevOps.
Perhaps nowhere is this variable speed issue as visible then when talking about legacy mainframe systems working with modern cloud architectures. Yes IBM’s z/system team has numerous examples of exactly this taking place. But don’t be fooled into thinking that this is about making old stuff work with new stuff, for it is not.
I have discussed this with Sanjeev Sharma of IBM as well regarding a follow on panel on this subject that both he, Carmen and Rosalind Radcliffe will be participating in this month at the InterConnect 2015 event in Las Vegas (Mobile to Mainframe Experts: DevOps Best Practices for Systems of Engagement and Systems of Record, Session DEM-4399, Monday 2PM).
The real key to a successful DevOps implementation is recognizing the variable speeds of the different parts of the organization operate at. Yes automate, yes do more faster, yes, yes, yes. But at the end of the day some processes move like Cheetahs, others like Sloths. A Sloth is never going to be a Cheetah. The trick is making sure the Cheetah is not wasted behind the Sloth.
To be successful in DevOps, you cannot focus on one process or part of the story without a keen understanding of the big picture, the whole story. That is part of what I like about DevOps. It is a big picture, big goal game. While it is easy for any one of you to focus in on one piece or gear of the machine, it is the machine that counts. Machines have big gears and little gears, slow gears and fast gears. Getting them to function like clockwork is the key.
I think too many people try to get all of these gears to function at the same speed. In most cases this is a strategy destined to fail. Understanding the variable speeds of the people and parts of the process is necessary to cook the perfect dish.
So next time someone tells you that DevOps is about getting things done faster, remind them that we all can’t be the Cheetah. Sometimes speed kills. In real life we all move at variable speeds. So do different parts of the IT stack. Orchestrating them to be most efficient is really where DevOps wins.
