A couple of years ago, people started talking about the notion of “bimodal IT,” sometimes known as “ambidextrous IT.” The formal definition, according to Gartner, is “the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility.”

The idea was that an organization with legacy products would have parallel developments—one for continued enhancement to legacy systems and a second agile one to develop products quickly to take advantage of new technologies. To a certain extent, it’s a way to deal with the issue of Shadow IT, where business organizations set up unapproved parallel IT organizations because they don’t find traditional IT responsive enough.

In fact, bimodal IT even represents the two types of IT organizations, beyond just development, writes Dave Michels in No Jitter. “Mode 1 represents the IT department that we love to hate,” he writes. “It’s the mode that ensures things are reliable and secure. It’s the mode that says ‘no’ to just about every request, usually due to limitations (of staffing, budgets, testing, etc.) or concerns (related to security, support, experience, integration, compatibility, etc.).”

In contrast, “Mode 2 is the innovative and friendly IT,” Michels continues. “Its charter is exploration and responsiveness. In this mode, IT says ‘yes’ to most requests because the request itself is indicative that an unmet need exists. Speed and agility are king, and mode 1 simply can’t respond quickly enough. Mode 2 enables the company to benefit from newer technologies while they are still new.”

Bimodal problems

But the concept of bimodal IT is starting to get some pushback.

The theory behind bimodal is, “Disrupt thyself, before someone else disrupts you.” But that’s the wrong way to look at it, writes Laurence Hart in Word of Pie.

“Going bimodal is an unnatural way to run a team, group, or product,” Hart writes. “Running a more rapid, innovative set of teams alongside separate teams that are essentially keeping the lights just doesn’t work long term in a healthy organization.”

Part of the problem is that dividing IT into two groups creates conflict, writes Bernard Golden in CIO. “It’s likely that these two different IT groups will joust with one another for power,” he warns. “More importantly, despite the neat separation implied by the model, the fact is that they will need to cooperate. Setting up two organizations won’t necessarily resolve the tension, and may, in fact, exacerbate it as the two groups vie for resources and influence.”

Moreover, bimodal IT promotes the same sort of silos that the industry has been trying to get rid of, writes Mark A. Campbell in CIO Insight. “This is the opposite direction of every IT and organizational health trend since the term ‘functional silo syndrome’ was coined by Phil Ensor in 1988,” he writes. “Bimodal IT’s reliance on silos is simply muddle-headed thinking as proven out by countless studies over the past four decades.”

Worst of all, it isn’t clear how bimodal development would work over time. “I’ve seen two party systems in the past that have degenerated into ‘them’ vs ‘us’ and with no consideration of how things evolve they are not sustainable,” writes Simon Wardley in the Gardeviance blog.“There is no effective process for how the new (i.e. tomorrow’s industrialized components) become industrialized. The idea that somehow the two groups will work together in a ‘dance’ is fanciful. Brawl would be more like it.”

Even Gartner, which is one of the big proponents of bimodal IT, notes that it is fraught: While it predicted that 75 percent of enterprises would have a bimodal capability by 2017, it also predicted that half of them would make a mess of it.

Bimodal and beyond

So if bimodal IT doesn’t work, what should companies do instead?

What’s really needed is not bimodal IT, but trimodal IT, Michels writes. “Trimodal IT is the trick to making mode 2 sustainable and successful,” he writes. “IT must recognize the transitioning of new services into stable and scalable solutions as a separate, strategic function. It must assign a distinct group, even by selection of ambassadors from the other two modes, and specifically charter that group to integrate and adapt practices for ensuring operational success.”

Wardley also agrees with the trimodal concept. He postulates three teams: Pioneers, Settlers, and Town Planners. Basically, Pioneers are the innovators, Settlers turn innovations into products (like Michels’ transition team), and Town Planners turn the products into commodities or utilities. “If you want to create a bimodal / dual operating system structure out of this then you really have to give up on one part,” he warns.

And perhaps even trimodal isn’t enough, Campbell writes. “The agility vs. stability postulate is a false dichotomy,” he writes. “Bimodal is too trivial–the real-world is multi-modal. You need as many solution approaches as you have business drivers. It is not as simple as an ‘either-or’ bifurcation.”

Ultimately, bimodal IT can hurt the organization by cutting legacy apps off from technology that could improve them, warns Steven Murray in Computer Business Review. “Companies have decades of high value IP wrapped up in their legacy IT and mainframe applications making it critical for them to become more agile to remain relevant in today’s digital world,” he writes. “Those that don’t adopt a widespread agile approach will miss a major opportunity to fully enrich the customer experience and drive unprecedented value for the business.”

“Everyone in IT should be given the freedom to look into new technologies that might improve either system efficiency or provide possible value to the users,” Hart agrees. “Everyone in IT should be working with the business to learn what the business needs to be more effective.”

Get more information on the top trends affecting today’s workplace – including cloud, mobility and workflow automation – in this exclusive IDC research, “The Future of ECM: Code-Free Integrations and Anywhere Access.”