In 2014 Gartner introduced bimodal IT. Since then quite a lot has been written and said about it. And just recently it popped up at two different clients almost simultaneously. After reading articles, watching webinars and listening to what people say about it, I’m a bit worried that organizations think Bimodal IT is the goal. I don’t think so, and I’ll explain why.
According to Gartner, bimodal IT is a way of “…managing two separate but coherent styles of work: one focused on predictability; the other on exploration.” What they say is that there is a need for two different modes of IT (hence the name bimodal IT). Mode 1 is focusing on the predictable, stable and existing systems, while mode 2 is the innovating, fast moving, meet-the-demands-of-the-future type of systems.
So what Gartner says is happening, and as far as I can tell also recommends, is dividing the IT organization in two distinct modes. That is, people working with mode 1 systems will behave and work differently from the people running mode 2 type of systems.
This picture below tries to describe how Gartner sees it. The legacy systems (mode 1) that the organization already have contains capabilities, for instance billing, customer relationship, payments, etc. These capabilities should be made accessible through an API, so that the small, fast moving, innovative apps of the future (mode 2) can utilize the existing capabilities.
Looks cool, what’s the problem?
This structure implies that you organize along types of software systems, rather than types of business. Some teams will work with more slow-paced, stable and predictable mode 1 systems, and some teams will work the innovative, ever-changing mode 2 systems.
That kind of organization will foster two different cultures within your company. If mode 2 apps are supposed to be highly iterative and fast moving, what will happen when they need a change in a capability delivered by a mode 1 system? Because that will inevitably happen. The answer almost always is;
“Our next release is in a month, but scope is already locked for that release. Write down your requirements and send them to me, and we’ll see if we can manage next quarter.” And of course that is not good enough, so the teams working with the mode 2 app will add the capability locally. And that is a great start down the slippery slope of duplication, and sooner or later you won’t know which system does what or which data that’s master.
This is not theoretical reasoning. I have seen this exact problem at several clients. One example is the webshop team, who needed a change in the API (more data from backend system), and the response from backend team was, “yeah, our next release is in 2 months”. How fast-moving is the webshop now?
And it could become worse. Those working with innovative mode 2 apps will see their co-workers of mode 1 systems as slow, rigid and stuck in the past, while the ones working with existing capabilities will see their mode 2 co-workers as not thinking things through, always wanting to change and not work as proper engineers do.
Why should only some be innovating?
How come only mode 2 apps need innovating? I would like to think that it is the old legacy systems that needs the most innovation. But the bigger problem is why should only some of your hired brains be innovating? The more brains you engage the better ideas! And not just that. If all can contribute, everybody’s idea is important, then you’ll bring people together, not apart
It can’t all be bad, can it?
The good thing about this is that Gartner says that companies need to handle the “tsunami of change coming their way”, and the way to do it is to be able to react, build and deploy much quicker than a conventional approach can.
And I agree. Change is quicker, technology moves faster, and companies need to understand how to be digitally present. Bimodal IT might be a good way to get these companies started. But staying with bimodal IT and believe that it is organizational nirvana could bring a whole range of new problems. That’s not where I want my clients to end up. I’d like the business side of a company to be able to dictate how fast changes are deployed, not some monolithic architecture from the 90’s. Dare to go further! Bimodal IT is just one way of getting started. Bimodal IT is not the goal!