LeanIX - Product Documentation

Welcome to the LeanIX Product Documentation. Here you will find all the basic information you need to start working with LeanIX. We provide you with well-structured information on how to get more out of LeanIX, best-practices and use-case specific guidelines. Feel free to spread this product documentation in your company and use it as a common information source to answer your colleagues’ most urgent questions.

Get Started

Application Rationalization Dashboard

The Application Rationalization Dashboard allows you to identify redundant Applications using KPIs.


The rationalization of the Application landscape usually consists of the following four steps:

  1. Get necessary information into the workspace
  2. Identify and evaluate potentially redundant Applications
  3. Rationalize potentially redundant Applications
  4. Keep your inventory up-to-date

Step 1: Get necessary information into the workspace

To be able to identify potentially redundant Applications, we need (at least) the following information in the workspace:

  • The Applications as Fact Sheets together with the following attributes:
    • Technical Fit
    • Functional Fit
    • Business Criticality
    • Lifecycle
  • Your Business Capability model
  • Relations between the Applications and your Business Capabilities
  • Every Application needs at least one subscriber of type RESPONSIBLE
  • Your User Groups and their connection to the Applications (possibly also the constraining relations to determine which User Group uses which Application to support what Business Capability)

The information of these properties forms the basis of the aggregated "Data Quality" KPI on the Application Rationalization Dashboard. Furthermore, another KPI (NAME?) is featured indicating how many Fact Sheets have all of these properties filled out.

For the calculation of the data quality KPI, all Applications excluding those with an "end of life" lifecycle are considered. The calculation and update of the underlying metrics time series, that captures these KPIs, is done on a daily basis.


Best practice

  • Collaborate with your colleagues to collect & complete relevant information in your workspace, e.g. by using Surveys
  • Import missing data via Excel imports

Step 2: Identify and evaluate potentially redundant Applications

Before it is possible to actually rationalize Applications, it helps to identify Applications that are (potentially) redundant.



An Application is (potentially) redundant if all of the linked Business Capabilities are supported by more than one Application.

Our algorithm for calculating redundant Applications is the following:

  • For a given Application A, determine all Business Capabilities B_1, ... B_n where n is the number of Business Capabilities linked (directly) to A.
    • If n == 0, then A is missing data. and we go to the next Application.
  • For every Business Capability B_1, ... B_n count the amount of linked Applications c_1, ..., c_n.
    • If min(c_1, ..., c_n) > 1, then we call A redundant.
    • If max(c_1, ..., c_n) < 2, then we call A non-redundant.
    • If A is neither redundant nor non-redundant, then we call A partially redundant.


The left hand side, shows the Applications and the right hand side, the connected Business Capabilities. The three Applications show the three relevant scenarios for redundancy

Though for the Application Rationalization Dashboard we stop at this level for the redundancy calculation, you should go deeper to analyze the potential rationalization targets. It is a good idea to use an Application Matrix Report, filter on the Business Capabilities you are interested in and check what Applications are being used by which User Group.

In the earlier scenario, we can have e.g. the following matrix report:

The Application called "PARTIALLY_REDUNDANT" is the only one that supports "Only one App" and only User Group A uses this Application to support the Business Capability "Only one App". Why isn't User Group B using it? Don't they need this Business Capability? Is there maybe a gap?

The Business Capability "Two Apps" is supported by the Applications "PARTIALLY_REDUNDANT" and "REDUNDANT" for User Group A, but for User Group B only the Application "REDUNDANT" is being used? This can have a lot of reasons and you should investigate here: Is this a compliance or other reason or could User Group B use "PARTIALLY_REDUNDANT" as well and you could rationalize the Application "REDUNDANT" and save your company money?

In order to help you in tracking your effort on finding potentially redundant Applications, the Application Rationalization Dashboard features the distribution of redundant, partially redundant and non-redundant Applications as well as the Applications that still miss data to make this assessment. As always, the Applications that are "end of life" in their lifecycle are not counted in.

Step 3: Rationalize potentially redundant Applications

Given that you have complete data, you can now start assessing the value of each Application:

  • Use the following properties of Applications in a portfolio report to make the critical decisions:
    • Functional Fit
    • Technical Fit
    • Business Criticality
    • Cost

Then assign to the Applications the TIME categories:

  • Tolerate
  • Invest
  • Migrate
  • Eliminate

and assign appropriate lifecycles to these Applications according to your sunsetting plans.

In a future version of the Application Rationalization Dashboard, we will feature KPIs to show your progress on this topic as well as a portfolio report to quickly identify the best rationalization targets.

Step 4: Keep your inventory up-to-date

Though not yet part of the Application Rationalization dashboard, we recommend that you keep track of further rationalization in your workspace, e.g. based on the Burndown Chart of redundant Applications downloadable in the LeanIX Store (LINK?) or by implementing a cloud-readiness score and thereby tracking the progress of your cloud adoption.

Updated about a month ago

Application Rationalization Dashboard

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.