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
Purpose
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:
How do we identify low-hanging fruits that will reduce cost and give us more agility to act faster?
Where can we identify cost savings by eliminating duplication?
Where can we realize potential cost cuts?
How can we reduce the overall IT Risk Surface as it relates to a 'Long Tail' or 'history of ungoverned' organic IT acquisition?
How do I manage the impact, risk, and stakeholders of doing application rationalization?
In what applications should I increase the level of investment and what applications should I try to phase out?
Scope
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.
Rationale
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 combination 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.
Ardoq’s metamodel captures three evaluation criteria for determining application rationalization decisions:
Suitability (which is captured by an application’s Strategic Rating)
Structural Complexity (indication of connected infrastructure)
Cost
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
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.
Field | Type | Description | Definition |
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
Field | Type | Description | Definition |
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 |
Criticality | 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
Field | Type | Description | Definition |
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.
Field | Type | Description | Definition |
Total 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 Technology Services | Calculated Number | Provides a high-level overview of the Connected Technology Services. | Sum of all “Support By” Technology Services |
Total Supporting Infrastructure | Calculated Number | Provides a high-level overview of the connected services. | Sum of all “Support By” Servers & Technology Services |
If these metrics all 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 but evaluating 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.
Following the IT Cost Management Use Case Guide we can provide indicative cost values for Applications:
Field | Type | Description | Definition |
Total Cost | Calculated Number | Shows the Total Cost of the
Component | Total Direct + Total Consumed
Cost from the Component in
question |
Business Capability
As identified in the Business Capability Modeling Use Case Guide, 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 uses existing capability properties.
Application Rationalization References
Application Rationalization relies on two reference types:
Reference | Description |
Is Realized By | Represents that a component implements the logical requirements, behaviors, or characteristics defined by another component. As an example a Business Capability is realized by an Application |
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 Guide does not require further component types or references.
Prerequisite use cases are: Infrastructure Technology 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.20 featuresAndUsabilityKey = 'features_and_usability' featuresAndUsabilityWeighting = 0.20 businessStrategicFitKey = 'business_strategic_fit' businessStrategicFitWeighting = 0.25 criticalityKey = 'criticality' criticalityWeighting = 0.35
def calculateBusinessValue(it) { a=it.get().values(functionalFitKey)[0] as Double b=it.get().values(featuresAndUsabilityKey)[0] as Double c=it.get().values(businessStrategicFitKey)[0] as Double d=it.get().values(criticalityKey)[0] as Double return (a*functionalFitWeighting + b*featuresAndUsabilityWeighting + c*businessStrategicFitWeighting + d*criticalityWeighting).round(2) }
g.V(ids) .and( has(functionalFitKey), has(featuresAndUsabilityKey), has(businessStrategicFitKey), has(criticalityKey)) .project('id', 'name', 'value'). by(id). by('name'). by(map{calculateBusinessValue(it)})
|
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.
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)
}
g.V(ids)
.and(
has(technicalIntegrityKey),
has(maintainabilityAndAgilityKey),
has(technicalStrategicFitKey))
.project('id', 'name', 'value').
by(id).
by('name').
by(map{calculateTechnicalFit(it)}) |
Extending your Application Rationalization 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:
How will I or others capture this information?
How much effort will it be across the whole application portfolio?
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.
Version | Date | Author | Rationale |
0.1 |
| Sean Gibson | First Draft |
|
|
|
|
|
|
|
|