Plutora is the necessary "Air Traffic Control" for an increasingly Agile Enterprise

By Dalibor Siroky

I keep coming back to this analogy because it's the most apt description of what Plutora provides for the Enterprise.

We provide the software that you need to manage a busy release schedule.  Without Plutora you are forced to use manual methods to orchestrate releases and manage resources, and the analogy that connects with most of our customers is that Plutora is the necessary "Air Traffic Control" for an increasingly agile enterprise.

The two disciplines are very similar both deal with a delicate transition between two states.  Air Traffic Controllers deal with the transition being in-flight and on the ground, and Release Managers deal with the transition between in-development and running on production.  Both disciplines involve a highly orchestrated sequence of operations to minimize risk and manage these transitions, and both jobs involve managing several competing inputs at once.  While an Air Traffic Controller needs to guide 10 airplanes onto a busy runway, a Release Manager has to guide 10 projects onto a busy set of environments.

In terms of risk, both disciplines are also similar. Air Traffic Controllers are responsible for an incalculable amount of risk both in terms of hardware and lives, and Release Managers are responsible for the smooth operation of multi billion-dollar production networks.  In this post I'm developing this analogy to demonstrate that our current, reactive approach to release management is reminiscent of the way we landed planes in 1929 (yes, we landed planes in 1929.)

A Quick Tour through the History of Air Traffic Control:

1920s: Flashlights - Guidance on Landing and Take-off Only

In the 20s airplanes were guided to landing by people holding "flash lights." Planes only received direction when they approached an airport. Terrifying, right?

1930s: Pushing Figurines Around a Map

With the advent of radio communications controllers could now communicate with pilots, but radar had not yet been invented.  Controllers talked to pilots and pushed boat figurines across a map.

1950s: More Planes + Disaster Spurs Installation of Radar

After a disastrous mid-air collision the US Congress created the FAA and funded a real radar system to track planes. More radar coverage allowed controllers to track planes as they made progress toward a destination.

1975: Computerized Flight Plans, "Modern" Air Traffic Control

While technology has improved in four decades the modern approach of filing flight plans and passing planes between regional control centers has remained in place since the mid-70s.

A Quick Tour through the History of Release Management

2000s: Flashlights - Guidance only during a Release

This is the current state for most enterprise release managers.  There is no visibility into project lifecycle until a project shows up as ready to deploy to production.    For many release managers the earliest warning they will get that a project is ready for a release is, "Hey, can we do a production release tonight?"

There are only a few environments available and there is often little room for schedule slippage or error.   If too many projects show up at once, a release manager is in serious trouble. These risks were manageable when there were only a few projects in the landing sequence.

2010s: DevOps - A Collection of Tools, No Transparency

With busier skies, release management has started to take a more proactive approach to tracking projects on a release trajectory, but most release managers are still disconnected from the development groups that drive activity.

Release Managers in this decade are often left with a series of unrealistic release plans spanning entire departments.  It is up to the release and environment management group to pick up the phone and ask projects if they are still on track to delivery software.  While release managers aren't pushing boat figurines across a physical map, we are often updating wholly inaccurate Gantt charts that drive flawed estimates of capacity and over-budgeted hardware spend.

And, that's where the story ends.  When you compare the history of Air Traffic Control to the history of Release Management  you'll realize that we still lack the predictability and control that Radar brought to Air Traffic Controllers.  While most Release Managers will tell you they can predict activity in a week or two, many will express frustration when they try to extend plans further in the future.

Release managers are often just waiting for the next emergency.  The next close call when one business-critical application needs to land on the same environment as another business-critical application and they are asked to perform last-minute miracles to make up for the fact that the modern Enterprise hasn't invested in the necessary tools to track multiple projects as they progress toward a software release.

Most Enterprise Release Managers are Stuck in 1929

Release management is still viewed as process that begins at the end of the software development lifecycle and very few organizations have a release management function that tracks project progress from inception through implementation to delivery.  In many cases, the release manager is standing there, at the end of the runway pointing colored flash lights at approaching planes and while this approach worked in previous decades it doesn't work today.

Software releases are more frequent and involve significantly more risk, and every now and then Release Managers have to avoid colliding initiatives.   It's time to upgrade to a modern release management "Radar,"  and that radar is the Plutora Release Manager.

With Plutora:

• You can connect to all of your project's JIRA issues and track multiple projects as they progress toward a software release.
• You can visualize the conflicts that may arise between project release schedules and reroute projects that are on a collision course for an environment or QA resource.
• You can understand what the current capacity of your team is and quickly identify if critical resources such as QA or release engineering are in danger of burn out.

Just like an ATC controller can call up an airliner in transit and ask them to either speed up or slow down to anticipate traffic jams hours ahead of time, with Plutora your release managers will be able to look far into the future to understand how projects need to adjust to ensure that business initiatives are not blocked for lack of resources.   You can forecast what your IT environment budget will look like months in advance.

When we compare Release Management with Air Traffic Control it's clear that it is time for Release Management to move into the 1950s or even the 1970s.

Would you land at O'Hare if there was just a guy standing on the edge of the runway with a set of flashlights?  If the answer is no then why would you expect your release manager to manually track software releases with spreadsheets during the final phase of software delivery? For many of our customers there's considerably more risk involved in managing an efficient release pipeline.

When you have billion-dollar software initiatives in the air, you should invest in tools that give you the ability to manage the transition from development to production with ease and efficiency.