Bimodal IT vs. Hybrid IT: What’s the Best Approach?

IT departments have always been an important part of the business. Critical business models rely on systems managed by IT. Businesses have been using IT for years, but IT is now finding a seat at the table and is helping to lead businesses into a new digital era. As the business puts more pressure on IT to deliver, we're having to re-structure our IT departments. One path that has been drawn up is the Gartner Bimodal IT model.

What Is Bimodal IT?

Gartner released their bimodal IT model back in 2014. It was their attempt to help guide enterprises through the new era of digital transformation. Gartner broke down IT into two different styles of work, defined as "The practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on exploration."

1. 1. Mode 1 "focuses on what is known while renovating the legacy environment fit for the digital world."
2. 2. Mode 2 is "exploratory and experimental to areas of uncertainty."

Mode 1 is focused on legacy applications with a focus on strict recordkeeping. When I first read about Mode 1, I thought of mainframes and legacy code base. These technologies are still very important, but traditionally are hard to add new features and functionality.

Mode 2 is focused on new applications and greenfield deployments, which led me to think about mobile applications and web-based apps.

This might have been a good starting point for enterprises to lead their IT departments into the next wave of technologies and into the digital era, but with the rise of DevOps and hybrid IT, there are gaps in the bimodal model. Gartner's model doesn't really talk about culture and the people needed to interact with each other to support these systems. Bimodal IT doubles the processes because you've created two separate pipelines and you're only as fast as your slowest link. Lastly, new technology practices can be applied using a DevOps and Agile development approach.

What Does Bimodal IT Mean for People?

People are a company's greatest asset, and making people choose between Mode 1 and Mode 2, two distinctly different development paths, is not a good idea.

Mode 1 gives people who are less inclined to learn a place to hide, be comfortable, and not innovate in an area that needs it more than ever. It gives people an excuse to not have to learn new methods or a reason for not knowing because they weren't sent to training or to a conference. Natural silos get built up in all departments of a business and management struggles with trying to have different teams communicate with each other. Now we're encouraging these walls to be built up. Mode 1 might be legacy, but it holds a lot of the critical data that needs to be fed into the newer front-end systems maintained by the Mode 2 group. We need to blend these two groups together to encourage better communication because the systems they interact with are linked.

Process for DevOps

DevOps is about combining processes and tools to help an organization deliver quality applications at a high speed. I normally see groups from Mode 2 and operations referenced when talking about DevOps. We get excited about the new shiny toys in IT and lose sight of the existing infrastructure. Not all deployments are greenfield—they’re normally brownfields. There's already a piece of technology or a process we need to incorporate with our new process. It’s the same with DevOps.

We need to include both Modes 1 and 2 under DevOps and use the same model of development for both modes. Both will benefit when the teams can be merged into a single team and the range of skills can be developed instead of limited to a single practice.

The Interaction of Technologies

When I first read about the Gartner Mode 1, it threw me back to when I worked for a manufacturing company that had a fleet of COBOL programmers who administered the IBM Z-series mainframe. These administrators and this system basically ran the entire organization because they contained the most critical data for the business. But rolling out any new change took a lot of effort. Making the system run faster usually required a hardware refresh. It took months of planning to add new features, and there wasn't an easy way to roll out into production. We maintained two separate pipelines of work. We had two distinctly different groups of people with different skillsets. One side didn't really understand the level of effort of the other side.

I don't think companies are looking at releasing multiple versions of code to their legacy systems. Instead, businesses are looking for their legacy systems to be more flexible and agile in nature—to be able to change when the business changes, pivot when the business needs to pivot. We can learn from each other by working closely with each other. Continuous integration and continuous deployment are a key component of DevOps. CI/CD allows for automated testing using technology to track code versions for quick delivery, stable releases, and quality. Instead of allowing one group benefiting from these new technologies, we need to borrow similar tools and apply to all systems so the business can benefit.

Conclusion

The introduction of the public cloud disrupted enterprise businesses and introduced new models to quickly deliver applications. A new management approach was needed to maintain new applications while supporting legacy systems, and Gartner was one of the first to put out a new model. Since then, new approaches to software development and system management have evolved and become the preferred method. Research has shown it's better for different teams to communicate with one another and share ideas instead of building silos. We've learned that it's good to merge teams from the development side as well as the operations team. Now it's time to include the legacy team.