The theory of constraints says the true measure of a chain’s strength is found in its weakest link. This is a given, whether you interpret it as a management philosophy or an all-purpose notion, and serves as a great analogy for looking at complex systems. But those who propose Bimodal IT seem to have ignored the reality of the weakest link.
The Fast and Slow of Bimodal IT
Bimodal IT is the belief you can be successful dividing IT into two groups, which I’ll call “fast” and “slow.”
The fast group is structured to respond quickly to business needs. It often features a DevOps and Continuous Delivery culture. When the business needs something, these groups are equipped to quickly respond.
But then there’s the slow group. It’s usually where the mainframe—its applications, data, and staff—resides. The idea is these are complex legacy systems that are highly reliable, but older and difficult to change. The release cycles could be yearly, quarterly, monthly, at best twice a month. This pace doesn’t mesh with the “fast” group. Things continue with occasional required maintenance, but with no serious new development or innovation.
How Bimodal IT Thwarts Great Ideas
Do you see the problem with Bimodal IT’s fast-versus-slow concept yet? Let me illustrate with an example.
Let’s say someone in your organization has a great idea. It’s something that would put you ahead of your competition, but you need to move fast.
The fast group analyzes the idea, agrees it’s good and prepares to respond. Since they use the Agile development methodology, they can put some of the analysis and estimation into current two-week sprints and prepare to move the new tasks ahead of others in upcoming sprints.
But the fast group finds out they’ll need access to data and applications on the mainframe. Since the majority of data still resides on the mainframe and the core applications as well, this isn’t unusual. But to push the idea out into the market quickly, the fast group doesn’t just need the right data—they need it now! Unfortunately, that’s not going to happen.
The fast group determines it will have to work into the existing slow Waterfall process, where priorities have already been set. The fast group will have to fit into the next open slot. Even with a monthly cycle there will be a delay for analysis. Once the analysis is done, there will have to be negotiations for fitting the code into the next development cycle.
Bimodal IT Welcomes the Weakest Link
These cycles don’t mesh. There will be a waiting time, a great lag that delays the idea.
The fast group could slow down to meet that languid pace, but instead they’re more likely to attempt to speed around the slow group. They may try to get direct access to the data and code their own logic to suit their needs. This adds time with duplicate logic and unnecessary complexity.
Thanks to Bimodal IT, your competition-trouncing idea is being slowed down by the weakest link.
Does it need to be this way? Why do you, why would you, want any part of your IT organization to be deliberately and acceptably slow? Why can’t everyone be in the “fast” group?
The answer lies in bringing the same techniques and many of the same tools that have had success making you fast on one side over to the slow side. Bringing the concepts of Agile, DevOps and Continuous Delivery to the mainframe is beyond possible—it’s happening here.
By eliminating the weakest link created by Bimodal IT, you will have a much stronger delivery chain. I recommend reading this white paper and blog series if you want to learn just how possible this is
Photo: Flickr: Hernán Piñera