Bimodal IT is the flawed notion that software systems should be divided into these
two distinct categories for management and control.

Front Office systems should be optimized for rapid feature development. These systems
of engagement need to react rapidly to changing customer needs and business
opportunities. Defects should be tolerated as the necessary cost for this rapid
development cycle.

Back Office systems should be optimized for reliability. As systems of record, it's
important that you don't get defects that damage the enterprise. Consequently you slow
down the rate of change.

The term Bimodal IT is used by Gartner [1]. McKinsey and Co talk about the same basic idea under the name "Two Speed IT". (I find it hard to resist calling it "Bipolar IT".)

When I first heard about this approach, I was pleased - thinking that these august
organizations had come to same conclusion that I had with my
UtilityVsStrategicDichotomy, but as I read further I realized that Bimodal IT
was a different animal. And worse I think that Bimodal IT is really a path down the
wrong direction.

My first problem is that the separation is based on software systems rather than
business activity. If you want to rapidly cycle new ideas, you are going to need to
modify the back office systems of record just as frequently as the front office systems of
engagement. You can't come up with clever pricing plans without modifying the systems of
record that support them.

My second issue is that the bimodal idea is founded on the
TradableQualityHypothesis, the idea that quality is something you trade-off
for speed. It's a common notion, but a false one. One of the striking things that we
learned at ThoughtWorks when we started using agile approaches for rapid feature
delivery is that we also saw a dramatic decline in production defects. It's not uncommon
to see us go live with an order of magnitude fewer defects than is usual for our
clients, even in their systems of record. The key point is that high quality (and low
defects) are a crucial enabler for rapid cycle-time. By not paying attention to quality,
people following a bimodal approach will actually end up slowing down their pace of
innovation in their "systems of engagement".

So my advice here that it is wise to use different management approaches to different
kinds of software projects, but don't make this distinction based on the bimodal
approach. Instead take a BusinessCapabilityCentric approach, and look at
whether your business capabilities are utility or strategic.

Further Reading

Sriram Narayan's book - Agile IT Organization Design
- looks at this kind of problem in much more depth.

Jez Humble provides a worthwhile critique of Bimodal IT

Simon Wardley prefers
a three-level model of Pioneers, Settlers, and Town Planners.

Notes

1:
Sadly all their substantial material is available to subscribers only.

Acknowledgements

Brian Oxley, Dave Elliman, Jonny LeRoy, Ken McCormack, Mark Taylor, Patrick Kua, Paulo
Caroli, and Praful J Todkar

discussed drafts of this post on our internal mailing list



Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement