Bimodal IT

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

• Front Office systems (systems of engagement) 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 (systems of record) 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.