Bimodal IT theory
A few years ago, research organization Gartner came up with this concept called Bimodal IT theory. This basically said that for any large organisations, there are two types of IT systems. These types serve different purposes, are built with different technologies, serve different customers, have different cost and risk profiles, and should be kept separate. And the way we manage and work on them is completely different.
Gartner called these two types “Systems of Record” and “Systems of Engagement”. I am going to explain what they really mean by this, then I’m going to argue why I think they are full of shit. Then I am going to explain how smart organizations should be dividing up their IT systems.
What does Bimodal IT Theory mean?
Gartner came up with a model where you divide a big company’s IT systems into two Systems of Record and Systems of Engagement.
Systems of Record are basically where the data all lives, and it’s usually in big old scary mainframes running big old scary mainframe software. And it hasn’t change much and people don’t change it much and that’s the way it is. And it’s looked after by a big old scary mainframe team full of big old scary mainframe guys and they don’t like to be bothered and they don’t like anyone coming around and even looking at their systems, let alone touching them.
Systems of Engagement are basically what people call “channels”, i.e. systems that anyone (mainly customers, but sometimes staff too) use to interact with the company, usually by means of reading data from and/or writing data to the systems of engagement. And these are of course small shiny new cool systems running Node and Docker and React and other cool trendy things and looked after by young attractive hipsters in glasses who read Arstechnica and type frantically on Mac laptops and “push shit to prod all the time man, hells yeah” and so on. And they are all about Agile and DevOps and Continuous Integration / Continuous Delivery and all the latest fads and practices.
Two-speed model
So Gartner have basically characterised these systems as:
- old versus new
- back-end versus front-end
- Slow/infrequent change versus fast/frequent change.
They are basically saying, you crazy kids can go and have fun and your Agile thing and your DevOps whatsamacallit and your Lean thingamagoo, but don’t go anywhere NEAR that old clunky system back there covered in cobwebs. Those cobwebs have been there since Dicky Nixon was the president, so don’t touch! Or else!
This is a total copout. This model is bullshit. I think it’s bullshit, Jez Humble thinks it’s bullshit, and he’s a smart guy who wrote this amazing book, Rob England (kind of) thinks it’s bullshit and he’s written a bunch of books, so probably knows what he’s talking about. Let’s pull this apart and see what the problem is.
Why this model is a problem
This model has big problems, for three reasons:
- cultural / organizational
- delivery
- technological.
Cultural / organizational reasons
This model divides an organization into two big chunks, the old stuff and the new stuff. And it divides it horizontally, which is plain wrong. This is the problem of the old Waterfall days when you had “component” teams. The database team, the front-end team, the back-end team, and so on. And the teams didn’t talk to each other much. So you had lots of handovers, approvals, bottlenecks and the like. Basically, Bimodal IT theory says we should organise our teams like this:
Instead of how I think we should do it, which is like this (i.e. cross-functional teams):
Delivery reasons
This model causes problems for an IT delivery chain also. If you have a team that is working on one of these “systems of engagement”, you have a potential problem. You might be doing Agile, maybe Scrum. You’re working in two week sprints, looking to deliver at the end of each sprint. You have implemented DevOps, own your channel in all environments, and have automated infrastructure and configuration. That’s all great. But your channel is dependent on those Systems of Record. And it’s possible (actually it’s quite likely) that you won’t be able to make meaningful changes in your channel without some corresponding changes in your Systems of Record.
Remember, this is a “two speed” model. The people running the Systems of Record might only be on, say, a three month release cycle. Not very agile. And they probably don’t care that you want to push out to production every two weeks. “That’s too often! Too much risk! Too much change! Everything might break!” they will probably say. So now you’re stuck on their release schedule – every three months.
This is the Theory of Constraints in action. It’s important to remember it well. A chain is only as strong as its weakest link. A team is only as strong as its weakest member. And an information system is only as agile as its least agile component.
Technological reasons
This model is also a problem for technological reasons. The smartest companies in the world are moving away from big monolothic applications to small, fine-grained microservices. All the cool kids are doing it. This means that not only do you not want do this bad bimodal thing:
You actually want to go further. You want to not only divide it vertically by function / domain (rather than by layer or component, like in the bimodal model), you want to make those vertical domains as small as possible. So more like this:
This is a model very far removed from the big fat old monolithic model of Bimodal IT theory. Microservices were created specifically to avoid many of the horrors of the big old nasty Systems of Record: long build and release times, dependencies all over the place, difficulty to rapidly scale on demand, fragility of design.
Who is this a problem for?
Bimodal IT theory is generally used in the context of traditional enterprises, not newer tech companies. That is, they are usually talking about big old companies like banks or airlines that have built up big enterprise IT systems over the last 50 years. It generally doesn’t apply to small startups (who don’t have big clunky enterprise Systems of Record), or big super powerful tech companies like Google, Amazon or Facebook. Those guys have their shit together, right? And don’t suffer from these problems, right?
Look at what Amazon is doing
Amazon have their shit together. They have decomposed their entire colossal set of systems into discrete fine-grained services that can be consumed internally (by parts of Amazon) or externally (to customers via Amazon Web Services). They do DevOps at terrifying scale. And they perform roughly 20,000 releases to production every DAY. They have a datastore that puts most big old clunky ERP systems to shame, but they move faster than anyone else in the world. And that is because this model is based on a fallacy.
The fallacy of speed versus safety
Bimodal IT theory is based on a fallacy: if you move slowly, you will have safety and minimise risk. And the converse (which is even more false), if you move quickly, you will lose safety and introduce risk. This is crap. Amazon performs 12,000 production releases every day, and they have one of the best track records of safety and stability on the planet. That is because Amazon have completely rejected the Bimodal IT theory.
They started off with a big clunky enterprise System of Record, and it started getting bloated and horrible and was brittle and slowing them down. So instead of living with this and dragging their whole operation into the mud, they smashed it into thousands of pieces, implemented DevOps and Continuous Delivery, and built probably the best IT infrastructure on the planet.
If it hurts, do it more
As they say in Continuous Delivery, “if it hurts, do it more”. You can get safety at speed if you engineer your entire system (infrastructure, code, process, people, configuration, everything) to operate with safety at speed. If you tell yourself you will be releasing 12,000 times a day, you will find a way to make that work. It is a challenge and a big investment but it is possible to do. The big smart tech companies are doing it. Old dumb enterprises are not doing it, and it is going to doom them to a slow, horrible death. They do not see IT as a crucial part of their business, so they refuse to make the necessary investments in it. And stupid models like this from Gartner are making the situation worse, by telling these dumb CIOs that they are doing the right thing.
Is Bimodal IT Theory a description or a prescription?
If the Bimodal IT Theory was a description, then it would be fine. It would be describing a problem that exists for many big companies. A problem that executives need to solve. But it is not; it is a prescription. It is telling CIOs and CTOs and CEOs that what they are doing is fine; that they can keep doing IT like it is the 1990s. But it’s not. Their position is being disrupted and attacked by both small, nimble startups like Air BnB, and by big new scary behemoths like Amazon.
Bimodal IT theory is a pleasant lie, a sedative that tells executives that it is ok to fall asleep at the wheel and leave their old systems the way they are. Nothing could be further from the truth.
