Happy mode, sad mode, DevOps mode: Stop worrying and go bimodal
Beware West Coast motivationals, just do IT
There’s a debate going on right now about the best way to run IT: specifically, all those custom applications and services inside organizations. Do we try new, agile approaches, or stick to the old, methodical processes?
Gartner did much to start this discussion with their bi-modal concept:
Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.
Mode 1 deals with predictable, well understood tasks, while mode 2 is for exploratory tasks, all those known unknowns and unknown unknowns out there. Gartner even works Cynefin in there for some complexity theory seasoning.
When you net it all out, much of how Gartner describes bimodal IT is pretty similar to the “slow down and think more about how to solve your problems, and focus on outcomes over processes” school of thought – aka the “stop doing dumb stuff” vibe that you hear from the DevOps world.
A key motivation for having two modes is to protect the new, agile teams from being clobbered by the old, waterfall-y teams and their Big Process ways: it can be too hard to change culture enough enough at scale to survive lift-off, and then you’re just stuck back in the muck.
Most people take all this be sanctioning “old IT” resulting in freezing the use of new IT stacks (“cloud!”) but freezing any changes to the culture and process around those “mode 1” applications. The opposing camp, then, tends to see the result of bimodal as somewhat the opposite of Gartner’s goals of encouraging and creating organizational oxygen for innovation.
As such, you can imagine that the “unimodal” (as we’ll call them, eh?) camp asks the question “why wouldn’t you just run everything in awesome mode?” It's a good point: the way the debate has been framed implies that some staff will be beset with operating in “sad mode” until the pink slips rain down. Rather than fixing how all of IT runs, if it's left to fester, Jez Humble says, your legacy IT will eventually eat you up from the inside:
[L]eaders that fail to move beyond Gartner’s advice will end up falling further and further behind the competition. They will continue to invest ever more money to maintain systems that will become increasingly complex and fragile over time, while failing to gain the expected return on investment from adopting agile methods.
Gartner rival Forrester has noted several times that the happy/sad mode approach can lead to low morale and, thus, one would infer, less than ideal productivity. And as another dip-stick into the sump of sentiment around this issue, the reaction to bimodal as a keynote topic at the recent OpenStack Summit was along the lines of “I think I just threw up a little bit in my mouth”.
In defence of the counter-counterpoint, as it were, there are some systems in which failure can be very expensive; thus, change carries more risk. Perhaps we should give those systems extra time and attention, or leave them alone entirely. We have this notion that rapidly changing software, though it may delight users with a weekly cornucopia of new features, will cause downtime.
“Move fast and break things,” as the West Coast motivational posters put it. “Yeah, not so much with my systems of record,” the ITIL-set would retort.
Of course, the promise of the new, DevOps-y way is that there’s ample testing and architectural resilience to remove such fears. If you can deploy at will, you can also patch and even rollback at will. Your operational maturity is a safety net. The DevOps set are interesting in proving out that unimodal is the one true way and, as indicated by Humble, believe the evolving research shows you can both move fast and avoid breaking things, if not make your software and staff morale downright better.
Thus far, much of the commentary has come from analysts and consultants. They of course imply that they’re channelling the voice of the customer, but it’s always good to go to source directly. In discussing how one of the US’s largest insurers, Allstate, has been revamping their approach to IT department Matt Curry gave some advice on bimodal IT.
“It creates this dichotomy of competition and resistance,” in the IT department Curry says, “and that’s not really what we’re trying to create.” What they’re trying to create is more collaboration and understanding amongst staff to propel a unified IT department forward. Instead of going together hand-and-hand, as Curry adds, “bimodal drives this wedge into your organization and it’s a terrible, terrible thing.”
(I’d be remiss if I didn’t point out another, delightful, response to bimodal: the so called “trimodal” approach.)
Can’t we all, just get along?
I always get the sense that the two camps are, more or less, talking about the same thing: giving IT the processes and culture needed to be more innovative and, thus, helping out the larger organization more. The two camps are just approaching them from different angles, constraints, and symptoms they’re addressing. And, of course, with much of its content locked behind an expensive paywall, we can’t expect many of the free-wheeling DevOps-set to be reading up on bimodal.
Perhaps Gartner would do well to jump, rather than toe-tip, into the fray. These two camps should sort out their differences and start talking with one voice. After all, we’d all benefit from the software at large enterprises and governments sucking less, and that’s what both of these camps are after. ®