Bimodal IT: it’s back - but should it be?

For the uninitiated, bimodal IT entails having two separate IT teams working in tandem. In one team (team 1 for the remainder of the article) are a group of people responsible for maintaining the business’ core infrastructure. They will handle things such as software updates and stability using tried and tested methodologies.

But the other team (team 2) is far more maverick. It operates on the cutting edge and takes responsibility for making large numbers of changes, rolling out custom builds through automation and doing anything they can to give the customer what they need, quickly.

The concept has some obvious merits. After all, every business wants to be able to respond to its customers’ needs quickly and effectively. We mentioned at the outset that bimodal IT had recently become more viable and that is largely due to increased adoption of DevOps processes. We’ve previously written at length about how tricky it was for us to adopt fast-paced and relatively unstable DevOps practice in comparison to the precise, steady and secure working practices that had been our stock-in-trade for the previous 20 years. With rapid deployment now par for the course in many organisations, bimodal IT no longer seems quite so scary.

But is it fundamentally flawed? In the past, bimodal IT structures would always fall down because of the very nature of its setup: creating two distinct camps to deal with issues that are nowhere near as separate as that model suggests and are actually inexorably entwined. For example, it is unlikely to be too long before a change rolled out quickly by team 2 to meet customer demand starts to impact on team 1’s ability to maintain and support the core infrastructure. Equally, team 2’s bleeding edge work is likely to be undermined by a stable back-end that will not always scale quickly enough to match their demands. The result is that frustration increases, stability decreases and changes made by team 2 start to create small issues.

Increased comfort with following DevOps practice, coupled with a slight blurring of the lines between the two teams of the traditional bimodal IT vision, means it can be implemented effectively and is making a comeback. Companies like Amazon are leading the charge by making thousands of changes per day, all automated and maintained by their core team.

With the right staff and the correct processes in place, it can be done. Nonetheless, it remains quite easy to hit the sort of snags we discussed above. Even Amazon has found out the hard way that its approach is not infallible. As such, bimodal IT is not yet the right approach for every business and may never be. The risks probably outweigh the rewards unless your organisation desperately needs the sort of agility we’ve discussed. That probably limits the usefulness of bimodal IT to larger enterprise operations. For everyone else, it is probably safer to let bimodal IT pass you by.