The types of companies I (used to) work for and (now) consult to, love release management. At least their IT people do.
For those who are not in the know, check out the following 2 resources for a bit of background
To ensure that the cross system (and often) cross department, company or country design, development, test and deploy process, companies introduce Release Management Processes. Different application development projects are collected together, and managed from a central point - who is unimaginatively known as the Release Manager. The release manager usually has responsibility for delivery and deployment of all the changes requried within a system, and across systems for a particular instance of deployment activities (that's a wordy way of saying that a whole load of stuff gets developed, tested, and then deployed together).
So, to recap - early days - applications designed, developed, tested and deployed whenever people want. More mature business - applications designed, developed, tested and deployed under a managed process, with defined implementation dates. In principle, that sounds fine. In fact, it sounds like a sensible way to manage development and deployment. Software can be complex, and complexity grows as you have more systems involved, different parties, different skills, and in some extreme cases, different countries and cultures.
Business users (ie, the people paying for the development, and specifying the functionality) rarely like release management. It's costly. It's slow. It's inflexible. And this is more true if the business users know a little bit about software development, and especially if it involves the web.
The web is known for being an inherently agile environment. Web applications are usually self-contained and loosely coupled, and can be easily and quickly altered. There are other types of applications that exist in enterprises that do not have the same inherent agility. Customer Management Systems, Billing Systems, Banking Systems, ERP systems. All of these systems usually have long lead time on changes, strict testing requirements, are have historically been designed and developed in a different (monolithic) manner to web systems. The requirements on them are often different too - they often aren't about exposing new "services" to the public, but more about internal services, bug fixes, operational fixes, or enhancements to allow new products to be offered. However, they don't interface with the external customer and often aren't driven by the same requirement for agility - it's often easier in business (for your brand, and bottom line) to deploy something that is a bit crappy internally (manual processes, double-keying data etc) if you can get the message out to the customer.
Business users want the ability to alter the messages and functions that are delivered to their customers on their terms - when they want - not bound to some (in their eyes) arbitrary release schedule. They don't understand why their functionality must be deployed with another, completely unrelated, system or process. They want to get their product to market.
I feel strongly that certain types of systems fall nicely in a "release managed" category, and others fall into a "system owner" managed category. (sidenote: I feel that for a platform that supports as much functionality as "the web" that often The System is too coarse a unit for splitting - it could be taken down to business process, journey, or user type). For me, I believe that systems that have a requirement to be highly agile, provide a high level of flexibility (configuration/scripting, as opposed to packaging and release of compiled code), and support essentially decoupled functions and flows, should not necessarily form part of conventional release management processes. The "release early, release often" convention can be followed on these systems. Obviously, a business must be made aware of the risks with this approach (e.g., more defects are likely to arise), and they should also be made aware of some of the sensible processes and changes in methodology to make this approach work (e.g., agile development methodologies). In my mind, integration and web implementations fall into this category.
Integration systems enhance the ability for each system to remain decoupled from it's peers - and this in turn means the systems are more modular, and should be able to support development and implementation (outside of a monster sized release), even when all of the required functions are not implemented. Integration systems can provide stubs that indicate a service is unavailable, and when each system is finally ready, then the processes can be turned on in each. Integration systems are inherently cross application, yet system independent at once. This paradoxical view on integration is what makes them great candidates for exclusion from release cycles - they are self contained, but support both the situations where external systems are present, as well as when they aren't. This level of resilience and flexibility means that they are a core enabler to allow other systems to deploy functions, and still work when the up/downstream systems they are reliant on do not exist.
I have a couple of recommendations if your organization is considering looking to migrate to a release management style approach for application development and deployment: