The Bimodal misconception, why Gartner has to realize the ignorance of its customers

Okay, first of all, I'm talking about Gartner's Bimodal IT thing here which is defined by them, that is Gartner as follows: "Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration.", which is taken from here. And it makes no sense, because Gartner omitted to mention that this is an application architecture thing.

The problem I have with Gartner's definition of Bimodal IT is that it implies rather explicitly that predictability and exploration don't go together, which is of course totally correct. You explore because you can't predict. But the reason why Bimodal IT was introduced is because we face a stand-off between waterfall and agile, between Silo'd IT and DevOps, between client/server and service oriented systems, between legacy and the new world.

Reading the rest of Gartner's definition (Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability.) you understand the flaw in their reasoning. The flaw is in that the definition assumes that an organization can be divided in two ways of addressing its business, or rather that it can adopt a way of working in that it addresses its business simultaneously in a 'we know what the customer wants' and a 'we want to know what a customer wants' way of working. Which is bogus, of course. Totally bogus.

At one of my current clients, Bimodal IT is a hot topic. Here it is used such that the back-end systems are considered Mode 1 systems and the front-end systems are considered Mode 2 systems. Furthermore, the epic mistake is made to consider everything running in the cloud to be a front-end system and everything in the on-premise environment, which is a traditional data-centre, to be a back-end system. Makes no sense to me, and I can guarantee that within the next 6 months there will be back-end systems running in the cloud.

To understand Bimodal IT, we need to understand why the term was coined. Basically, you need to re-read the definition and understand what is being said. You need to put it in the context of time, and address it from an architectural perspective. Because that is what Bimodal IT is, well that is its raison d'etre.

So, let's start with 'one focused on predictability' and forget about this. It's an ambiguous term. Ambiguous because for one we want our software delivery cycle to be predictable, we want the quality of our solutions to be predictable and we want the costs of our solutions to be predictable. At all times, no difference between front-end and back-end, no difference between cloud and data centre and no difference between old and new. At the same time, we can't predict what the best feature set of our solution is. We can't ever predict it, no difference between fron
t-end and back-end, no difference between cloud and data centre and no difference between old and new.
So predictability only applies to our solution delivery process and not to our solution.
And then there's 'the other on exploration' which we should forget as well. It's an ambiguous term as well. It's ambiguous because we need to always explore to find the right feature set for our solution. This is because we can't predict the right set. It has nothing to do with where we're hosting, whether it's front-end or back-end or anything else.
So Bimodal IT by Gartner's definition makes no sense, because from the outset it's wrong.

But here's the catch, at the time Gartner coined the term, it made perfect sense. It's just that Gartner forgot to mention that Bimodal IT actually hinges on application architecture.

Back to this customer. Bimodal IT is used as an excuse not to comply with the ancient and really seriously out dated processes in IT that are (to be) followed within this organization and I assume unwillingness to try to modernise the processes. By just simply referring to Gartner and their definition of Bimodal IT and stating that this is the exact situation at their organisation, some of my clients architects and project managers are implying that the processes only apply to what's running in the back-end and what they're working on, which is the front-end.(*)

Let's see why thinking in terms of Bimodal IT is making sense. It makes sense because at the time Gartner coined the term, we developed our systems predominantly being Waterfally and the hipsters were being Agile. There was nothing exploratory about it, and read the Agile manifest and it says nothing about exploration, but the more about predictability.
Mode 1 and 2 are all about delivery cycles. Mode 1 is long, Mode 2 is short. One could say Mode 1 is about being ignorant and Mode 2 about being smart.

So, ignorant vs smart, what's that about?

Well, in Mode 1, we tend to think that it makes sense to first define the complete solution, design it and build it before we deliver it to our users. And because for some reason, release into production always results into (often major) headaches, we also tend to think it makes sense to not release that often, so we limit the occurrences of headaches. Hey, if you only bang your head against a wall twice a year, you only run the risk to crack your skull twice a year. So makes perfect sense, doesn't it?
Then there's Mode 2, where we think that is makes sense to just grab the most important, or valuable features and develop these and take them to our users, and then do it again with the next most valuable solutions and put them out to our users. And we tend to think that because we only release a tiny thingy, it's very unlikely that it'll go wrong and will only cause (if at all) a dull feeling in the back of our head. Hey, if you nudge your head against a wall every few days, at the most you know that the wall is still there, but that's about all to be felt.

So Bimodal IT is where one group of people thinks that doing something really hard is less risky when you make it even more complex but do it fewer times and the other group of people thinks quite the opposite, that doing something really hard is less risky when you simplify it and do it more often. Kind of practice makes perfect.

And yes, years ago when Gartner came up with Bimodal IT, we really had this Mode 1 and Mode 2 division as described above. But in this day and age, the Mode 1 people are a rare breed. Mind that we're discussing this in an era where major banks (ING) are firing pretty much everybody that is Mode 1, where major airlines (KLM) are spending millions of €'s to transform in to a full Mode 2 organisation and where it's hip to be Mode 2 at IT departments of local and national governments.

But Bimodal IT is there to stay for a while. Not because of predictability, nor because of exploration. Not even because of Waterfallians (Mode 1 people). Nope, it's because of Monoliths. Those ancient systems that were delivered in a day and age when we thought Client/Server was awesome and everything should be consolidated into one system so we could guarantee data consistency and we could really vouch for abiding to the DRY principle (Don't Repeat Yourself).

These systems can't be changed, they are architected to be unchangeable. We don't want them to be that way, but they are. It's because our application architectures of a couple of years ago resulted in unchangeable systems, we can only change them by changing the complete system. The monoliths are preventing us from becoming post-Bimodal IT organisations.

Back to the misconception. Bimodal IT is something that has to do with the monoliths in our IT landscape and nothing with how we perceive our IT or the systems in our IT landscape. The misconception is that we need to adopt a Bimodal IT approach to how we do IT because we don't have to. We have to get rid of the monoliths and we need to start by isolating them behind a layer of changeable software. Hide them like a skeleton in a closet of services.

By adopting Bimodal IT today, or continue with Bimodal IT today, means you either have a totally wrong understanding about how to manage your IT department, or you are still in the previous millennium when it comes to IT architecture, or you're just using Gartner's reputation as an excuse for not having to modernise your IT processes.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link to my blog to all your Whatsapp friends and everybody in your contactlist.
But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Iwan


Although this post is my personal opinion, there're quite a few articles to be found on the internet about this topic that I've read. So here're some interesting reads:

- Gartner Glossary: Bimodal IT
- Gartner's bimodal IT mistake: DevOps can deliver velocity and quality
- Bimodal IT: Gartner's Recipe For Disaster
- Beware the Dangers of Bimodal IT
- Gartner’s Evolution of Bimodal IT
- The Flaw at the Heart of Bimodal IT




*: Interestingly enough, they forget to mention that the back-end is running on-premise and they're in the cloud and yes, the front-ends hosted on-premise are just as much under the same regime as the back-ends.