Bimodal IT, The Talk of The Town
The notorious Bimodal IT heavily promoted by Gartner. It seems like the IT community has divided into two parts: those who haven’t made their mind yet about the bimodal IT concept, and those who ridicule it and “predict” its soon demise. The truth is, however, as always, in the middle.
First, let us take care of the definition of Bimodal IT by Gartner. Instead of turning to the one that is usually cited by publications, let us instead have a look at how Bimodal IT is outlined in research notes.
Bimodal IT organization implicates that IT should adopt two different approaches to handling IT-related work in general, and in particular in relation to business. The focus of the so call Mode 1 is on predictability and stability and should be best used “where requirements are well-understood in advance, and can be identified by a process of analysis”. The other mode, the so called Mode 2, is perceived as “best-suited for areas where an organization cannot make an accurate, detailed, predefined plan because not enough is known about the area”.
In case this definition is still too vague, let me clarify it with hands-on examples. You would find the application of the Mode 1 approach in such projects like, e.g. replacing a bulky ERP mega-suite with a Postmodern ERP, or maybe even breaking down a complex monolithic software into more manageable and better maintainable pieces, be it Self-Contained Systems or Microservices. After all, the requirements and the outcome are typically very clear in such projects. As for the Mode 2, you would find it, for example, in pilot IoT projects, when the overall direction is more or less understood, but the means, requirements and viability are yet unclear and will be revealed only in the course of the project in small pieces.
It seems, however, that this definition of Bimodal IT is almost deliberately misinterpreted by many anti-advocates of this concept as labeling the Mode 1 “boring” and Mode 2 “exciting”, though these words have never been used in research notes. Another misinterpretation is that the Mode 1 is no home for Agile, as it wants to do things as it has always done them and continue to operate unchanged, although it is clearly specified in the research note “Deliver on the Promise of Bimodal” that the concept of agile should be applied to both Modes. In fact, IT leaders are encouraged to “transition their Mode 1 teams from traditional waterfall methods to agile, iterative or incremental delivery methods where possible”.
After perusing numerous articles and discussions on Bimodal IT, I’ve come to the conclusion that people vastly misrepresent and misinterpret the concept of Bimodal IT, likely without having read any of the original research notes. So, I’d like to clarify a few things based on what we have witnessed in the field of innovative IT initiatives.
The Bimodal IT Concept Explained on the Example of Application Integration Projects
In the talks with our clients and those who are still evaluating our hybrid integration platform we have seen that, though IT departments at larger companies are all in for IoT, Mobile, chatbots and such, they are still unclear about what it is they really want. They have pictured the desired final destination, but they have yet a vague understanding of how to get there, what the requirements for such projects and accompanying tools might be, and how the ideal outcome should look like. And this is absolutely fine, because with IoT and Co, IT departments are moving into the unknown territories, with each use case being highly individual and probably hardly duplicable on a horizontal scale.
If you think about digital transformation and disruptive IT initiatives in this light, then it is not hard to see the point that Gartner has been trying to make for over a year by now. And we see this especially in the area of integration projects – naturally, since application and data integration is our area of expertise: There are development teams outside the IT department that are working on custom software applications or corporate chatbots.
There are line of business employees who need to integrate newly acquired applications with existing systems quickly and in fact, do this already, using third-party integration services (just check out reviews on e.g. Zapier on G2Crowd software review platform to see it for yourself). There are ad hoc integrators, who are not specialized in applications and systems integration but are required to do this from time to time within the scope of their own projects, be it development of a custom mobile application or an internal database.
If left in the hands of the central IT departments, such integration projects can take months if not years to be accomplished, which is also understandable as they are not the matter of IT department’s’ primary concern. Yet they need to be carried out quickly, otherwise any digital transformation initiatives would turn into a Fata Morgana.
Hybrid Integration Platform – The Glue That Holds Together Different IT Modes
Now, as we see, while being allocated to different kinds of IT work, both modes will be bound to have to share at least one competence, and that is integration. What used to be the prerogative of the IT department, is now already claimed by the typical representatives of Mode 2 in Bimodal IT terms, namely by the so called citizen and ad hoc integrators (whether central IT likes it or not).
In this light, the wisest thing for central IT to do is to implement a hybrid cloud-based integration platform that will be widely shared across both Modes.
A hybrid integration platform as a service is an integration middleware that connects various cloud and on-premise applications, systems and databases, and can be deployed both in the cloud and on-premise. Typically, a hybrid iPaaS comes with a number of predefined API-based integration connectors for applications as well as standardized tools for building custom connectors. It offers a unified, transparent monitoring system, provides its own API and plays well with existing systems, for example a legacy ESB.
Traditional IT can, thus, produce pieces of code, connectors and even integration solutions for the cloud and on-premise, and share them across all organizations, B2B partners, development teams and line of business employees. At the same time, members of the Mode 2 can perform necessary integrations on their own, in an agile and ad hoc manner without having to steal central IT’s time and efforts away from business-critical projects.
What’s even more important, though, is that an integration platform allows both Modes to work together, supporting the Mode 2 while speeding up the Mode 1. A development team (Mode 2) from the department XY will thus be able, for example, deliver a connector for their custom mobile app on the platform, where central IT (Mode 1) can take it over and connect to certain legacy back-end applications and systems.
With a cloud-based integration platform, CIOs and IT leaders can make sure that it is not “either Mode 1 or Mode 2”, but that in fact, both modes work together, each contributing to each other’s innovation and agility, both supporting digital transformation, and getting out of each other’s way where necessary. Just as a true Bimodal IT organization should look like.
