Application Rationalization Metamodel

Application Rationalization (AR) is the effort to strategically identify business applications across an organization to determine which should be tolerated, migrated, invested in, or eliminated. Application Rationalization can be a one off initiative but, is often part of a continuous process to ensure that applications are best aligned to enable business capabilities. Read this article to learn about the scope of Application Rationalization, the choices we’ve made regarding implementation, and how to implement it in practice.

Purpose, Scope, and Rationale


Application Rationalization illustrates how organizations can leverage the relationship between applications and business capabilities to drive decision making around an application’s overall business and technical fit. The process highlights candidates for rationalization in order to facilitate further business case and impact analysis processes.

AR assists organizations in answering the following questions:

  1. How do we identify low-hanging fruits that will reduce cost and give us more agility to act faster?

  2. Where can we identify cost savings by eliminating duplication?

  3. Where can we realize potential cost cuts?

  4. How can we reduce the overall IT Risk Surface as it relates to a 'Long Tail' or 'history of ungoverned' organic IT acquisition?

  5. How do I manage the impact, risk, and stakeholders of doing application rationalization?

  6. In what applications should I increase the level of investment and what applications should I try to phase out?

Application Rationalization does not require any further metamodel components to be created and utilizes the efforts carried out in the Business Capability Realization (BCR), Application Lifecycle Management (ALM), IT Lifecycle Management (ITLM), Application Integration Management, and IT Cost Management (ITCM) use cases. However, the Metamodel does require the addition of a number of new fields to the Application component.


There are many different strategic justifications for an organization to conduct a rationalization initiative including elimination/consolidation, economizing, modernization, retiring aging applications, a bloated IT portfolio, etc.

This version of the Application Rationalization Use Case Guide sets the scope for application consolidation and elimination. Consolidation is where multiple applications are realizing the same capability, creating functional overlaps. Through consolidation, we look to remove these redundancies to drive efficiency and reduce IT spend. This will act as a catalyst for several other types of elimination based application rationalization efforts, like Mergers & Acquisitions and Modernization, as it is foundational in nature.

But the primary focus is to provide stakeholders with a list of actionable application rationalization candidates to facilitate further business case and impact analysis processes on an individual application basis.


The objective of the Metamodel is to capture information through the application rationalization process to determine the strategic rating for a given application.

To facilitate the Tolerate, Invest, Migrate, Eliminate (TIME) strategic rating and determine the business value and technical fit of an application Ardoq broadly follows the CIO Application Rationalization Playbook as the method to inventory the application portfolio and gather relevant information. The playbook provides an alternative strategic rating scoring model in the form of Review, Reward, Refresh and Remove. Ardoq recommends aligning application scoring to the more widely recognized Gartner TIME model. Application rationalization in Ardoq, therefore, uses an amalgamation of Gartner's TIME and CIO Council's playbook to deliver the optimal coverage.

Ardoq uses Gartner’s TIME model which looks at the business value of an application and compares it against the technical fit. This comparison enables a strategic rating to be determined. The Strategic Rating is one of the essential criteria in the identification of potential Application Rationalization candidates. For example, Applications with a strategic rating of Eliminate, would be candidates for consolidation and removal from the application portfolio. In contrast, a strategic rating of Invest are likely candidates for improvement and further development due to the value they bring to the organization. Strategic ratings are further explained in the application component properties section below.

Our rationale for the Application Rationalization metamodel is to handle the broadest set of scenarios possible with the minimum number of metamodeling concepts.

Learn more about this approach in our Seven Principles of Creating a great Enterprise Architecture Metamodel. We also aim to leverage what has been provided in supporting use cases.

Ardoq’s Approach to Application Rationalization

Ardoq’s approach to rationalization starts with the identification of applications for potential consolidation. This means reducing the application portfolio to drive resource efficiency and reducing the risk profile of the organization.

To achieve Consolidation Ardoq’s metamodel captures 3 evaluation criteria for determining application rationalization decisions: Suitability (which is captured by an application’s Strategic Rating) , Structural Complexity (indication of connected infrastructure), and Cost when utilizing the relationship between Applications and their explicit connection to Business Capabilities.

Suitability captures the application’s fit in the organization as a whole. It considers the Alignment to Processes, Features and Usability, Criticality, and Organizational Fit. This information is collected from application owners.

Structural complexity records a quantitative way to determine how interconnected an application is in relation to the overall IT portfolio. Ardoq uses Integration Count, Number of Connected Technology Services and Servers, and the number of Business Capabilities realized by a specified application. These fields provide stakeholders with a way to evaluate how much effort might be required to rationalize a given application.

Cost is the last area the metamodel considers and this is the calculated cost provided by the application component.

As a basis for identifying opportunities, Ardoq uses strategic rating and an application lifecycle end date of less than 12 months to identify potential candidates. This is then combined with total cost and structural complexity to provide the basis for decision-making and further assessment.

Understanding the Application Rationalization Metamodel

This section will walk through the different component types, fields, and reference types that make up the metamodel for Application Rationalization.

Application Components

At the heart of Application Rationalization is the Application Component. As covered in greater detail in the Application Lifecycle Management Metamodel article, an application is the configuration of lower-level software or technology to provide specific business capability or technology capability, perform a defined task, or analyze specific information.

Application Component Properties

We combine existing application component data and create properties to facilitate the assignment of a strategic rating. This data can later be captured through input, import, or surveys.

These properties provide the opportunity to calculate the suitability, structural complexity, and cost in meaningful ways to produce relevant application rationalization dashboards, reports, and visualizations.


Suitability looks at the strategic rating which balances the importance and overall fit of an application in the business. This provides a framework to evaluate your application portfolio against two primary measures; Business Value and Technical Fit. The allocation of business value and technical fit generate the following suitability criteria:

  • Tolerate - Applications that provide low business value, but do have a working function, and provide high technical fit. This type of application shouldn't be too costly and should require little to no support. For example applications with a business value score of 0-3 and a technical fit score of 3-5 would be given a strategic rating of tolerate.

  • Invest - Applications that are both high in technical fit and help you reach your business objectives deserve further investment. This type of application experiences no disruptions and serves its purpose and ideally generates cost savings or income. For example applications with a business value score of 3-5 and a technical fit score of 3-5 would be given a strategic rating of invest.

  • Migrate - Applications that serve a crucial purpose to your business but are problematic on the IT side need to be migrated. Migrate highlights applications that might require too much effort or cost for maintenance and support. For example applications with a business value score of 3-5 and a technical fit score of 0-3 would be given a strategic rating of migrate.

  • Eliminate - Applications that have low business value and poor technical fit should be eliminated. For example applications with a business value score of 0-3 and a technical fit score of 0-3 would be given a strategic rating of eliminate.





Strategic Rating

Calculated Text (TIME)

Application model from Gartner for placing applications Tolerate, Invest, Migrate, and Eliminate.

Strategic Rating = (Business Value measured against Technical Fit)

Business Value

Calculated Number Value (1-5)

Assesses how well the application supports the current needs and the future plans and value to its users.

Business Value = Business Strategic Fit + Features and Usability + Functional Fit + Criticality

Technical Fit

Calculated Number Value (1-5)

How well the application supports the current technical needs and the future plans of the support organization.

Technical Fit = Technical Integrity + Maintainability and Agility + Technical Strategic Fit

Business Value





Business Strategic Fit

Survey Calculated Number

Scale (1-5)

Application’s ability to support business strategy or the ambitions of its users.

Survey Value

1 - No Alignment -> 5 Highly Aligned

Features and Usability

Survey Number

Scale (1-5)

Is the application easy to use without unreasonable training or extensive experience?

Survey Value

1 - Highly complex and requires training and extensive knowledge to get maximum value -> 5 Easy to use and intuitive / no or minimal training is required.

Functional Fit

Survey Number

Scale (1-5)

Does the application provide all the functionality required to realize the relevant capability/value stream

Survey Value

1 - Requires supplemental tools or workarounds -> 5 Highly Aligned


Survey NUmber

Scale (1-5)

Criticality of the application in supporting the business and/or customers

Survey Value

1 - Non-Critical No Impact -> 5 Mission Critical - Serious Impact

Technical Fit





Technical Integrity

Survey Number

Scale (1-5)

Determines how the application adheres to technical standards.

Survey Value

1 - Non-Compliant -> 5 Highly Compliant

Maintainability and Agility

Survey Number

Scale (1-5)

Provides a value for the ease of upkeep and ability to adapt within the technology landscape.

Survey Value

1 - Maintenance is feared and full of unknown impacts -> 5 Easy to Maintain and Flexible

Technical Strategic Fit

Survey Number

Scale (1-5)

Provides an indication to future-proofing of an application.

Survey Value

1 - Legacy and does not support modern architecture -> 5 Highly extensible and aligned with future requirements.

Structural Complexity

As previously mentioned, Structural Complexity is a basic way of determining how interconnected, technically, the application is in the overall IT portfolio.





Realized Capabilities

Calculated Number

Provides stakeholders with a view of what capabilities the application realizes.

Count of all the Business Capabilities that a given application realizes

Total Integrations

Calculated Number

Highlights if the application provides and/or consumes data from other applications or systems.

Sum of all of the Incoming and Outgoing Integrations

Total Combined Infrastructure

Calculated Number

Provides a high-level overview of the Connected infrastructure.

Sum of all “Support By” directly connected infrastructure

Total Connected Infrastructure

Calculated Number

Provides a high-level overview of the Connected Technology Services.

Sum of all “Support By” Technology Services

Total Connected Infrastructure

Calculated Number

Provides a high-level overview of the connected services.

Sum of all “Support By” Servers & Technology Services

If these metricsall have notionally high values then stakeholders could infer the application would have a high level of effort to rationalize the application.

As an example an application has a strategic rating of ELIMINATE butevaluating two applications we find that application one’s structural complexity values are >4 Realized Capabilities + >5 Total Integrations + >10 Total Connected Infrastructure components but application two’s structural complexity is 1 Realized Capability + 1 Total Integrations + 1 Total Connected Infrastructure Component. In this scenario the person responsible for Application Rationalization could infer that application two would require less effort to Eliminate the application. It should be noted that Structural Complexity only provides an indication of effort.

Total Cost

Cost is often a key consideration when evaluating applications.

Utilizing the ITCM Metamodel and Use Case we can provide indicative cost values for Applications:





Total Cost

Calculated Number

Shows the Total Cost of the


Total Direct + Total Consumed

Cost from the Component in


Business Capability

As identified in the BCR and BCM use cases, a business capability is a set of resources that, by working together, gives the organization the ability to purposefully produce a particular business output. They are the modular building blocks of a business, either as something that exists today or something that a company is able to do in the future. The use case does not create any new properties on business capability, it only utilizes existing capability properties.

Application Rationalization References

Application Rationalization relies on two reference types:



Is Realized By

Represents that a component implements the

logical requirements, behaviors, or characteristics defined by another component.

As an expample a Business Capability is realized by an


Is Supported By

Represents the operation of one component is a requirement or precondition for the operation of another.

As an example an Application is supported by a server

The references are important in determining the suitability or structural complexity of an application, which is why it’s important to be mindful about creating the right connections. Below is an example of the references between the four component types:

Practical Implementation

If previous use cases are complete, the Application Rationalization Use Case does not require further component types or references.

Prerequisite use cases are: IT Lifecycle Management, Application Integration Management, and Application Lifecycle Management and Application Hosting.

Application Rationalization also requires that Applications are modeled to relevant Business Capabilities they realize and that relevant cost information is provided through IT Cost Management.

Ardoq recommends the simplest model to do the job. The picture below illustrates the workspaces and their relations used to implement the data lineage bundle.

Gremlin Code

This section contains the Gremlin Code used to implement the Calculated Fields of the application rationalization use case.

Business Value Calculation

This contains the Gremlin Code that calculates a value for the field values to the target component Business Value. The code checks the fields: Functional Fit, Features And Usability, Business Strategic Fit and Criticality and calculates Business Value. The code also takes into account a specific weighting in Business Value.

functionalFitKey = 'functional_fit'

functionalFitWeighting = 0.25

availabilityAndQualityKey = 'availability_and_quality'

availabilityAndQualityWeighting = 0.25

businessStrategicFitKey = 'business_strategic_fit'

businessStrategicFitWeighting = 0.25

criticalityKey = 'criticality'

criticalityWeighting = 0.25

def calculateBusinessFit(it) {

a=it.get().values(functionalFitKey)[0] as Double

b=it.get().values(availabilityAndQualityKey)[0] as Double

c=it.get().values(businessStrategicFitKey)[0] as Double

d=it.get().values(criticalityKey)[0] as Double

return (a*functionalFitWeighting + b*availabilityAndQualityWeighting + c*businessStrategicFitWeighting + d*criticalityWeighting).round(2)








.project('id', 'name', 'value').




Technical Fit Calculation

This contains the Gremlin Code that calculates a value for the field values to the target component Technical Fit. The code checks the fields: Technical Integrity, Maintainability And Agility, Technical Strategic Fit and calculates Technical Fit. The code also takes into account a specific weighting in Technical Fit.

technicalFitRatingField = 'Technical Fit'

technicalIntegrityKey = 'technical_integrity'

technicalIntegrityWeighting = 0.40

maintainabilityAndAgilityKey = 'maintainability_and_agility'

maintainabilityAndAgilityWeighting = 0.27

technicalStrategicFitKey = 'technical_strategic_fit'

technicalStrategicFitWeighting = 0.33

def calculateTechnicalFit(it) {

a=it.get().values(technicalIntegrityKey)[0] as Double

b=it.get().values(maintainabilityAndAgilityKey)[0] as Double

c=it.get().values(technicalStrategicFitKey)[0] as Double

return (a*technicalIntegrityWeighting + b*maintainabilityAndAgilityWeighting + c*technicalStrategicFitWeighting).round(2)







.project('id', 'name', 'value').




Extending your AR Metamodel

We have provided our criteria but this section explains how you can add your own by extending the metamodel. For example, adding new fields can be done by an administrator in seconds - see this article for information on adding fields.

An administrator can also easily create a new component and reference type, although we suggest you plan this process carefully. Over-complex metamodels can be hard to navigate and query.

Before you extend your metamodel, ask yourself:

  1. How will I or others capture this information?

  2. How much effort will it be across the whole application portfolio?

  3. How will I use this information to create actionable insight?

With those considerations, you can quickly adapt your model to changing requirements. You can keep your critical data up-to-date and maintain your insights, keeping it continuously relevant as requirements evolve.

We're always happy to help. Feel free to reach out to us via the in-app chat if you have any follow-up questions about this article.






Sean Gibson

First Draft

Did this answer your question?