The rate of business change is just breathtaking these days. IT cannot be the bottleneck that prevents business from looking for opportunities and seizing them. But businesses are rightly concerned about making changes to software that’s working fine. If they don’t have a crisp, accurate way of deploying application software changes into production, then they are going to lose their competitive edge.

In the old days, Release Management was about preventing change. Today, it’s about enabling change.

It doesn’t matter how much time you spend developing the application. It doesn’t matter how rigorously you test an application change. Nothing changes the business until you release that code into production – and then that change is a very big deal. Because if you don’t do it right, you can disrupt the business.  Today, businesses have very narrow windows for making application changes. So, it’s absolutely essential to do it right.

An effective Release Management strategy will improve Release Management efficiency and increase production up-time. It will ensure compliance, and it will improve communication within Release Management processes so there are fewer surprises.

When you can achieve these four things, change can become more of a competitive weapon for the business, instead of a liability.

Effective Release Management can be quite liberating, because it gives you the confidence and competencies to make more changes. For this reason, it’s a great complement to Agile development.  You can confidently deliver code changes every three to four weeks instead of every 6 or 10 or 12 months. You can get the business what it needs when it needs it – not weeks or months too late. And all while ensuring business continuity.

Over the last 30 years, I have worked with hundreds of customers on improving their change management. I’ve seen their pain in releasing code into production. I recognized that Release Management wasn’t a tools problem but a process problem.

Most organizations have automated pieces of the process, but those pieces are disconnected. There’s poor communication between people, and there’s no central place to go for information about the status of releases. When releases have problems, it takes far too long to track back to get to the root cause. Everything takes too long, and exposes the business to too much risk.

So we have to build our release management solution on a process-first, tools-second philosophy. We build a Release Management system that connects and automates the entire process.  The process then drives the right tools by remote control, under the covers. Because everything is connected, the system provides a single source of truth about releases – a place where everyone involved can go to see exactly what’s happening, right from their Web browsers.

It continues with an end-to-end framework, which is the heart of a software solution to Release Management. The framework connects automated Release Management activities across departmental boundaries, geographies, development methodologies and computing platforms, both mainframe and distributed. It connects all the processes involved, from RFCs through deployment. It provides that all-important top-down view, while leaving key data in their source systems.

With automated policies and a framework in place, you can do things that vastly accelerate and strengthen Release Management.

For example, you can have a centralized, automated approvals mechanism for releases. You can have automated alerts and notifications, so that all participants in a release – including business application owners – are automatically notified of critical milestones.  No more wasteful, all-hands-on-deck meetings.

When all Release Management information is available in a central repository, you can have a centralized, enterprise release calendar.  You can be much more strategic in scheduling, monitoring, and re-prioritizing releases, based on what’s happening in the business.

The we can look at new kinds of analytic tools that can help you continually analyze the effectiveness of Release Management. You will be able to ask – and answer – such questions as “What percentage of releases are successfully installed the first time?” “How is the number of failed releases trending?” or “How many unauthorized changes were deployed into production?”

In the future we need to look at how Release Management information can be driven directly into the CMDB in the data center.  This will open up a wave of new opportunity to accelerate business change.