Get the Full Picture: Rationalizing Your Apps in Isolation Is Not Rationalization
Application rationalization can be a challenging endeavor. Those who don’t take the correct approach or get the right backing often struggle to experience the real benefits they are after. One of the largest contributing factors to unsuccessful rationalization comes from applying a framework that is designed to only assess individual applications in isolation. Often for the purposes of education or to help sell tools or consulting services, application rationalization is simplified to get the basics across and make obtaining the results seem relatively easy.
One such approach that can be accused of this oversimplification is the TIME model (Tolerate, Invest, Migrate, and Eliminate). TIME is a common approach to rationalization where you’re asking two fundamental questions: does the application present a challenge from a technical perspective and how valuable is this application to the organization? Both of these can be unpacked to address many specific factors, such as maintainability, reliability, performance, cost, or alignment with your technology roadmap as well as value factors such as criticality, impact on established KPIs, and alignment with the business’s strategic priorities.
The basic idea is:
-
Apps with low value and high technical fit fall into the tolerate quadrant, as their value may be low, but because they don’t pose any risks, there is less justification to pay for decommission. - Apps with high value and high technical fit fall into the invest quadrant, where again you keep the app, but welcome or actively pursue enhancement or expansion.
- Apps with high value and low technical fit require migration, as the business needs that functionality, but it is best to move to a new platform or alternative solution that resolves any technical issues.
- Finally, apps with low value and low technical fit are candidates for elimination as they provide little value and the ongoing operational costs or risk they would present warrant the spend for decommission.
It should be noted that while this is quite simplistic, it does provide a lot of organizations with a starting point for planning for individual applications and the future state of their application portfolio.
The problem is, where does redundancy come into this equation?
In the example provided above we see two CRMs, both given an invest disposition because they are viewed as valuable and having a strong technical fit. Surely, if these two systems were redundant, the goal of a rationalization framework would be to determine which should be kept and which should be removed. We need to know more about these two systems to suggest what their disposition should be.
Arguably the biggest benefit from application rationalization, especially from an ROI perspective, is identifying and reducing redundant applications. An application’s value or technical fit doesn’t necessarily lessen because there is another solution that provides similar functionality.
Any toolset or approach that claims to rationalize your applications has to take into consideration where and how your applications overlap. Ideal practices would suggest that this information is well understood prior to collecting other factors such as value, cost, and performance.
This is why application rationalization is more commonly seen as a feature within enterprise architecture (EA) tools instead of application lifecycle management (ALM) tools. ALM falls guilty to the same problem of managing applications as individual units and does include the portfolio view, which EA tools specialize in. EA tools are going to view the applications as a part of business capability, which exists across your organization.
LeanIX is a good example of this. Its product is first and foremost an EA suite, yet one of the largest use cases is application rationalization. Lean IX is oriented around business architecture practices and mapping technical assets to business capabilities. This allows application managers to develop a standardized and recognizable set of functional categories (business capabilities) for your application. This allows you to sort your apps based on similar, complementary, or redundant functionality. When dealing with a highly redundant portfolio this becomes the most critical exercise in rationalization.
Source: LeanIX at SoftwareReviews, Accessed May 4, 2020
LeanIX continues to climb in the EA tool space and is currently is second on Info-Tech’s list of EA software vendors. Its ability to tie itself into the business decision-making process, like application rationalization, is a big huge part of its value.
Our Take
- Don’t use a generic approach to rationalization. Apply an approach that is aligned to your goals.
- Odds are you need to get a better understanding of your portfolio, specifically your redundancies, before you begin to rationalize your apps. Tools like LeanIX and guidance like Info-Tech’s approach for application portfolio management and business architecture can help you get the prerequisite for rationalization.