Over a million developers have joined DZone.

Bimodal IT: Incorporating Traditional IT While Applying Agility

DZone's Guide to

Bimodal IT: Incorporating Traditional IT While Applying Agility

Can bimodal IT really incorporate both traditional and cutting-edge IT practices?

· DevOps Zone ·
Free Resource

DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.

In the first part of this article, we outlined a definition of, and purpose for, bimodal IT, a concept pioneered by research firm Gartner to describe the challenges facing many enterprise IT departments in the 2010s. Basically, many organizations face the challenge of building what developer Jez Humble has called "systems of engagement" — i.e., web and mobile apps and services that are updated rapidly in accordance with agile methodologies and DevOps automation tools — while still maintaining their "systems of record," such as the databases that contain account information including contact details, transactions, etc.

Can Bimodal IT Really Incorporate Both Traditional and Cutting-Edge IT Practices?

Under the bimodal IT framework, the idea is to maintain two parallel tracks for tackling these two very different types of systems. Whereas systems of engagement (also called "Mode 2" to conform with the "bimodal IT" lingo) are best served by agile practices, systems of record (also known as "Mode 1") are supposed to be ideal for traditional waterfall testing approaches to the application lifecycle. Does this bifurcation of the IT department really work in practice, though?

It is not clear whether it does or not. Bimodal IT may not be a realistic route for many enterprises, especially ones that have even their Mode 2 efforts (e.g., their new mobile banking tools) tethered tightly to their Mode 1 systems. For example, building an app that checks a bank account balance would likely require connecting to age-old databases and files, built on technology decades older than anything used in the creation of the app itself.

Another way to think of it: Even an agile app built with tools such as Puppet, Docker, and a modern enterprise test management solution may have to be constructed with the severe limitations of a 1980s-era COBOL program in mind. In this way, the agile aspects of the Mode 2 application are essentially wasted on having to wait around on older systems to be maintained and evolved - a costly and risky process. The blurring of the lines between Mode 1 and Mode 2 has prompted many in the tech industry to question the accuracy of the bimodal IT model.

"Gartner's model rests on a false assumption that is still pervasive in our industry: That we must trade off responsiveness against reliability," Humble wrote in a blog for Continuous Delivery. "The conventional wisdom is that if we make changes to our products and services faster and more frequently, we will reduce their stability, increase our costs, and compromise on quality. This assumption is wrong."

What is the Alternative to Bimodal IT?

One obvious flaw in the bimodal IT concept is the implication that Mode 1 and Mode 2 applications are each in neatly contained silos. Would it be possible to turn one into the other? It seems like it should be.

A legacy Mode 1 application in theory should be transformable into a nimble Mode 2 offering, while a cutting-edge Mode 2 solution should be able to be stabilized as a long-term backend service. Giant companies such as Amazon, Google and Facebook — to name three of the most successful firms of the internet era — have proven that it is possible to construct enormous systems of record and engagement on short timetables and then institute them as the cornerstones of their worldwide operations.

Granted, the typical enterprise does not have access to the same level of resources as any of these companies. But it may still be able to move beyond the simplifications of bimodal IT by changing its culture and upgrading its tools:

  • The DevOps movement is a good place to start. DevOps is built on the idea of collaboration between all parts of a business and the busting of "silos," or isolated groups such as the discrete development and operations teams that are assumed under the usual waterfall model. DevOps also prioritizes the idea of automation of tasks such as infrastructure requests and some forms of testing, which can be sped along with the help of a test automation platform.
  • Other corresponding DevOps tools such as Docker (a containerization solution that removes some of the overhead associated with virtual machines), Puppet and Chef, among others, have become increasingly popular in recent years as more enterprises shift toward the Mode 2 world described by bimodal IT, in many cases leaving behind the Mode 1 past altogether. Technical solutions can complement the cultural practices of DevOps and transform the entire organization.

The result of a move toward DevOps might be a more agile organization overall, one that can upgrade its legacy systems over a sustainable timeline while also stabilizing its newer innovations. Enterprise test management tools are essential resources in keeping up the pace of development and ensuring that application lifecycles are sufficient for DevOps.

Read the 4-part DevOps testing eBook to learn how to detect problems earlier in your DevOps testing processes.

gartner ,management ,enterprise ,nimble ,testing ,developer ,research

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}