Plutora Blog - Release Management
Release Managers are the Heroes of Bimodal ITReading time 7 minutes
Gartner has put a name on a common experience across all industries – IT departments often support two different approaches to IT. One side is focused on agility and rapid time to market while the other is focused on stability and traditional service management. With Bimodal IT you have one department operating in two modes: “Traditional” IT alongside “Exploratory” IT. Gartner calls this Bimodal IT.
Release managers have understood this aspect of IT for some time. We sit at the intersection of these two approaches when software from various projects is integrated together and transitioned from development to production. Some projects require the meticulous application of process to meet a monthly deadline while other projects are throwing code into production twice a day. There’s a wide spectrum of IT project types, but with Bimodal IT you put projects into two buckets: traditional and exploratory.
In our previous analysis we’ve talked about development having different motivations and goals as operations, but in larger organizations it is true that there are increasingly two or more approaches to IT within one department. There is a different set of rules for that new website redesign vs. the installation of a new order processing database for a bank. Different teams working on projects require different levels of change control and a completely different approach to releases.
Release managers face some of their most challenging problems when these two worlds collide – when one of your exploratory projects needs to interact with a traditional project it is often the release manager who is responsible for translating between these two, often incompatible approaches to IT. That’s why we created Plutora, a tool that acknowledges the multiple realities inside most large IT departments. What release managers are looking for isn’t a single process to manage everything. They are looking for a tool that can adapt to different styles of IT project management across projects within the same release.
Bimodal IT: Don’t Cross the Streams
If an enterprise release is properly managed then these two modes of IT will rarely interact. If, on the other hand, an organization isn’t disciplined about process and planning a release manager is often responsible for acting as a translator between teams focused on stability and teams focused on innovation and rapid delivery. These teams speak two entirely different languages.
If boundaries between the Traditional and Exploratory sides of the IT department are well defined then a release manager’s job is easy. For example, if an agile team writing a slick, well-designed web application needs to interact with a backend system they can do so through a well-defined API or a protocol. For example, most web applications interact with a database through a database driver and if a system is relatively mature then schema changes might be few and far between. In this situation, a release process can assume an almost complete disconnect between “Traditional” and “Exploratory.”
If, on the other hand, management has added a frequent release dependency between the exploratory web-development team and the traditional database team, this is when a release process can be delayed by risks introduced by bridging this bimodal divide. Your exploratory teams will be constantly blocked by the requirements of your traditional teams.
These problems arise because systems designed with an emphasis on stability are rarely the same systems that can support agile delivery. Stable, “Traditional” systems are subject to heavyweight process and change control for a reason – they are often fueling the core of a large business. Innovative, “Exploratory” systems are often developed by small teams as a POC that isn’t subject to rigorous process. This POC graduates to production and most organizations opt to preserve the agility demonstrated during development. They can release once a day, or even more frequently, because they don’t present the same risk profile to the organization.
So, how do you manage both within the same IT organization? Bimodal IT.
Keys to Bimodal IT Success
Here are some tips to help manage the differences between projects in an IT department that has gone Bimodal.
Make Projects Choose a Side – If you practice Bimodal IT you will need to create a central list of projects and initiatives and relate them to one side. Your web site redesign will likely be exploratory while your backend systems might be traditional. Don’t just classify projects in IT, classify IT functions and how they are aligned to support both sides. How does your change management team support traditional projects vs. exploratory projects and does one side call for changes to policy and approach?
If you don’t classify projects and you don’t adapt your systems to support both sides differently you are creating untenable conflicts for projects and throwing your application teams at a minefield of confusing and contradictory assumptions. (Does this project require change control? Which side is it on?)
Take Care with Your Dependencies – Make sure that all of your cross-project dependencies are intentional and don’t just wander into a complex network diagram of cross-departmental dependencies. If you’ve assigned projects to the Exploratory and Traditional buckets and you’ve identified a project that depends on another across this boundary make sure that you understand the exact nature of the dependency.
If you are not careful with this boundary then you are going to introduce obstacles into your release process. If your mostly exploratory projects have a single problematic dependency on a traditional project then you’ll be forcing teams to wait for the very process you were trying to avoid with Bimodal IT.
Mind the Gap – In a Bimodal IT department there are two sides. There are projects and functions that are designed to support a more traditional approach (rigorous change control) then there are other functions designed to support exploration (continuous delivery.) You’ll want to make sure that projects don’t get to pick and choose between these two modes depending on what is expedient at the moment.
If you follow an ala-carte approach to IT infrastructure it makes it more difficult to apply patterns during your release process. For example, if a project falls under a more traditional approach to management then allowing it to hook into the continuous deployment pipelines used by exploratory projects will create confusing exceptions. Projects in your CDI pipeline will be designed to deploy frequently, but that one, exception needs to be run through rigorous change control before you can deploy.
Part of the promise of Bimodal IT is that it simplifies the challenge. Instead of dealing with a thousand shades of DevOps, you have projects that are compatible with agile approaches and projects that are not. If bimodal is the model you follow – mind the gap.
The Future Direction of Bimodal IT? We’re betting on Agile.
The idea of Bimodal IT is one that captures the current moment in the industry. Companies are moving toward a more agile, more DevOps-friendly approach to releasing software. At the same time, there is an undeniable reality that portions of the IT department are still supporting slow-moving, waterfall-based applications that demand strict process. Bimodal is today’s reality.
When looking at longer-term trends, it will be challenging for CIOs to embrace Bimodal IT as more and more projects in IT move toward agility the “Traditional” half of IT will, over decades become a smaller aspect of IT. Agility is an infectious condition in IT, and even though it might seem impractical for legacy systems to embrace more agile approaches to management the market will find a way to make even the most risk-averse legacy system more agile. Bimodal IT is a good bet for the next 10 years, but as systems continue to accelerate we predict a more agile future using systems such as Plutora to manage complexity and mitigate release risk.