Comprehensive software reviews to make better IT decisions
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.
- 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.
Want to Know More?
This note outlines some of the fundamental KPIs that you should measure to show the success of the enterprise architecture team. It also discusses how you measure them and visualize the result.
The application portfolio management (APM) tool space can be a confusing one, as many software vendors offer their own take of what APM is. Enterprise architecture, application management and project portfolio management tools offer an APM use case, but these are often quite skewed the primary function of the tool.
Application rationalization fails when the chosen framework does not match your scenario or the goals for your application portfolio. This note looks at how to apply application rationalization during an M&A.
Often people misidentify the purpose of application rationalization, leading to misuse and unsatisfactory results. We try to break application rationalization down to its simplest form to understand how to make the most of this critical IT function. tr
Measuring technical debt is important, but more important is communicating the implications of this problem in terms of risk to business capabilities. Cast Highlight tools are used for application portfolio management (APM), specializing in applying code analytics to business decisions regarding your organization’s applications.
MEGA International announced the launch of its HOPEX Information Architecture solution, enabling various stakeholders to share the same level of information to make collaborative, informed decisions about the governance of data.
Enterprise architects want to collaborate with businesses in real-time to design and create models, but due to geographical constraints, this is not often possible. Many enterprise architecture (EA) tools simply don’t allow the parties/teams to view changes in real-time.
iServer: Enterprise Architecture and Strategic Portfolio Management Tightly Aligned to Your Microsoft Suite
Orbus’s iServer provides quick and easy architecture and strategic portfolio analysis features for those embedded in the Microsoft environment.
Over 1,000 IT leaders and professions gathered for a diverse slate of technology and professional practice sessions this week at BA World Toronto, May 27-30, 2019. There has been broad representation from key vendors in the Product, Requirements, and Design Management category. Tom O’Reilly, the COO of Sparx Systems ran a session to explore how requirements management tools are a key part of a modern business analysis practice.