When a CIO or a CTO thinks of the applications they support it is almost always in terms of a "portfolio" When a research company named Gleanster poll executives about agile data management they discovered an interesting trend. Companies are reporting an increase in portfolio sizes with just over 36% of all respondents from large companies listing 75 or more applications in their portfolio.
75 or More Applications
These are the kinds of companies we work with. Companies that have a large number of projects and a large number of environments. In these environments it's easy to get distracted by this high-level view of software projects and assume that all software releases should be standardized. All projects must adhere to a set of standards and a process that minimizes risk, and all projects must have the same release process.
Organizations that have a recent history of rocky releases always tend to have that single approach to managing a release. We think this is a mistake, this assumption that every release should have the same structure and the same governance gates is an assumption that's built into some popular tools that are used to manage enterprise releases. But, anyone who has worked "in the trenches" on a release process understands that even on a single project there is always a large variety of release types:
My point isn't to make a list of all the possible types of releases it is just an acknowledgement that there is a wide variation, and our customers all tend to use different language for these different release types.
Variation in Risk
A portfolio of 75 applications is also a portfolio that has a wide variation of risk. This is another reason to avoid "One Release Process to Rule them All". If you configure your governance gates to provide maximum oversight of a critical deployment to the public-facing website would you do the same for an internal intranet used by 3-4 people?
You might think the answer is an obvious no, but if you don't use a tool like Plutora which allows you to customize your organization's workflow and override standards when they don't make sense you might just be using one of those legacy change management tools that treats every change to production as if it were a Moon launch.
This is the most common complaint of professionals forced to use bad tools for release management. They understand the necessity of tracking change. They understand the need for process, but what few understand is why tools designed to keep track of CMDB databases have been designed without usability in mind.
Plutora Meets Your Requirements
In Plutora we've tried to break the mold and create a tool that allows users to interact with a release process that can be redefined to meet your organization's requirements. We don't force you to stand up a single release management workflow because we understand that you work at the kind of company that is too big for cookie-cutter solutions.
When you are managing a release or approving a release as a manager, a tool like Plutora understands four things: