A Better Approach to Bimodal IT

I first encountered the ideas behind Bimodal IT about two years before Gartner coined the term. I was doing a speaking tour of CIO roundtables in the US and Europe. While chatting with the attendees over lunch before my talks, I repeatedly heard the words “core” and edge”. Core referred to legacy, system-of-record systems, while Edge referred to greenfield, system-of-engagement systems. The attendees were unanimous in their belief that core and edge could and should be treated separately. What fascinated me was their reasoning.

When the CIO’s talked about the need to separate core from edge, they didn’t talk about differing requirements, such as reliability or compliance vs. experimentation and speed. Instead, their voices and the looks in their eyes communicated pure fear. They didn’t want to apply agile techniques to their core systems, or move them to the cloud, because they were afraid to touch them. They knew their legacy systems were old, and ossified, and hadn’t been touched in any significant way in years. They assumed, probably rightly, that trying to change those systems more than was absolutely necessary would cause them fall apart before their eyes.

In addition to fear, the CIO’s were also motivated by hope: the hope that separating edge systems out would let them get away with not touching their core systems. Among the many critiques of Bimodal IT, though, one of the most important is the fact that systems of engagement and systems of record interact with each other ever more strongly. As software eats more of the world, and as IT becomes more central to our businesses and our lives, the attempt to keep inner and outer separate becomes more and more futile, as does the hope that one can move significantly more slowly than the other.

While I question the validity of the principles underlying Bimodal IT, I do believe we have a bimodal problem. The fear in the eyes of the CIO’s I met is accurate. If we are to move our businesses forward, we have to figure out how to address this fear. To that end, I propose changing our approach to so-called Mode 1 systems. Instead of figuring out how to avoid the need to change them frequently, we need to figure out how to make them easier to change. In some cases that will mean rewriting a system from scratch, or replacing it with a SaaS solution. In other cases it will mean selectively applying Mode 2 techniques such as automated deployment and regression testing. In all cases it will require experimentation, courage, and incrementality. Given that we don’t know how our legacy systems will break, we have to start by finding out.

Part of the logic behind Bimodal IT involves implementing separate mindsets. Critics of Bimodal IT have pointed out the cultural dangers in such an approach. Given the need to transform Mode 1 into a “changeability” strategy, though, and the importance of a learning-centered attitude to that strategy, it seems to me that a common mindset across both modes is the most critical cultural aspect we need to imbue into IT. The difference between them thus becomes more subtle. While Mode 2 focuses on “making changeable things”, Mode 1 adopts a compatible focus on “making our things changeable”.