In the same way you need to be an 80s or 90s kid to get the association between a pencil and a cassette, in the not so distant future lucky IT people will no longer need to see a direct association between the two words “Application” and “Rationalization”.
What is Application Rationalization?
Application Rationalization is an activity under taken by most large enterprises over the last decade to consolidate their application portfolio.
Perceived benefits are:
• Gaining control of the application landscape
• Retiring unused, redundant or inefficient applications
• Reduce application costs
• Modernize the application portfolio and enable innovation
Why does Application Rationalization happen?
A common characteristic of large enterprises is a matrix of global geography (business units and presence across continents & countries) and segments & functions. While there is a global strategy, individual business units, segments or functions frequently build, release and manage applications locally to address local business and segment requirements. This results in a large number of applications spread globally.
No matter what the size of the organization, all companies are guilty of rapidly releasing applications to solve immediate issues. These are technical debt applications.
Poor enterprise architecture and a lack of an overview of the entire enterprise current and target landscape results in "mushroom" applications popping up.
Even if good application planning take place and target application landscapes are known and accounted for, frequently enterprises may need to address urgent new requirements due to unforeseen market changes or regulation.
All of the above results in large unwieldy application portfolios, high application costs and high maintenance costs. The answer is seen to be an "Application Rationalization" initiative.
Why do Application Rationalization initiatives fail?
Application Rationalization initiatives are frequently unsuccessful. In my experience they fail for the following reasons.
1. Organisations set aggressive & unrealistic goals trying to reduce application portfolios sometimes by nearly up to 50%.
2. The initiative is run from one group at a global level, i.e. a group application department, while this department may have a mandate for all applications globally they frequently cannot have insight into all applications' scopes at business unit level and cross-departmentally. It is therefore unrealistic that it is run from such a group.
3. Application Rationalization is frequently run without properly engaging enterprise architecture and without a full understanding of the target architectural landscape, this results in only pieces of the target landscape being accounted for and the full portfolio requirements not being fully understood.
So when will Application Rationalization become the cassette and pencil?
In enterprises we typically deal with applications and projects. Applications are born from projects or programs and all governance pivots around this structure. A project can last many months or years, has a dedicated project team and delivery schedule. A project ends and an application goes into BAU (business as usual) state. It is maintained by a different team from the project team. Aside from fixes, an application can be a relatively static entity on the application landscape horizon until it is End-Of-Life'd or maybe meets an application rationalization initiative.
Adopting DevOps the enterprise moves from project delivery to product management.
No longer do you have a portfolio of applications handed from one group (project delivery) to another (application maintenance/operations) but rather you have products. Built and managed by the same DevOps team. The "you build it, you run it" mantra. The product is described by a product backlog. The product owner(s) represents, describes and prioritizes the requirements. This means when the business has new requirements or urgent new features (for example, to respond to market changes or regulation) the existing product can address these new stories. A new application does not need to be built. Using DevOps the enterprise can manage fewer products that never go into a BAU state. The product is a never a static entity on the enterprise's landscape horizon.
The DevOps approach will remove the need for Application Rationalization initiatives in the future as the product continuously evolves with the DevOps team. All the application rationalization benefits mentioned above are realized.
If your organization is evaluating an application rationalization initiative, consider using DevOps to change the focus of your application development and the agility of your production assets.