Bimodal IT is not the goal

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

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.

bimodalIT

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!

7 Comments

  • 1
    Tonyjoyce
    2016-10-21 - 15:48 | Permalink

    Interesting and concise observations of a common systems problem. what you describe is the subversion of front office / back office business functions to a heavily governed technology architecture. The clients have lost track of who does what work, not surprising with the rapid pace of changes engendered by new expectations of digital savvy customers.

  • 3
    Björn
    2016-11-02 - 08:18 | Permalink

    Thanks for sharing your thoughts. Do you also have an idea of how this envisioned end goal could be accomplished in environments where mode 1 is not only self enforced, but equally a product of extensive government regulations? Example: in the health care sector, systems that manage patient data (electronic health care record systems for instance) are regulated enough (CE certification and such) that innovation is stifled. Today in Sweden, 18 months from idea to implementation is considered an extremely fast timeline. I could theoretically see this be cut to maybe 6 months, but less than that is pretty much made impossible by outside factors.

    • 4
      2016-11-08 - 14:35 | Permalink

      Hi Björn,

      I have some experience with the health care sector, having been a CTO in a start-up in that area. So I know that the regulated sectors are tough, mainly because the regulations are not up to date with the technical progress that’s constantly being made.

      What you can do is to try to be as agile as possible. Just because regulations says you can’t deploy as often as you want, doesn’t stop you from building your product iteratively and incrementally. You can still deploy every two weeks to an internal stage environment for instance.
      You could also build your system with a flexible architecture with a high degree of automated testing. You don’t havet o build a monolith just because you can’t deploy more often than every 6 months.

  • 5
    Vinaya Muralidharan
    2016-12-12 - 08:42 | Permalink

    Thanks for sharing your thoughts.
    About the last section – Bimodal IT being seen as a sane approach to managing the tsunami of change – i would pick, and highly recommend, a Kanban approach to change instead – start where you are and make small evolutionary changes. From my limited understanding of Bimodal IT, it seems to encourage silos and local optima and loses the big system view.
    I would love to hear what you think about this.

    Regards,
    Vinaya

    • 6
      2016-12-15 - 19:04 | Permalink

      Exactly my point, so I agree fully. I only said that Bimodal IT can be one way of getting started. It is better at handling external change than a classical waterfall approach. But it is not the best, hence why it shouldn’t be where you end up.

      • 7
        Vinaya Muralidharan
        2016-12-17 - 03:02 | Permalink

        Thanks Mikael!

  • Leave a Reply

    Your email address will not be published. Required fields are marked *