Build an Application Rationalization Framework

Manage your application portfolio to minimize risk and maximize value.

Analyst Perspective

"You're not rationalizing for the sake of IT, you’re rationalizing your apps to create better outcomes for the business and your customers. Consider what’s in it for delivery, operations, the business, and the customer." – Cole Cioran, Senior Director – Research, Application Delivery and Management

Our understanding of the problem

This Research Is Designed For:

• Application portfolio managers, application portfolio management (APM) teams, or any application leaders who are tasked with making application portfolio decisions.
• Application leaders looking to align their portfolios to the organization’s strategy.
• Application leaders who need a process for rationalizing their applications.

This Research Will Help You:

• Measure the business value of your applications.
• Rationalize your portfolio to determine the best disposition for each application.
• Initiate a roadmap that will showcase the future of your applications.

This Research Will Also Assist:

• CIOs and other business leaders who need to understand the applications in their portfolio, the value they contribute to the business, and their strategic direction over a given timeline.
• Steering committees and/or the PMO that needs to understand the process by which application dispositions are generated.

This Research Will Help Them:

• Build their reputation as an IT leader who drives the business forward.
• Define the organization’s value statement in the context of IT and their applications.
• Visualize the roadmap to the organization’s target application landscape.

Executive Summary

Situation

• Almost two-thirds of organizations report that they have too many or far too many applications due to sprawl from poorly managed portfolios (Flexera, 2015).
• Application managers are spending too much time supporting non-critical applications and not enough time on their most vital ones.
• Application managers need their portfolios to be current and effective and evolve continuously to support the business or risk being marginalized.

Complication

• The necessary pieces of rationalization are rarely in one place. You need to assemble the resources to collect vital rationalization criteria.
• There is a lack of standard practices to define the business value that the applications in a portfolio provide and, without value rationalization, decisions are misaligned to business needs.

Resolution

• Define the roles, responsibilities, and outputs for application rationalization within your application portfolio management (APM) and other related practices.
• Build a tailored application rationalization framework (ARF) aligned with your motivations, goals, and limitations.
• Apply the various application assessments to produce the information, which your dispositions will be based on, and adapt your ARF based on the experiences of your first iteration.
• Review, determine, and prioritize your application dispositions to create a portfolio strategy aligned to your goals.
• Initiate an application portfolio roadmap, which will showcase your rationalization decisions to key stakeholders.

Info-Tech Insight

There is no one size fits all.

Applying a rigid approach with inflexible inputs can delay or prevent you from realizing value. Play to your strengths and build a framework that aligns to your goals and limitations.

Business value must drive your decisions.

Of the 11 vendor capabilities asked about by Info-Tech’s SoftwareReviews, “business value created” has the second highest relationship with overall software satisfaction.

Take an iterative approach.

Larger approaches take longer and are more likely to fail. Identify the applications that best address your strategic objectives, then: rationalize, learn, repeat.

Info-Tech recommends a disciplined, step-by-step approach as outlined in our Application Portfolio Strategy Program

Step 1 "No Knowledge": Define application capabilities and visualize lifecycle stages

Application Discovery

1. Build in Application Portfolio Management Principles.
2. Conduct Application Alignment.
3. Build Detailed Application Inventory

Step 2 "No Strategy": Rationalize application portfolio and visualize strategic directions

Application Rationalization

4. Set Your Rationalization Framework
5. Conduct Assessment & Assign Dispositions
6. Create an Application Portfolio Roadmap

Step 3 "No Plan": Build a product roadmap and visualize the detailed plan

Detailed Disposition Planning

7. Conduct an Impact Assessment
8. Determine the Details of the Disposition
9. Create Detailed Product Roadmaps

This blueprint focuses on step 2 of Info-Tech's Application Portfolio Strategy Program. Our methodology assumes you have completed the following activities, which are outlined in Discover Your Applications.

• Collected your full application inventory (including Shadow IT)
• Aligned applications to business capabilities
• Determined redundant applications
• Identified appropriate subject matter experts (business and technical) for your applications

Info-Tech's four-phase methodology

Phase 1

Lay Your Foundations

• Define Motivations, Goals, and Scope
• Iteration and Engagement Planning

This phase is intended to establish the fundamentals in launching either a rationalization initiative or ongoing practice.

Here we define goals, scope, and the involvement of various roles from both IT and the business.

Phase 2

Plan Your ARF

• Establish Rationalization Inputs and Current Gaps

This phase is intended to review a high-level approach to rationalization and determine which analyses are necessary and their appropriate level of depth.

Here we produce an initial ARF and discuss any gaps in terms of the availability of necessary data points and additional collection methods that will need to be applied.

Phase 3

Test and Adapt Your ARF

• Perform First Iteration Analysis
• First Iteration Retrospective and Adaptation

This phase is intended to put the ARF into action and adapt as necessary to ensure success in your organization.

If appropriate, here we apply Info-Tech’s ARF and toolset and test it against a set of applications to determine how best to adapt these materials for your needs.

Phase 4

Initiate Your Roadmap

• Prioritize and Roadmap Applications
• Ongoing Rationalization and Roadmapping

This phase is intended to capture results of rationalization and solidify your rationalization initiative or ongoing practice.

Here we aim to inject your dispositions into an application portfolio roadmap and ensure ongoing governance of APM activities.

There is an inconsistent understanding and ownership of the application portfolio

What can I discover about my portfolio?

Application portfolios are misunderstood.

Portfolios are viewed as only supportive in nature. There is no strategy or process to evaluate application portfolios effectively. As a result, organizations build a roadmap with a lack of understanding of their portfolio.

72% of organizations do not have an excellent understanding of the application portfolio (Capgemini).

How can I improve my portfolio?

Misalignment between Applications and Business Operations

Applications fail to meet their intended function, resulting in duplication, a waste of resources, and a decrease in ROI. This makes it harder for IT to justify to the business the reasons to complete a roadmap.

48% of organizations believe that there are more applications than the business requires (Capgemini).

How can my portfolio help transform the business?

IT's budget is to keep the lights on.

The application portfolio is complex and pervasive and requires constant support from IT. This makes it increasingly difficult for IT to adopt or develop new strategies since its immediate goal will always be to fix what already exists. This causes large delays and breaks in the timeline to complete a roadmap.

68% of IT directors have wasted time and money because they did not have better visibility of application roadmaps (ComputerWeekly).

Roadmaps can be the solution, but stall when they lack the information needed for good decision making

An application portfolio roadmap provides a visual representation of your application portfolio, is used to plan out the portfolio’s strategy over a given time frame, and assists management in key decisions. But…

• You can’t change an app without knowing its backend.
• You can't rationalize what you don't know.
• You can’t confirm redundancies without knowing every app.
• You can’t rationalize without the business perspective.

A roadmap is meaningless if you haven’t done any analysis to understand the multiple perspectives on your applications.

Application rationalization ensures roadmaps reflect what the business actually wants and needs

Application rationalization is the practice of strategically identifying business applications across an organization to determine which applications should be kept, replaced, retired, or consolidated (TechTarget).

Discover, Improve, and Transform Through Application Rationalization

Your application rationalization effort increases the maturity of your roadmap efforts by increasing value to the business. Go beyond the discover phase – leverage application rationalization insights to reach the improve and transform phases.

Strong Apps Are Key to Business Satisfaction

79% of organizations with high application suite satisfaction believe that IT offers the organization a competitive edge over others in the industry. (Info-Tech Research Group, N=230)

Info-Tech Insight

Companies with an effective portfolio are twice as likely to report high-quality applications, four times as likely to report high proficiency in legacy apps management, and six times as likely to report strong business alignment.

Rationalization comes at a justified cost

Rationalization can reduce costs and drive innovation

Projecting the ROI of application rationalization is difficult and dangerous when used as the only marker for success.

However, rationalization, when done effectively, will help drop operational or maintenance costs of your applications as well as provide many more opportunities to add value to the business.

Organizations lack a strategic approach to application rationalization, leading to failure

IT leaders strive to push the business forward but are stuck in a cycle of reaction where they manage short-term needs rather than strategic approaches.

Why Is This the Case?

Lack of Relevant Information

Rationalization fails without appropriately detailed, accurate, and up-to-date information. You need to identify what information is available and assemble the teams to collect and analyze it.

Failure to Align With Business Objectives

Rationalization fails when you lack a clear list of strategic and collaborative priorities; priorities need to be both IT and non-IT related to align with the business objectives and provide value.

IT Leaders Fails to Justify Projects

Adhering to a rigid rationalization process can be complex and costly. Play to your strengths and build an ARF based on your goals and limitations.

Info-Tech Insight

Misaligned portfolio roadmaps are known to lead teams and projects into failure!
Building an up-to-date portfolio roadmap that aligns business objectives to IT objectives will increase approval and help the business see the long-term value of roadmapping.

Don’t start in the middle; ensure you have the basics down

Application portfolio strategy practice maturity stages

1. Discover Your Applications
2. Improve
3. Transform

Disambiguate your systems and clarify your scope

Define the items that make up your portfolio.

Broad or unclear definitions of “application” can complicate the scope of rationalization. Take the time to define an application and come to a common understanding of the systems which will be the focus of your rationalization effort.

Bundling systems under common banner or taking a product view of your applications and components can be an effective way to ensure you include your full collection of systems, without having to perform too many individual assessments.

Scope

Info-Tech’s framework can be applied to portfolios of apps, products, and their related capabilities or services.

However you organize your tech stack, Info-Tech’s application rationalization framework can be applied.

Understand the multiple lenses of application rationalization and include in your framework

There are many lenses to view your applications. Rationalize your applications using all perspectives to assess your portfolio and determine the most beneficial course of action.

Application Alignment - Architect Perspective

How well does the entire portfolio align to your business capabilities?

Are there overlaps or redundancies in your application features?

Covered in Discover Your Applications.

Business Value - CEO Perspective

Is the application producing sufficient business value?

Does it impact profitability, enable capabilities, or add any critical factor that fulfills the mission and vision?

TCO - CIO Perspective

What is the overall cost of the application?

What is the projected cost as your organization grows? What is the cost to maintain the application?

End User

How does the end user perceive the application?

What is the user experience?

Do the features adequately support the intended functions?

Is the application important or does it have high utilization?

Technical Value - App Team Perspective

What is the state of the backend of the application?

Has the application maintained sufficient code quality? Is the application reliable? How does it fit into your application architecture?

Each perspective requires its own analysis and is an area of criteria for rationalization.

Apply the appropriate amount of rigor for your ARF based on your specific goals and limitations

Ideally, the richer the data the better the results, but the reality is in-depth analysis is challenging and you’ll need to play to your strengths to be successful.

There is no one-size-fits all rationalization. The primary goal of this blueprint is to help you determine the appropriate level of analysis given your motivations and goals for this effort as well as the limitations of resources, timeline, and accessible information.

Rationalize and build your application portfolio strategy the right way to ensure success

Big-Bang Approach

• An attempt to assess the whole portfolio at once.
• The result is information overload.
• Information gathered is likely incomplete and/or inaccurate.
• Tangible benefits are a long time away.

Covert Approach

• Information is collected behind the scenes and whenever information sources are available.
• Assumptions about the business use of applications go unconfirmed.

Corner-of-the-Desk Approach

• No one is explicitly dedicated to building a strategy or APM practices.
• Information is collected whenever the application team has time available.
• Benefits are pushed out and value is lost.

Iterative Approach

• Carried out in phases, concentrating on individual business units or subsets of applications.
• Priority areas are completed first.
• The APM practice strengthens through experience.

Sponsored Mandate Approach

• The appropriate business stakeholders participate.
• Rationalization is given project sponsors who champion the practice and communicate the benefits across the organization.

Dedicated Approach

• Rationalization and other APM activities are given a budget and formal agenda.
• Roles and responsibilities are assigned to team members.

Use Info-Tech’s Application Portfolio Assessment Diagnostic to add the end users’ perspective to your decision making

Prior to Blueprint: Call 1-888-670-8889 to inquire about or request the Application Portfolio Assessment.

Info-Tech Best Practice

The approach in this blueprint has been designed in coordination with Info-Tech’s Application Portfolio Assessment (APA) Diagnostic. While it is not a prerequisite, your project will experience the best results and be completed much quicker by taking advantage of our diagnostic offering prior to initiating the activities in this blueprint.

Use the program diagnostic to:

• Assess the importance and satisfaction of enterprise applications.
• Solicit feedback from your end users on applications being used.
• Understand the strengths and weaknesses of your current applications.
• Perform a high-level application rationalization initiative.

Integrate diagnostic results to:

• Target which applications to analyze in greater detail.
• Expand on the initial application rationalization results with a more comprehensive and business-value-focused criteria.

Use Info-Tech’s Application Rationalization Tool to determine and then visualize your application portfolio strategy

At the center of this project is an Application Rationalization Tool that is used as a living document of your:

1. Customizable Application Rationalization Framework

2. Recommendation Dispositions

3. Application Portfolio Roadmap (seen below)

Use the step-by-step advice within this blueprint to rationalize your application portfolio and build a realistic and accurate application roadmap that drives business value.

Central to our approach to application rationalization are industry-leading frameworks

Info-Tech uses the APQC and COBIT5 frameworks for certain areas of this research. Contextualizing application rationalization within these frameworks clarifies its importance and role and ensures that our assessment tool is focused on key priority areas. The APQC and COBIT5 frameworks are used as a starting point for assessing application effectiveness within specific business capabilities of the different components of application rationalization.

APQC is one of the world's leading proponents of business benchmarking, best practices, and knowledge management research.

COBIT 5 is the leading framework for the governance and management of enterprise IT.

In addition to industry-leading frameworks, our best-practice approach is enhanced by the insights and guidance from our analysts, industry experts, and our clients.

Our peer network of over 33,000 happy clients proves the effectiveness of our research.

Our team conducts 1,000+ hours of primary and secondary research to ensure that our approach is enhanced by best practices.

A public utility organization is using Info-Tech’s approach for rationalization of its applications for reduced complexity

Case Study

Industry: Public Sector

Source: Info-Tech Research Group

Challenge

• The public utility has a complex application portfolio, with a large number of applications custom-built that provide limited functionality to certain business groups.
• The organization needed to move away from custom point solutions and adopt more hosted solutions to cater to larger audiences across business domains.
• The organization required a comprehensive solution for the following:
  • Understanding how applications are being used by business users.
  • Unraveling the complexity of its application landscape using a formal rationalization process.

Solution

• The organization went through a rationalization process with Info-Tech in a four-day onsite engagement to determine the following:
  • Satisfaction level and quality evaluation of end users’ perception of application functionality.
  • Confirmation on what needs to be done with each application under assessment.
  • The level of impact the necessary changes required for a particular application would have on the greater app ecosystem.
  • Prioritization methodology for application roadmap implementation.

Results

• Info-Tech’s Application Portfolio Assessment Diagnostic report helped the public utility understand what applications users valued and found difficult to use.
• The rationalization process gave insight into situations where functionality was duplicated across multiple applications and could be consolidated within one application.
• The organization determined that its application portfolio was highly complex, and Info-Tech provided a good framework for more in-depth analysis.
• The organization now has a rationalization process that it can take to other business domains.

Info-Tech offers various levels of support to best suit your needs

DIY Toolkit

“Our team has already made this critical project a priority, and we have the time and capability, but some guidance along the way would be helpful.”

Guided Implementation

“Our team knows that we need to fix a process, but we need assistance to determine where to focus. Some check-ins along the way would help keep us on track.”

Workshop

“We need to hit the ground running and get this project kicked off immediately. Our team has the ability to take this over once we get a framework and strategy in place.”

Consulting

“Our team does not have the time or the knowledge to take this project on. We need assistance through the entirety of this project.”

Diagnostics and consistent frameworks used throughout all four options

Visualize your application portfolio strategy in three ways: do-it-yourself, Guided Implementations, or an onsite workshop

Application Rationalization Workshop Overview

Contact your account representative or email Workshops@InfoTech.com for more information.

Phase 1

Lay Your Foundations

Step 1.1: Define Motivations, Goals, and Scope

This step will walk you through the following activities:

1.1.1: Define the motivations, goals, and metrics for rationalization

1.1.2: Define “application” in your organization

1.1.3: Identify your core APM team, scope, and hand-offs

This step involves the following participants:

• Core APM Team
• CIO, IT Leaders, Steering Committee
• Enterprise and Application Architects
• PMO or PPM

Outcomes of this step

• Aligned understanding of the motivations and goals for your application rationalization and the metrics that will be used to measure success.
• Definition of “application” or the system types that will undergo rationalization, and an understanding of how other related systems will be involved.
• Agreement on scope of rationalization, accountabilities, and responsibilities from the core
• APM team and the outputs of rationalization as well as necessary inputs and proceeding activities taken on by other teams.

Review the different motivations of application rationalization and how that will affect your framework

What instigated the need for an improved or net-new application rationalization framework?

Portfolio Governance

Improves...

• Spending Risk
• Retirement of aged and low-value apps
• Business enablement

Impact on your rationalization framework:

• Less urgent
• As rigorous as appropriate
• Apply in-depth analysis as needed

Transformative Initiatives

Enables...

• Data migration
• Legacy modernization
• Infrastructure/cloud migration
• Standardizing platforms

Impact on your rationalization framework:

• Time sensitive
• Scope on impacted areas
• Need to determine specific dispositions
• Outcomes need to include detailed and actionable steps

Event-Driven Rationalization

Responds to...

• Mergers and acquisitions
• Regulatory and compliance change

Impact on your rationalization framework:

• Time constrained
• Lots of discovery work
• Primary focus on duplication

Application rationalization is more difficult to complete under reactive circumstances as shortened timelines cause teams to neglect the necessary depth of analysis. There is no escaping the analysis, but you can aim to Build an Application Rationalization Framework more suited for your circumstances.

Rationalization Approach: Your cadence is important

Info-Tech Insight

Organizations are quick to opt to the project approach, which to the naked eye appears cheaper. The problem with this approach is that upon completion, information is invariably not maintained and results quickly become stale and of little value to decision makers. The continuous approach is centered around keeping information accurate and up to date and routinely advising the business on their best options. This does not necessarily imply full-time resources, but a structured cadence in rationalization and APM.

Consider what will increase your effort, which can extend timelines or modify your cadence

Rationalization

Scope:

It goes without saying that the more apps you have the longer the rationalization will likely take.

But what you define as an “application” can range and quickly expand your scope.

Another consideration is the amount of distinct divisions within your organization (i.e. functional areas, regions, siloed depts./teams) that will require separate focused iterations.

Resources:

Another large consideration is the number and availability of the individuals who will collect, compile, and analyze the information, as well as building and presenting the results.

Target Portfolio:

What are the motivations driving rationalization. A focus on retirement may look quite different than a focus on transformation or migration.

Limitations:

What other limitations exist which will impact your timeline?

Related IT Capabilities:

Similar to APM maturity, related IT capabilities refers to any other existing IT functions that support the creation of the boarder application portfolio strategy, as seen in the following slide.

Business architects should be doing your application-capability alignment and the PMO should handle project intake and impact analysis.

When those IT capabilities aren’t in place, it is often the responsibility of the rationalization team to complete.

APM Maturity

APM maturity refers to the existing quality of documentation of your applications. Inventories missing info (e.g. cost, features) or not listing the appropriate personnel who can provide that info (product owners, tech SMEs) can make much of your rationalization effort chasing facts and figures instead of performing the actual analysis.

Where does your “rationalization” effort fit within the end-to-end application portfolio strategy program

At Info-Tech we view rationalization as a component of a greater application portfolio strategic initiative or APM practice. In this blueprint we focus on the core rationalization steps and strongly encourage that you first complete the proceeding steps.

Additionally, we recommend you review the following steps to rationalization and ensure that you have determined the necessary roles and responsibilities that follow a rationalization effort.

These are Info-Tech’s core rationalization steps, traditionally conducted by the APM role, with the result of recommended dispositions for your applications and a high-level portfolio roadmap.

1. Build in Application Portfolio Mgmt. Principles
2. Conduct Application Alignment
   • Ideally step 2 is the responsibility of your business architects, but often falls onto APM to complete or adapt.
3. Build Detailed Application Inventory
4. Set Your Rationalization Framework
5. Conduct Assessment & Assign Dispositions
6. Create an Application Portfolio Roadmap
7. Conduct an Impact Assessment
8. Determine the Details of the Disposition
9. Create Detailed Product Roadmaps

Depending on your org. structure and existing IT capabilities, the recommended dispositions may be handed off to PPM or product teams to perform the next steps, but often these responsibilities stick with the APM role.

Specific goals and your current maturity will impact how you should tailor your approach

Rationalization requires a proper understanding of the underlining business goals and objectives of your application strategy. Effectively identifying these drivers is paramount to gaining approval for any changes you plan to make to your application portfolio.

After identifying the drivers for your rationalization effort, your team will need to ensure that these will be built into the foundations on which you build your approach.

“What is most critical?”, but also “what must come first?”

Discover

• Collect Inventory
• Uncover Shadow IT
• Uncover Redundancies
• Anticipate Upgrades
• Predict Retirement

Improve

• Reduce Cost
• Increase Efficiency
• Reduce Applications
• Eliminate Redundancy
• Limit Risk

Transform

• Improve Architecture
• Modernize
• Enable Scalability
• Drive Business Growth
• Improve User Experience

Exercise: Define the motivations, goals, and metrics for rationalization

1.1.1 15-30 minutes

The objective of this exercise is to establish a common understanding of your organization’s motivations and goals of this effort and determine any appropriate customization to your approach. Why are you here? What does success look like?

Input:

• Overarching organizational strategy
• Application strategy

Output:

• Defined motivations and goals for application rationalization

Materials:

• Whiteboard
• Markers

Participants:

• Core APM Team
• CIO, IT Leaders, Steering Committee

1. Determine the motivations behind your rationalization effort. You may want to review any documents (e.g. project plans, year-end reviews, quarterly updates, and strategy documents) that can provide you with insights behind the strategic objectives of your business and IT stakeholders.
2. With the appropriate stakeholders, discuss the goals behind your application rationalization effort. Try to label your goals as either:
1. Short term: In this context, short term refers to more immediate goals used to represent the progress of activities for application rationalization and portfolio strategy. Likely these goals are more IT oriented.
2. Long term: In this context, long term refers to broader and more distant goals more related to the impact of the application rationalization and portfolio strategy. These goals should be more business oriented.
3. To help clearly define your goals, discuss appropriate metrics and targets for each goal. Often these metrics can be expressed as
1. Leading indicators: Metrics and targets used to gauge the success of your short-term goals and inform the progress of your application portfolio strategy.
2. Lagging indicators: Metrics and targets used to gauge the success of your long-term goals.

See the following slide for an example.

Example: Define the motivations, goals, and metrics for rationalization (continued)

Example:

Applications do not always mean the same thing to everyone

“Essentially applications are social constructions.” – Martin Fowler

Code

• A body of code that's seen by developers as a single unit.

Functionality

• A group of functionality that business customers see as a single unit.

Funding

• An initiative that those with the money see as a single budget.

What else?

How you define “application” can quickly expand your scope

Architectural Components

Middleware:

Used for designing and implementing the interaction and communication between mutually interacting software applications.

APIs:

A programmatic interface for an application's functions, data, or process.

Data:

An application data repository.

Infrastructure:

The underlying foundation of the system, which includes basic support services and hardware.

Applications:

?

The ambiguity of the term “application” can make application rationalization quite messy.

Many organizations choose to bundle the user-facing application with their appropriate various sub-systems, middleware, or peripherals and treat that as the singular item that they will rationalize. Essentially, this is taking a product view of your applications and relevant systems and it can be quite helpful to organizations in certain environments. Review Info-Tech’s Transition to Product Delivery blueprint to learn more.

Exercise: Define “application” in your organization

1.1.2 15-30 minutes

The objective of this exercise is to establish a common understanding of “application” for various stakeholders or groups across the organization. The definition is also intended to help define the scope and determine which types of items will undergo the application rationalization analysis and be featured in any resulting artifacts (e.g. portfolio roadmaps).

Input

• Current understanding of applications

Output

• Organization definition of “application”

Materials

• Whiteboard
• Markers

Participants

• Core APM Team
• CIO, IT Leaders, Steering Committee
• Enterprise and Application Architects

1. Review the various business (e.g. stakeholders, management, end users) and technical (e.g. development, infrastructure) perspectives of applications.
2. Using bullet points, brainstorm aspects of an application that should be included in your definition.
3. Consider different types of technical solutions, systems, or deployable assets (business applications, supporting applications, databases, middleware, operating systems, platforms, custom-built excel tools, etc.) and discuss which types will be included or excluded from your analysis.
4. Test to see if your included or excluded systems contradicts any of the points your team made in step 2.
5. Create a concise statement of the definition of “application” indicated by the types of systems that will undergo rationalization.
6. (Optional) Create addition categories and definitions for other types of applications. Build a chart indicating the analyses and repositories or artifacts these systems will belong to.

See the following pages for an example.

Example Part 1: Definition of “application” in your organization

1. Rough Definition:
• is any software…or software component
• processes data to generate a business result
• is deployed
• enables a business process
• is maintained by IT
2. Including
• Custom-build apps
• Commercial apps
• MS 360 apps
• What else?

Excluding

• Databases
• Excel-built tools
• Static webpage
• Middleware
• Operating systems
• Externally owned and maintained apps
• What else?
3. Definition: An application is any software, software component, or technical solution that is used to enable an established business process or generate business value and is maintained or managed by internal teams.

Example Part 2: System types and inclusion in application rationalization

Ensure you have the right roles in place to perform rationalization

“Corner of the Desk” Approach

• No one is explicitly dedicated to building a strategy or APM practices.
• Information is collected whenever the application team has time available.
• Benefits are pushed out and value is lost.

"Dedicated" Approach

• The rationalization effort is given a budget and formal agenda.
• Roles and responsibilities are assigned to team members.

Either treated as a practice or initiative, rationalization and APM need assigned roles, responsibilities, and accountabilities in place to operate effectively and achieve success.

Ask:

• Who is performing the different assessments?
• Who is collecting and compiling the information?
• Who is building the artifacts?
• Who is keeping it all accurate and up to date?

Application Portfolio Manager

The individual responsible for the health and evolution of the application portfolio. Accountable for providing portfolio information to various stakeholders and supporting key decisions regarding the strategic direction of applications.

Info-Tech Best Practice

Building your application portfolio strategy is not a one and done activity. The artifacts (inventory, roadmap, etc.) need to be kept accurate and up to date, and that only happens with dedicated resources and assigned accountability.

Info-Tech Best Practice

The application portfolio manager and their team is who this research is written for. However, the reality is many organizations don’t have explicitly dedicated resources in place. If these roles, and subsequent teams, are not assigned, the strategy is likely to be unsuccessful.

Exercise: Identify your core APM team, scope, and hand-offs

1.1.3 15-30 minutes

The objective of this exercise is to come to a mutual understanding of who is involved in the rationalization effort at a high level.

Input

• Understanding of goals and scope.

Output

• High-level roles for APM team

Materials

• Whiteboard
• Markers

Participants

• Core APM Team
• IT Leaders
• Enterprise and Application Architects
• PMO or PPM

1. Review the results of exercise 1.1.1 and 1.1.2.
2. Discuss or review the targeted number of applications to undergo rationalization.
3. Discuss how rationalization fits into APM, Enterprise Architecture, Project Portfolio Management, and other strategic initiatives or relevant practices within your IT organization.
4. Discuss where rationalization starts and ends. Consider other teams or individuals responsible for prerequisite inputs and define your targeted outputs.
5. Identify who is part of your core APM team or the team responsible for carrying out the rationalization effort.

Step 1.2: Iteration and Engagement Planning

This step will walk you through the following activities:

1.2.1: Iteration Planning

1.2.2: Iteration Prioritization

1.2.3: Develop a Communication Plan

1.2.4: Populate Application Rationalization Tool With First Iteration

This step involves the following participants:

• Core APM Team
• Business Relationship Managers
• Communication Department

Outcomes of this step

• First iteration or group of applications to test the application rationalization framework.
• Subsequent iterations and application groupings, listed and prioritized.
• Lists of appropriate application SMEs to consult with and harvest relevant application data and information.
• Communication and engagement plans for appropriate stakeholders, including executive management, department leaders, application owners, and SMEs.

Experience your biggest wins upfront: Explore different ways to narrow the approach of your first iteration

Target the Most Critical Applications

This approach allows you to look at the applications that are the most important to key operations. Improvements to these applications, particularly when usability, functionality, and data quality are low, will likely have the largest positive impact on your portfolio’s ability to drive business value. This group would also be the best to rationalize for large strategic or transformative goals.

Target Underperforming Applications

This approach will give you best opportunity to find areas for quick wins, such as implementing new training programs or lowering your seat count. Analyzing poor performance or underutilized applications will also expose areas of low value and provide opportunities to retire and reduce your number of applications.

Stick to a Single Business Unit

This approach will allow you to narrow your focus to a limited number of business capabilities and isolate a portion of your application architecture. Depending on organizational structure, it may limit the number of product owners and technical personnel you will need to involve in the assessment process. This approach can be particularly helpful for exposing redundancy.

Stick to a Single Business Process

This approach will allow you to narrow your focus to a single business process or operation that exists across business units, departments, or locations. This, again, will allow you to limit the number of product owners and technical personnel you will need to involve. This may be the best approach when aiming to eliminate redundancy during mergers and acquisitions.

Info-Tech Best Practice

While there is merit in any approach, your best chances at success are grouping apps and building your iterations based on shared SMEs who you will depend on for information. Typically, this means the single business unit or process approach are best.

Ensure your approach aligns to the goals of your project

Iteration planning is crucial to ensuring early benefits and strong participation from your business units

Taking an iterative approach means listing your application groups and determining an order of attack that will garner the strongest outcomes early in the process.

Consider these areas when prioritizing your iterations.

Participation from key application subject matter experts

• Consider application groups that have SMEs who will be willing and available to participate and who will act as champions of rationalization and communicate its benefits

IT Benefits

• Consider which application groups consist of:
  • A high estimate of redundant applications
  • Under-performing applications
  • High application costs
  • High presence of legacy systems

Business Benefits

• Consider which application groups have:
  • A high potential to benefit from application modernization
  • A high potential to benefit from a technology gap assessment
  • Low satisfaction with their application portfolio

Info-Tech Tip

Your first iteration will naturally be more trial and error and help you understand and adapt the methodology. Focus on a small number of apps – less on high-value opportunities and more on a stronger familiarity with the applications and a willingness to participate from necessary stakeholders.

Review who may need to be involved during rationalization; their willingness to participate is a large factor in success

Application rationalization is just one large data collection effort.

The application portfolio manager or team conducting the rationalization will need to interview many different stakeholders and leverage many different tools or information sources. Rationalization becomes considerably more challenging if these roles aren’t willing to participate or fail to see the benefit from their perspective. Take the time to consider who may be difficult to engage.

Application Rationalization

Application Alignment

• Business Architects
• Enterprise Architects
• Application Architects
• Business Unit/Process Owners
• Capability Maps
• Process Maps

Business Value

• Executives/C-Suite
• Steering Committee
• Product Owners
• Business Unit/Process Owners
• Mission Vision and Value Statements

TCO

• Operations Managers
• Maintenance Managers
• Vendor Managers
• Finance and Acct.
• ALM tools
• Service Desk Tools
• Vendor Contracts
• General Ledger

End User

• Product Owners
• Key Users
• End Users
• Customers
• Survey Tools
• Feedback Tools

Technical Health

• Development Mangers
• Maintenance Manager
• Operations Manager
• Solution Architects Engineers
• Data Managers
• Security Managers
• ALM Tools
• Service Desk Tools
• APM Tools

Exercise Part 1: Iteration planning

1.2.1. 1 hour

The objective of this exercise is to establish the list and order of the application groups that will undergo rationalization. Please note, parts 2 and 3 (instruction steps 6-8) and the subsequent exercise of engagement plans are more appropriate after completion of your first iteration and any retrospective discussions.

Input

• Organizational structure
• Rationalization priorities

Output

• First Iteration
• Iteration attack plan
• List of relevant SMEs

Materials

• Whiteboard
• Markers

Participants

• Core APM Team

1. Review the motivations and goals established in exercise 1.1.1.
2. Explore the different approaches to grouping sub-sets of applications and discuss their pros and cons:
   1. Target critical applications.
   2. Target under-performing applications.
   3. Stick to a single business unit.
   4. Stick to a single business process.
   5. Any alternative method that’s makes sense for you. If there are logical groupings of applications based on shared resources and SMEs, you will be better off building your iterations to meet that structure.
3. Consider the size of your iterations. Info-Tech recommends your first iteration is sized at five or less and subsequent iterations range from 10 to 15 applications.
4. Break down your application groups based on your approach.
5. Select your group for your first iteration and establish the owners and appropriate SMEs for these applications. Consider the following SME types: Product Owner, Business Process Owners, Technical Owners, Support Owners, Maintenance Managers, Operations Managers, Development Managers, and Solution Architects.

See the following page for an example.

Example Part 2: Iteration planning

1.2.1

NB: Focus on other application groups after completion of first iteration.

6. Adapt and continue to populate this table upon completing first iteration.

Exercise Part 3: Iteration Planning

1.2.1

7. For each application group the following.
   1. The willingness of the participants: Often, this factor is not well understood, and it may take some effort to open a dialogue between your team and these business unit representatives to communicate the need and benefits for this analysis. Identify which business units you suspect will be holdouts.
   2. IT benefits: By now you should have a stronger sense of where your trouble areas are. Consider where you have poor visibility and have experienced a number of incidents due to this lack of exposure. Also consider business units that have similar capabilities and the potential for redundancy between the two. It may be most beneficial to assess these two back to back.
   3. Business benefits: Based on your knowledge, consider which business units are not strongly supported by IT applications, have a lower satisfaction with the applications portfolio, or, most importantly, have been labeled a priority for IT improvement by the organization’s executive leadership.
8. Based on these considerations, plot your business units on a matrix of “willingness to participate” and “potential to benefit.”

See the following page for an example.

Example: Iteration prioritization

1.2.2

Order of Iterations:

1. Corporate Services Apps
2. Mission Critical Apps
3. Finance Apps
4. Marketing Apps
5. Collaboration Tools
6. Facilities Apps

Exercise: Develop a communication plan (optional)

1.2.3 1 hour

The objective of this exercise is to develop a method to communicate with your business stakeholders, primarily any potential holdouts.

Input

• Iteration plan

Output

• Engagement and communication plan for business units

Materials

• Whiteboard
• Markers

Participants

• Core APM Team
• Business Relations
• Communication Dept.

1. Based on the considerations made in the previous exercise, determine where your stakeholders fall on a matrix of awareness (informed vs. uninformed) and sentiment for rationalization (supportive, indifferent, or resistant). You may also want to consider other stakeholders impacted or involved in rationalization, such as:
   1. CIO, CEO, C[x]O
   2. Application SMEs (Product Owners, Operations Managers)
2. Plot the stakeholders from those quadrants on a stakeholder engagement map.
3. Build a communication strategy based on your groupings. Consider the following:
   1. Who are your resistors? These individuals will actively detract from the project’s success if you don’t address their concerns.
   2. Who is indifferent? These individuals need to be further educated on the benefits of business architecture to have an informed opinion.
   3. Who are your supporters? These individuals will spread your message if you equip them to do so.
   4. Avoid these common mistakes: Do not jump to addressing resistor concerns first. Instead, equip your supporters with the information they need to help your cause and gain positive momentum before approaching resistors.

See the following page for an example.

Example: Develop a communication plan

Example: Stakeholder Engagement Map

Example: Develop a communication plan (continued)

Use Info-Tech’s Application Rationalization Tool

Info-Tech Deliverable

Populate the Application Rationalization Tool as you complete the activities and steps.

This tool is the central hub for the majority of the blueprint activities.

This tool is designed to be flexible to the specifics of your application rationalization framework. Therefore, the tool is customizable to the adaptations you apply to our default framework.

Use this tool with your first iteration. Then continue to populate it as you rationalize subsequent iterations.

Exercise: Populate the Application Rationalization Tool with first iteration

1.2.4 30 minutes-1 hours

The objective of this part of the exercise is to carry over your narrowed list into the Application Rationalization Tool and input basic application information.

Input

• First iteration narrowed scope of applications

Output

• Basic application information

Materials

• Application Rationalization Tool

Participants

• Core APM Team

1. Review exercise 1.2.1 and the subset of applications for your first iteration.
2. Input your list of applications into the “Application Entry” tab in the Application Rationalization Tool.
3. Collect the following information and populate the appropriate columns.
   1. Abbreviated Name: (For the purposes of visual representations of your portfolio.)
   2. Application Type: Determine whether the application is COTS, home-grown, SaaS, hybrid, or other.
   3. Current Status: Determine whether the application is active, inactive, in repair, or in progress.
   4. Current Version/Release: The version or release number of the application.
   5. Number of Users: The number of individuals that actively use the application.
   6. Lifecycle Stage: Where the application is in its lifecycle.

Document results in the Application Rationalization Tool in the “Current Application Inventory” tab.

Phase 2

Plan Your Application Rationalization Framework

Step 2.1: Dispositions and Application Assessments

This step will walk you through the following activities:

2.1.1: Select and adapt your rationalization dispositions

2.1.2: Determine and review your assessments for rationalization

This step involves the following participants:

• Core APM Team

Outcomes of this step

• First iteration or group of applications to test the application rationalization framework.
• Subsequent iterations and application groupings listed and prioritized.
• Lists of appropriate application SMEs to consult with and harvest relevant application data and information.
• Communication and engagement plans for appropriate stakeholders, including executive management, department leaders, application owners, and SMEs.

The core outcome of rationalization is an assigned disposition for each of your applications

Disposition: The intended strategic direction or course of action for an application.

Expand or adapt Info-Tech’s dispositions to better fit the goals of your rationalization

Modernize

Enhance (upgrade)

Move application to a newer version or release.

Re-Platform

Move application to a more modern hardware/OS, translate application to new language, or reuse code in a modern environment.

Remediate

Refactor application to a better structure to improve integration and flexibility.

Maintain

Sustain

Continue with application as is

Retrain

Train users on core functionalities and features of application.

Support

Develop a custom support model to improve the maintenance and performance of the application.

Consolidate

Absorb

Adapt and configure application to handle operations transferred from redundant systems.

Merge

Combine functionality onto a common platform.

Retire

Decommission

Eliminate application altogether.

Replace

Eliminate application and replace with a new or alternative system.

Exercise: Select and adapt your rationalization dispositions (optional)

2.1.1 15 minutes

The objective of this exercise is to modify Info-Tech’s recommended set of dispositions to fit the unique goals of your application rationalization effort.

Input

• Goals and limitations

Output

• Set of dispositions

Materials

• Whiteboard and markers
• Application Rationalization Tool

Participants

• Core APM Team

Document results in the Application Rationalization Tool in the Disposition Selection tab.

Info-Tech strongly encourages applying all five lenses, but adjust the depth appropriately for your goals and limitations

Review the five lenses model to determine which assessments are necessary or what degree of rigor should be applied for each assessment, given your goals and limitations.

Understand the various lifecycle stages of applications and how they impact rationalization

An application goes through four distinct lifecycle stages

WHY THIS IS IMPORTANT

Lifecycle stage influences what you should expect in terms of value. Starting low, value will eventually rise, plateau, and drop off over time.

Making this distinction is important as there is less need to rationalize new and investment-justified Birth or Growth apps (outside of redundancies).

Mature and EOL apps, however, should be the main focus of rationalization, which really can be viewed as essentially determining which Mature or EOL apps are worth an increased investment and a return to the growth stage and which should be left alone or appropriately phased out.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

There is no in-depth lifecycle stage assessment. Simply assign a stage. When in doubt, apply other analyses to find the appropriate disposition.

Understand application lifecycle stages

BIRTH

This phase includes formulating the initial business plan for an application and how it will best serve the needs of a particular business unit. The application becomes familiarized by end users as the business provides training and documentation on how to use its functionalities.

GROWTH

The initial growth phase of an application involves the improvement and customization of a particular application. The application begins to provide more business value to the organization as users become more accustomed to and effective in using its features to complete their tasks.

MATURITY

The application’s business value begins to stabilize as its associated costs increase and its ability to meet the demands laid out in the growth phase diminish.

END OF LIFE (EOL)

The application is at risk of losing its business value and the cost to maintain the application is beginning to outweigh its value. Ultimately, an application must be retired and possibly replaced as its business value has eroded.

Understand different approaches to application alignment and determining functional overlap

Application alignment is key to determine overlaps and redundancies.

WHY THIS IS IMPORTANT

Aligning applications to their business use is the most important input and often hardest part of rationalization (so it has its own blueprint). This analysis will allow you to determine what features or functionality an app provides or is actually used by the business. Which in turn will allow you to determine which apps are similar or redundant. This analysis will likely make rationalization decisions, specifically consolidation, much easier.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

Here the in-depth analysis is process mapping, including individual tasks and their alignment to your apps. This level of analysis is recommended when understanding of your portfolio is poor and concerns of redundancy, shadow IT, or M&A are primary motivations behind rationalization.

Application alignment can occur at multiple levels of granularity

CAPABILITY LEVEL

A capability is what an organization does. Creating an abstract of the business and mapping apps to capabilities provides high-level understanding of potential functional overlaps. This is best accomplished when the organization has a mature business architecture practice. Depending on how sub-capabilities have been defined, you maybe limited in your ability to determine “true redundancies.”

PROCESS LEVEL

A process is how the organization does it. The process level requires a deeper dive or investigation into how the business actually executes. It provides a stronger indication on functionality, but still may not include smaller shadow IT solutions or hidden uses and dependencies. This information is subject to change and inconsistencies from different user groups, which requires thorough and up-to-date analysis.

TASK LEVEL

Tasks make up a process. Achieving a task-level alignment to applications provides the most definitive understanding of functionality, user dependencies, and true redundancies, and is the best way to expose shadow IT. However, it requires more time and effort to uncover and is even harder to accurately maintain as it is much more subject to change and inconsistencies.

Understand the importance of reducing subjectivity and measuring the various kinds of business value

Business value can be ambiguous, but it is essential information for your apps.

WHY THIS IS IMPORTANT

Understanding the relative value of your apps is critical for determining if an app continues to justify its cost and delivers as intended, or which option should prevail when redundancies are found. Applying a consistent method, considering organizational priorities, measured through metrics is just as important, as it limits intangibles, uncertainty, and bias.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

Info-Tech's value measurement framework offers a more rigorous approach to quantifying value. This is most appropriate when value is poorly defined and ambiguous across the organization. It is also helpful with transformational motivations as this will help prioritizing many application dispositions.

High-level categories of business value

GENERATE REVENUE

Application functions that impact your organization’s ability to generate revenue or funding or are connected to immediate growth opportunities.

REDUCE COSTS

Applications that reduce overhead. They typically are less related to broad strategic vision or goals and more simply limit expenses that would occur had the product or service not been put in place.

ENHANCE SERVICES

Functions that enable business capabilities that improve the organization’s resources and operations or improve the end user’s experience.

REACH CUSTOMERS AND MARKETS

Application functions that enable and improve the interaction with customers or produce market information and insights.

Review Info-Tech’s Build a Value Measurement Framework for the detailed approach to measuring an application’s value.

Understand the ongoing and future costs associated with your applications

An app’s cost extends past vendor fees.

Cost:

• License
• Maintenance
• Upgrades
• Education
• Peripherals

WHY THIS IS IMPORTANT

Licenses and maintenance are invariably major items on a company’s books, but people can’t pinpoint why or which apps make up this spend. Decisions are made without the full picture, causing negative impacts on value for little reduction in cost. Collecting TCO on an individual-app basis shows that allocation and helps drive decisions towards efficient portfolios.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

Many experience diminishing value from TCO over-analysis. While license spend is easily acquired, maintenance is not and requires info sourced from ALM or service desk tools. Without these tools you’ll struggle, and tirelessly chasing exact figures won’t prove worthwhile. Apply a more thorough analysis when the information is available, or if Finance/ Accounting demand it. Otherwise, thoughtful estimations may suffice.

Understand common areas of cost.

LICENSING AND SUBSCRIPTIONS

Your recurring payments to a vendor.

Many SaaS applications require a license on a per-user basis. Review financial data and determine costs by looking at per-user or fixed rates charged by the vendor. Often these fees include support.

UPGRADE FEES

The forecasted vendor payment for software upgrades.

Mainly COTS applications will require enhancement or version upgrade fees. Determining these costs requires either anticipated vendor changes or leveraging the vendor roadmap.

MAINTENANCE LABOR

The cost of internal labor to maintain an app.

These stem from internal enhancements and upkeep. Calculate these costs with past spend (salaries, wages, person-hours worked) for your individual apps. This requires strong ALM traceability.

PERIPHERALS

The cost of additional components directly related to an app.

Many apps require peripheral components, such as storage, servers, and middleware. Ideally, these should be included in TCO. However, linking these sub-systems to an individual app is challenging and requires good judgement.

INDIRECT COSTS

Miscellaneous expenses necessary for an application’s use.

Expenses like end-user training, developer education, and admin are often neglected, but they are very real costs organizations pay for the app to function properly and provide value.

Assess the health of your application portfolio from the perspective of your end users

Leverage surveys to understand the end user’s perspective.

Use Info-Tech’s Application Portfolio Assessment to complete the picture.

WHY THIS IS IMPORTANT

The end user’s perspective is naturally important as they experience the app on a regular and more intimate basis. Consulting your end user allows you to extend past the application management or development perspective that tends to focus on technical aspects, as well as the executive perspective, which cares only for business outcomes.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

If your rationalization goals are in generally improving how IT serves the business, opposed to broader transformational goals, then the satisfaction levels of your end users becomes a more important criterion.

Understand the top concerns of your end-user perspectives

IMPORTANCE

Importance in this context refers to how necessary the application is for an end user to complete their job. This can also be used as a proxy for utilization. Low-importance applications are those with poor utilization rates.

SATISFACTION

Satisfaction refers to the sentiment your end users have with the features and functionality of the application. Do the features of the application function as intended? Does the application align to the business process it aims to support?

USABILITY

Usability refers to the level of satisfaction your end users have with the application’s user experience. Does the design of the application allow end users to perform their tasks with relative ease or minimal disruption?

Info-Tech Best Practice

Do not make assumptions with these performance indicators or use lengthy methods of collecting information. Use Info-Tech’s Application Portfolio Assessment to collect data on your end user’s perspective.

Understand the technical health of your applications

Your application’s back-end health and design is critical.

WHY THIS IS IMPORTANT

Many rationalization efforts hinge around a technical health for two main reasons. Naturally, the backend is less transparent, and therefore, requires more effort to determine areas of risk. Secondly, the non-visible issues are commonly neglected, build over time, and reach a tipping point where a more reactive rationalization occurs.

WHEN TO APPLY AN IN-DEPTH ANALYSIS

This area also succumbs to paralysis-by-analysis. “In-depth” includes collecting data around speed, capacity, etc. When not part of the current practice, it’s hard to justify the value of adding these measures. If your risk threshold is of concern, apply rigor where appropriate. Otherwise, leveraging your technical SMEs to gauge areas of health, based on their familiarity and influenced by some metrics, will prove more successful.

Technical health of your applications

MAINTAINABILITY (RAS)

RAS refers to an app’s Reliability, Availability, and Serviceability, in other words, its maintenance history. How often, how long, and how difficult is it for your resources to keep the application afloat and what are the resulting risks? This can include the root causes (i.e. technical debt, poor source code mgmt., or support structure).

TECHNICAL PERFORMANCE

Separate from functionality and appearance, does the application process data as timely and efficiently as needed?

INTEROPERABILITY

The degree to which an app is integrated with current systems. Apps require comprehensive technical planning and oversight to ensure they connect within the greater application architecture.

ADAPTABILITY

How easily can the app be modified or scaled to changes in business needs?

SECURITY

Has the app and support model been designed to mitigate and respond quickly to security risk threats? Holes in security coverage can lead to numerous instances of decreased value and, more importantly, harm to the business.

A decision tree presents a simplified view of rationalization and the separate application assessments involved

It helps us start to understand which application assessments need to occur to effectively rationalize.

The problem is most of these decision points are not yes or no questions, require many points of information, and can range in what an appropriate disposition should be.

Again, rationalization and the individual assessment depend on available SMEs and information sources

Application rationalization is just one large data collection effort.

The application portfolio manager or team conducting the rationalization will need to interview many different stakeholders and leverage many different tools or information sources. Rationalization becomes considerably more challenging when you lack these tools or lack the clarity of who fills these roles as they relate to individual applications. Take the time to determine what information is necessary and what information can reasonably be collected prior to defining your application rationalization framework.

Application Rationalization

Application Alignment

• Business Architects
• Enterprise Architects
• Application Architects
• Business Unit/Process Owners
• Capability Maps
• Process Maps

Business Value

• Executives/C-Suite
• Steering Committee
• Product Owners
• Business Unit/Process Owners
• Mission Vision and Value Statements

TCO

• Operations Managers
• Maintenance Managers
• Vendor Managers
• Finance and Acct.
• ALM tools
• Service Desk Tools
• Vendor Contracts
• General Ledger

End User

• Product Owners
• Key Users
• End Users
• Customers
• Survey Tools
• Feedback Tools

Technical Health

• Development Mangers
• Maintenance Manager
• Operations Manager
• Solution Architects Engineers
• Data Managers
• Security Managers
• ALM Tools
• Service Desk Tools
• APM Tools

Exercise: Determine and review your assessments for rationalization

2.1.2 45 minutes

The objective of this exercise is to determine an initial ARF at a high-level and discuss any gaps in terms of the availability of necessary data points and additional collection methods that will need to be applied.

Input

• Goals and limitations
• Knowledge of any prior analysis

Output

• Initial scope for key application assessments for ARF

Materials

• Whiteboard and Markers

Participants

• APM Team

1. (Optional) Review the results of exercises 1.1 and 2.1 and adapt the Application Rationalization Decision Tree to fit your disposition model and rationalization goals.
2. List the different assessments that will included in your ARF. Info-Tech strongly recommends you include:
1. Lifecycle Stage Assessment
2. Application Alignment (if incomplete, please refer to Discover Your Applications)
3. Business Value Assessment
4. Total Cost of Ownership Assessment
5. End-User Performance Assessment
6. Technical Performance Assessment
3. For each assessment, brainstorm with your teams:
   • Has the appropriate data been collected, or has any analysis been performed?
   • If yes, what is the quality of the information? Is it appropriate, up to date, accurate, and sufficient for your rationalization goals?
   • If no, what is the availability of said information and how much effort will it require to collect?
   • What method will you apply to collect any outstanding information?
   • What degree of rigor will you apply for this assessment (i.e. 1-10 scale vs. comprehensive metric-based measurements)?
   • Highlight the assessment or data collection that you predict will be difficult.

See the following page for an example.

Example: Determine the assessments for rationalization

2.1.2

Exercise: Determine and review your assessments for rationalization (continued)

2.1.2 45 minutes

The objective of this exercise is to structure the individual assessments that comprise the overall rationalization process.

Input

• Goals and limitations
• Knowledge of any prior analysis

Output

• Initial scope for key application assessments for ARF

Materials

• Whiteboard and Markers

Participants

• Whiteboard and Markers

4. Based on your initial ARF, expand on exercise 1.2.1 to include any additional subject matter experts who will need to be included in your rationalization effort.
5. Review the appropriateness of Info-Tech’s default approach outlined in Phase 3, Step 1. Based on your ARF, you may need to alter various aspects of the assessments laid out in this step.

Phase 3

Test and Adapt Your Application Rationalization Framework

Step 3.1 Perform First Iteration

This step will walk you through the following activities:

3.1.1: Initial Criteria

3.1.2: Functional Overlaps and Redundancies

3.1.3: Define and weigh business value drivers

3.1.4: Measure business value

3.1.5: Measure TCO

3.1.6: Business Value and TCO Comparison

3.1.7: End-User Perspective

3.1.8: Technical Health Assessment

This step involves the following participants:

• Core APM Team
• Application SMEs
• Authorities on Business Value
  • Executive Leadership, Steering Committee, etc.

Outcomes of this step

• Defined rationalization criteria for App Alignment, Business Value, TCO, End-User Perspective, and Technical Health.
• Defined and weighed business value drivers.
• Business value scores for each application.
• TCO measurements and projection for each application.
• End-user satisfaction scores for each application.
• Technical health gauge for each application.

About Step 3.1 - Perform First Iteration

This is intended to provide a default Application Rationalization Framework and toolset. This can be used to rationalize your applications; however, it does rely on a specific approach that requires some specific assessments and data inputs.

In this approach:

• We have assumed you have previously determined the business capabilities of your applications. If you have not, Info-Tech strongly recommends you review the blueprint, Discover Your Applications.
• We apply a Value measurement framework (VMF) to determine the business value of your applications. For a full review of this assessment, refer to Build a Value Measurement Framework.
• We recommend using the Application Portfolio Assessment Diagnostic to determine the end-user satisfaction of your applications.
• We provide an additional tool to produce a detailed TCO of your applications.

Info-Tech strongly recommends you:

• Review the appropriateness of this approach based on your goals and the details established for your initial ARF defined in exercise 2.1.2.
• If you continue to apply this default approach, adapt the approach and settings within the toolset based on the results of your first iteration.

About Info-Tech’s Application Rationalization Tool

The main function built into Info-Tech’s Application Rationalization Tool is essentially a disposition scoring tool.

Each app is given a recommended disposition based on scores derived from:

• Rationalization Criteria. The results collected form the various application assessments become the inputs of the tool.
• Disposition Settings. The scoring system that dictates how each input impacts each of the recommend disposition options.

The tool is currently populated with default settings, which should be altered to meet the customizations in your rationalization framework. The four main steps for using and adapting the disposition function of the Application Rationalization Tool are:

1. List your dispositions In the “Dispositions Selection” tab, adapt our default list of dispositions to better meet the goals of your rationalization effort. The Tool allows for 14 disposition options.

2. Input the results from your various assessments. In the “Rationalization Criteria” tab, customize the Tool to the details of your various applications assessment and carry over the results for each of your applications. The Tool allows for 20 rationalization criteria factors.
3. Adapt disposition settings In the “Dispositions Selection” tab, adapt our default scoring setting to produce the recommended dispositions in line with the goals of your rationalization effort. The Tool allows you to modify the weight of each factor.
4. Review Recommended Dispositions In the “Disposition Recommendations” tab, review the outputs from the Rationalization Tool and assign the appropriate disposition for your apps. The Tool will recommend the top disposition and showcase the score for other options.

*Reminder: This tool recommends dispositions based on the inputs and settings. It is meant to facilitate and aid the decision-making process, not replace it. Rationalization, and assigning dispositions to your apps, will still require additional key factors and conversations with relevant stakeholders.

Exercise: Determine your rationalization criteria – initial considerations

3.1.1 30 minutes

The objective of this exercise is to define the rationalization criteria and disposition settings, essentially filter out certain options, for other application characteristics.

Input

• Goals and limitations
• Application knowledge

Output

• Rationalization criteria and disposition settings for application characteristics

Materials

• Whiteboard and Markers
• Application Rationalization Tool

Participants

• Core APM Team
• Relevant Application SMEs

1. Consider what application characteristics, outside of Info-Tech’s Five lenses model (Lifecycle Stage, Type, etc.), should impact the recommended disposition.
2. For each rationalization criteria, select up to five categories an application would belong to.
3. For each category, identify the impact on recommended dispositions.
4. The Application Rationalization Tool can include five rationalization criteria for this section.

5. Appropriately modify the Application Alignment Column in the “Rationalization Criteria” tab and adjust the disposition scoring in the “Disposition Settings” tab.
6. Apply this assessment to your first iteration of applications.

Document results in the Application Rationalization Tool in the Rationalization Criteria and Disposition Settings tabs.

Application alignment requires a significant effort; Info-Tech recommends conducting a separate and prerequisite initiative

Info-Tech has several resources that will help you align your applications to their business use and determine areas of redundancy. We strongly recommend collecting this information prior to rationalization.

Use Info-Tech’s Discover Your Applications to launch your application portfolio strategy. This research provides the fundamentals of APM and acts as the prerequisite to application rationalization. Through the primary activity of application alignment, this blueprint will help you uncover all your applications, identify and define their various features and functionality, and determine which apps overlap.

Use Info-Tech’s Bridge IT and the Business With Business Architecture to launch a business architecture practice as well as build capability maps out of your organization’s value streams.

Engage, model, and drive the business forward with capability maps that highlight the areas of the business featured in your strategy.

Use Info-Tech’s Industry Reference Architecture to kick-start your capability mapping. Leveraging our industry-focused templates will help you avoid wasting time and money reinventing the wheel.

Reference architectures are built on years of industry expertise, honed by analysts working with real IT professionals in your industry.

Distinguish functional overlap from redundancy

While the difference between overlap and redundancy may just be semantics, you need to determine the degree to which your applications have duplicate functionality.

Truly redundant apps, which offer the same features, are “low-hanging fruit.” When identified, the appropriate action is to determine the most cost-beneficial option and propose a transition of processes onto a single app.

This scenario shows two apps with similar functionality for similar processes. This level of overlap is less common, but certainly can happen with siloed organizations containing business units with similar capabilities, after M&A, and when APM practices are quite immature.

More likely your redundancies will have some, but not complete, overlap. This scenario is still a candidate for consolidation but will require more analysis as the disposition will cause larger business impact.

Here, both apps offer features enabling process 1, but the second app lacks the functionality for process 2. Consolidation onto app 1 and removal of app 2 may be viable, but feature D may link to another capability, complicating the business case for that disposition.

Exercise: Determine your rationalization criteria – Functional Overlaps and Redundancies

3.1.2 30 minutes

The objective of this exercise is to define the rationalization criteria and disposition settings for application redundancies.

Input

• Goals and limitations
• Application alignment results and artifacts

Output

• Rationalization criteria and disposition settings for functional overlap disposition scoring
• Listed overlaps

Materials

• Whiteboard and marker
• Application Rationalization Tool

Participants

• Core APM Team
• Business Architects
• Relevant Application SMEs

1. On a scale of 1 to 5 define your different degrees of application redundancy.
2. For each degree of redundancy, identify the impact of recommended dispositions.

3. Appropriately modify the Application Alignment Column in the “Rationalization Criteria” tab and adjust the disposition scoring in the “Disposition Settings” tab.
4. Apply this assessment to your first iteration of applications.

Document results in the Application Rationalization Tool in the Rationalization Criteria and Disposition Settings tabs.

Measure your product or services with Info-Tech’s Value Measurement Framework (VMF) and value scores

The VMF provides a consistent and less subjective approach to generating a value score for an application, product, service, or individual feature by using business-defined value drivers and application-specific value metrics. See Info-Tech's full approach with Build a Value Measurement Framework.

Use Info-Tech’s Value Calculator Tool to measure your application’s value based on alignment and business outcomes

This tool will help you:

Define and weight the value drivers of your organization, which will be used to measure the relative value of your individual applications.

Produce balanced value scores for each of your applications based on their impact on business outcomes and alignment to organizational priorities.

Use this tool for exercises 3.1.3-4.

Business value is best defined and measured by the combined effort and perspective of both IT and the business

Buy-in for your IT strategy comes from the ability to showcase value. IT needs to ensure it has an aligned understanding of what is valuable to the organization.

First, priorities need to be established by the business. Second, IT can build a partnership with the business to determine what that value means in the context of IT products and services.

Business Value of Products and Services:

The Business:

• Keepers of the organization’s mission, vision, and value statements that define IT success. The business maintains the overall ownership and evaluation of the products along with those most familiar with the capabilities or processes enabled by technology.

IT:

• Technical subject matter experts of the products and services they deliver and maintain. Each IT function works together to ensure quality products and services are delivered up to stakeholder expectations.

Engage key stakeholders to reach a consensus on organizational priorities and value drivers

Engage these key players to create your value drivers:

Value Drivers:

• CEO
  • Who better holds the vision or mandate of the organization than its leader? Ideally they are front and center for this discussion.
• CIO
  • IT must ensure that technical/practical considerations are taken into account when determining value.
• CFO
  • The CFO or designated representative will ensure that estimated costs and benefits can be used to manage the budgets.
• VPs
  • Application delivery and mgmt. is designed to generate value for the business. Senior management from business units must help define what that value is.
• Evaluators (PMO, PO, APM, etc.)
  • Those primarily responsible for applying the VMF should be present and active in identifying and carefully defining your organization’s value drivers.
• Steering Committee
  • This established body, responsible for the strategic direction of the organization, is really the primary audience.

Value is based on business needs and vision

Value is subjective. It is defined through the organization’s past achievement and its future objectives.

There must be a consensus view of what is valuable within the organization, and these values need to be shared across the enterprise.

Instead of maintaining siloed views and fighting for priorities, all departments must have the same value and purpose in mind.

These factors – purpose and mission, past achievement and current state, vision and future state, and culture and leadership – impact what is valuable to the organization.

Value derives from the mission and vision of an organization; therefore, value is unique to each organization

Business value represents what the business needs to do to achieve its target state. Establishing the mission and vision helps identify that target state.

Mission

Why does the company exist?

• Specify the company’s purpose, or reason for being, and use it to guide each day’s activities and decisions.

Vision

What does the organization see itself becoming?

• Identify the desired future state of the organization. The vision articulates the role the organization strives to play and the way it wants to be perceived by the customer.
• State the ends, rather than the means, to get to the future state.

Business Value

What critical factors fulfill the mission and vision?

• Articulate the important capabilities the business should have to achieve its objectives. All business activities must enable business value.
• Communicate the means to achieve the mission and vision.

Understand the many types of value your products or services produce

Competent organizations know that value cannot always be represented by revenue or reduced expenses. However, it is not always apparent how to envision the full spectrum of value sources. Dissecting value by the benefit type and the value source’s orientation allows you to see the many ways in which a product or service brings value to the organization.

Financial Benefits vs. Improved Capabilities

Financial benefits refer to the degree to which the value source can be measured through monetary metrics and is often quite tangible.

Human benefit refers to how a product or service can deliver value through a user’s experience.

Inward vs. Outward Orientation

Inward refers to value sources that have an internal impact and improve your organization’s effectiveness and efficiency in performing its operations.

Outward refers to value sources that come from your interaction with external factors, such as the market or your customers.

Increase Revenue

Product or service functions that are specifically related to the impact on your organization’s ability to generate revenue.

Reduce Costs

Reduction of overhead. They typically are less related to broad strategic vision or goals and more simply limit expenses that would occur had the product or service not been put in place.

Enhance Services

Functions that enable business capabilities that improve the organization’s ability to perform its internal operations.

Reach Customers

Application functions that enable and improve the interaction with customers or produce market information and insights.

Expand past Info-Tech’s high-level value quadrants and identify the value drivers specific to your organization

Different industries have a wide range of value drivers. Consider the difference between public and private entities with respect to generating revenue or reaching their customers or other external stakeholders.

Even organizations in the same industry may have different values. For example, a mature, well-established manufacturer may view reputation and innovation as its highest-priority values, whereas a struggling manufacturer will see revenue or market share growth as its main drivers.

Value Drivers

• Increase Revenue
  • Revenue Growth
  • Data monetization
• Reduce Costs
  • Cost optimization
  • Labor reduction
• Enhance Services
  • Collaboration
  • Risk and compliance
• Reach Customers
  • Customer experience
  • Trust and reputation

You do not need to dissect each quadrant into an exhaustive list of value drivers. Info-Tech recommends defining distinct value drivers only for the areas you’ve identified as critical to your organization’s core goals and objectives.

Exercise: Define and weigh your value drivers

3.1.3 1 hour

The objective of this exercise is to establish a common understanding of the different values of the organization.

Input

• Mission, vision, and value statements

Output

• List and description of value drivers

Materials

• Whiteboard
• Markers

Participants

• Business value authorities
• Owner of value measurement framework

1. Place your business value authorities at the center of this exercise.
2. Collect all the documents your organization has on the mission and vision, strategy, governance, and target state, which may be defined by enterprise architecture.
3. Identify the company mission and vision. Simply transfer the information from the mission and vision document into the appropriate spaces in the business value statement.
4. Determine the organization’s business value drivers. Use the mission and vision, as well as the information from the collected documents, to formulate your own idea of business values.
5. Use value driver template on the next slide to define the value driver, including:
   • Value Driver Name
   • Description
   • Related Business Capabilities – If available, review business architecture materials, such as business capability maps.
   • Established KPI and Targets – If available, include any organization-wide established KPIs related to your value driver. These KPIs will likely be used or influence the metrics eventually assigned to your applications.

See the following page for an example.

Example Value Driver

Exercise: Weigh your value drivers

3.1.3 30 minutes

The objective of this exercise is to prioritize your value drivers based on their relative importance to the business.

Input

• Mission, vision, and value statements

Output

• Weights for value drivers

Materials

• Whiteboard
• Markers

Participants

• Business value authorities
• Owner of value measurement framework

1. Again, place the business value authorities at the center of this exercise.
2. To determine priority, divide 100% among your value drivers, allocating a percentage to each based on its relative importance to the organization.
3. Normalize those percentages on to a scale of 1 to 10, which will act as the weights for your value drivers.

See the following page for an example.

Example: Weigh your value drivers

3.1.3 30 minutes

Carry results over to the Value Calculator

3.1.3

Document results of this activity in the “Value Drivers” tab of the Value Calculator.

Ensure you’ve listed each application’s uses (functions, features, capabilities, etc.) and user groups

An application can enable multiple capabilities, perform a variety of functions, and have a range of different user groups. Therefore, a single application can produce multiple value sources, which range in type, impact, and significance to the business’ overarching priorities.

To effectively measure the overall value of an application you need to determine all the ways in which that application is used and apply a business-downward view of your applications.

Business Capability

• Sub-capability
• Process
• Task

Application

• Module
• Feature
• Function

Aim for Business Use

Simply listing the business capabilities of an app can be too high level. Regardless of your organization’s terminology, you need to establish all the different uses and users of an application to properly measure all the facets of its value.

Additional Research

Discover Your Applications helps you identify and define the business use and features of your applications.

The business outcome is the impact the product or service has on the intended business activity

Business outcomes are the business-oriented results produced by organization’s capabilities and the applications that support those capabilities.

The value source is, in essence, “How does the application impact the outcome?” and this can be either qualitative or quantitative.

Adapted from Agile Coach Journal

Exercise: Measure value (part 1) – Identify your value sources

3.1.4 30 minutes

The objective of this exercise is to establish the different value sources of a product or service.

Input

• Product or service knowledge
• Business process knowledge

Output

• List of value sources

Material

• Whiteboard
• Markers

Participants

• Owner of value measurement framework
• Product or service SMEs

1. List the items you are producing an overall balance value score for. These can be products, services, projects, applications, product backlog items, epics, etc.
2. For each item, list its various business outcomes in the form of a description that includes:
   1. The item being measured
   2. Business capability or activity
   3. How the item impacts said capability or activity

Consider applying the user story format for future value sources or a variation for current value sources.

As a [user], I want to [activity] so that I get [impact].

Exercise: Measure value (part 2) – Align to a value driver

3.1.4 30 minutes

The objective of this exercise is to determine the value driver for each value source.

Input

• Product or service knowledge
• Business process knowledge

Output

• Value driver weight

Materials

• Whiteboard
• Markers

Participants

• Owner of value measurement framework
• Product or service SMEs

1. Align each value source to a value driver. Choose between options A and B.
   1. Using a whiteboard, draw out a 2x2 business value matrix or an adapted version based on your own organizational value drivers. Place each value source in the appropriate quadrant.
   1. Increase Revenue
   2. Reduce Costs
   3. Enhance Services
   4. Reach Customers
   2. Using a whiteboard or large sticky pads, create a section for each value driver. Place each value source with the appropriate value driver.

See the following slide for an example.

Example: Brainstorm the different sources of business value (continued)

3.1.4

Example:

Carry results over to the Value Calculator

3.1.4

Document results of this activity in the Value Calculator in the Item {#} tab.

Aim, but do not reach, for SMART metrics

Creating meaningful metrics

Specific

Measurable

Achievable

Realistic

Time-based

Follow the SMART framework when adding metrics to the VMF.

The intention of SMART goals and metrics is to make sure you have chosen a gauge that will:

• Reflect the actual business outcome or value source you are measuring.
• Ensure all relevant stakeholders understand the goals or value you are driving towards.
• Ensure you have the means to capture the performance.

Info-Tech Insight

Metrics are NOT a magical solution. They should be treated as a tool in your toolbox and are sometimes no more than a rough gauge of performance. Carefully assign metrics to your products and services and do not disregard the informed subjective perspective when SMART metrics are unavailable.

Info-Tech Best Practice

One last critical consideration here is the degree of effort required to collect the metric compared to the value of the analysis you are performing. Assessing whether to invest in a project should apply the rigor of carefully selecting and measuring value. However, performing a rationalization of the full app portfolio will likely lead to analysis paralysis. Taking an informed subjective perspective may be the better route.

Exercise: Measure value (part 3) – Assign metrics and gauge value fulfillment

3.1.4 30-60 minutes

The objective of this exercise is to determine an appropriate metric for each value source.

Input

• Product or service knowledge
• Business process knowledge

Output

• Value driver weight

Materials

• Whiteboard
• Markers

Participants

• Owner of value measurement framework
• Product or service SMEs

See the following page for an example.

Carry results over to the Value Calculator

3.1.4

Document results of this activity in the Value Calculator in the Item {#} tab.

The full view of TCO will likely extend past what might appear in your general ledger

TCO means taking a comprehensive view of not only the software, but also the related technical components and services in place to maintain the app and ensure it’s used properly and delivers its intended value.

Info-Tech recommends viewing areas of cost in five categories:

LICENSE FEES

Your recurring payments to a vendor.

Many SaaS applications require a license on a per-user basis. Review financial data and determine costs by looking at per-user or fixed rates charged by the vendor. Often these fees include support.

UPGRADE FEES

The forecasted vendor payment for software upgrades.

Mainly COTS applications will require enhancement or version upgrade fees. To determine these costs requires an either anticipated vendor changes or leveraging the vendor roadmap.

MAINTENANCE

The cost of internal labor to maintain an app.

These costs stem from the internal enhancements and upkeep to your apps. Calculate these costs by reviewing past spend (salaries, wages, person-hours-worked) for your individual apps. This requires strong ALM traceability.

PERIPHERALS

The cost of additional components directly related to an app.

Many apps require peripheral components, such as storage, servers, and middleware. These should be included in TCO. However, linking these sub-systems to an individual app is challenging and requires good judgement.

INDIRECT COSTS

Miscellaneous expenses necessary for an application’s use.

Expenses like end-user training and developer education are often neglected, but they are very real costs organizations must pay for the app to function properly and provide value.

Different types of applications will find their largest costs in different areas.

You’re not an accountant; collecting and calculating TCO relies more on thoughtful estimates than exact figures

For the purposes of rationalization, TCO includes what the app costs to maintain now and what the app will continue to cost over a reasonable timeline (Info-Tech’s recommends no more than five years).

You must leverage current and historical operational expenses and trends to project TCO. Initial development fees or past capital expenses are irrelevant, unless used in some way to accurately project future costs.

This does NOT necessarily mean collect or project every single dollar but ensure you have considered the full picture of what an application costs.

There are a variety of sources to collect TCO:

ALM and Service Desk tools: Leverage your existing toolset to determine person hours worked on individual apps, which can infer the cost of internal maintenance.

Vendor Management: Reviewing software contracts provides an easier means to determining costs of COTS or SaaS applications.

General Ledger: Leveraging your finance/accounting department and financial data to collect exact figures. *This is unlikely to be kept at an individual-app basis.

More important than collecting exact figures:

• Consider all areas of cost.
• Understand what comprises the “Application” or what peripherals will be bundled into a single entity which is the “line-item” that will undergo the TCO assessment.
• Anticipate, estimate, and project changes in costs as an application ages.

Projecting TCO means anticipating the future.

Factors that can influence your TCO projections

LIFECYCLE STAGE

As applications age the cost of maintenance grows. The costs include ongoing and increased maintenance costs and creeping problems due to quality issues caused by ongoing development initiatives.

While apps in birth and growth are more likely to require enhancements, they are more cost efficient to put in place. When the app ages, the need for refactoring, although less frequent, will be more expensive on a cost per change basis.

CHANGE IN NUMBER OF USERS

License fees are often on a per-user or seat-number basis. If there are anticipated changes in the number of seats on a subscription, that should be reflected in license fee projection. Review trends to aid your projection of costs.

ANTICIPATED UPGRADES

Any major enhancements on your radar, whether dictated by the business or a vendor, should be factored in the long-term TCO of the application.

Applications will reach a point in their lifespan where the cost of change, like rewriting or adding a new feature, will be too high to generate a positive ROI from the added value of that change. Often this point is used to define when an application has become “un-maintainable.”

Use Info-Tech’s Application TCO Calculator to compile

This tool will help you:

Generate a detailed view of application TCO, considering multiple areas of application spend.

Project the costs of your applications over a five-year timeline.

Use this tool for exercise 3.1.5.

Exercise: Calculate application TCO

3.1.5 30 minutes - 1 hour

The objective of this exercise is to collect the TCO of your applications

Input

• Application knowledge
• IT expenses documentation

Output

• TCO of your applications

Materials

• Application TCO Calculator

Participants

• Core APM Team
• Operations Manager

1. For each application, review the different areas of TCO and begin:
1. License and Subscription Fees
2. Upgrade Fees
3. Maintenance Development Labor Cost
4. Peripherals
5. Indirect Costs
2. Determine how many years you plan to forecast TCO.
3. Begin to forecast the TCO of the application. Be sure to consider:
1. Where the application is in its lifecycle
2. Any anticipated upgrades or enhancements
3. Changes in number of users
4. Based on the experience from your first iteration, adapt your playbook.

Document results of the inventory collection in the Application TCO Calculator.

Exercise: Perform a business value and TCO analysis (Part 1)

3.1.6 30 minutes- 1 hour

The objective of this exercise is to compare an applications value to its cost.

Input

• Goals and limitations
• Business value and TCO for applications

Output

• Rationalization criteria and disposition settings for value and TCO comparison

Materials

• Whiteboard and Markers
• Application Rationalization Tool

Participants

• Core APM Team
• Relevant Application SMEs

1. Review the results of from your business value assessment (step 3.1.4) and TCO assessment (step 3.1.5).
2. For each application, enter their business value score and TCO into the appropriate columns of the “Business Value & TCO Comparison” tab.
3. Use the chart to determine applications’ value relative to their cost.

Exercise: Determine your rationalization criteria – business value and TCO comparison (Part 2)

3.1.6 30 minutes- 1 hour

The objective of this exercise is to define the rationalization criteria and disposition settings for business value and TCO rationalization criteria.

1. On a scale of 1 to 5, define your different levels of cost to value relationship.
2. For each level, identify the impact on recommended dispositions in the Application Rationalization Tool.

3. Appropriately modify the Application Alignment Column in the “Rationalization Criteria” tab and adjust the disposition scoring in the “Disposition Settings Tab.”

Document results in the Application Rationalization Tool in the Rationalization Criteria and Disposition Settings tabs.

End user’s perspective should not be neglected

The end user’s perspective is one of the more often neglected areas of rationalization. Business value includes the business outcomes, and technical health examines issues with the backend.

The end-user perspective aims to expose the front-end issues that the business and IT stakeholders don’t concern themselves with on a regular basis.

• How important does the end-user feel the application is?
• How satisfied is the end user with the application?
• Is the application easy to use?
• Does the application adequately present data?
• Is there sufficient training with the application?

These are undoubtably inter-related with generating strong business outcomes and represent the technical health of the app, but without exploring this perspective, assumptions may be made that limit you from improving the value and health of the application.

Info-Tech Insight:

The criteria discussed in this section may overlap with the business value assessment. Continue to apply this analysis as the inputs are used to generate more-specific dispositions.

Use Info-Tech’s Application Portfolio Assessment Diagnostic to add the end users’ perspective to your decision making

Call 1-888-670-8889 to inquire about or request the Application Portfolio Assessment.

Info-Tech Best Practice

The approach in this blueprint has been designed in coordination with Info-Tech’s Application Portfolio Assessment (APA) Diagnostic. While it is not a prerequisite, your project will experience the best results and be completed much quicker by taking advantage of our diagnostic offering prior to initiating the activities in this blueprint.

USE THE PROGRAM DIAGNOSTIC TO:

• Assess the importance and satisfaction of enterprise applications.
• Solicit feedback from your end users on applications being used.
• Understand the strengths and weaknesses of your current applications.
• Perform a high-level application rationalization initiative.

INTEGRATE DIAGNOSTIC RESULTS TO:

• Target which applications to analyze in greater detail.
• Expand on the initial application rationalization results with a more comprehensive and business-value-focused criteria.

Many steps within the exercises throughout this blueprint have been designed to incorporate both members who HAVE (indicated with an A) and HAVE NOT (indicated with a B) completed the APA diagnostic.

Exercise: Determine your rationalization criteria – End-User Perspective

3.1.7 30 minutes

The objective of this exercise is to define the rationalization criteria and disposition settings for the end user’s perspective.

Input

• Goals and limitations
• APA results

Output

• Rationalization criteria and disposition settings for end-user perspective

Materials

• Whiteboard and Markers
• Application Rationalization Tool

Participants

• Core APM Team
• Relevant Application SMEs

1. Review the results of the APA or alternative collection method for end user’s perspective.
2. Define the end-user perspective rationalization inputs. The tool can support up to six rationalization criteria. Info-Tech’s default settings apply the following criterion as they can be extracted using our APA diagnostic.
1. Perceived Importance
2. Satisfaction
3. Usability
4. Data presentation
5. Training
3. For each rationalization criteria, produce a 1 to 5 scale and determine how each score will impact your recommended dispositions in the Application Rationalization Tool.
4. (Optional) Define or use examples to determine the scale.

See the following page for an example.

Example: Determine your rationalization criteria – End-User Perspective

3.1.7

*This section is designed to use the results from Info-Tech’s Application Portfolio Assessment Diagnostic. Adapting this criteria would prevent you from being able to apply our end-user survey tool.

Gauge applications by their degree of common technical NFRs or measure the underlying factors that impact those attributes

Common evaluations of a technical health stick to high-level assessments of how an application delivers on in certain areas, which are traditionally associated with non-functional requirements. This would entail interviewing the appropriate technical subject matter experts for your applications.

MAINTAINABILITY

How Reliable, Available, and Serviceable (RAS) is the application?

TECHNICAL PERFORMANCE

Do the app functions operate as needed?

INTEROPERABILITY

To what degree can or is the app connected into other systems?

ADAPTABILITY

To what degree can the app handle changes in features or scale?

SECURITY

Is the application secure or does it have any security risks?

More detailed analysis is based in measuring the more tangible metrics, which are often the factors that impact how an app delivers on those non-functional requirements. This can require leveraging existing or potentially additional tools to perform that measurement, along with involvement from your technical SMEs.

TECHNICAL DEBT

• Lines of code
• Code duplication
• Deferred features
• Technical debt ratio

MAINTENANCE HISTORY

• Incident rate
• Mean time to repair
• Mean time between failure
• Downtime

PERFORMANCE

• Response time
• Throughput
• Dynamic capacity
• Static capacity

COMPLEX DESIGN

• # of disparate data sources/storage
• Configuration restrictions # of disparate sub-systems

VERSIONING

• # of versions behind # of releases per cycle/quarter

SECURITY

• Vulnerability count
• Flaw creation rate
• Application block rate
• Security incident rate

Info-Tech Insight

Info-Tech recommends the former approach of a high-to-low scale assessment of an app’s non-functional requirement (NFR) rating. However, that measure should be rooted in an informed estimation of how your applications would perform in the appropriate listed metrics.

Exercise: Determine your rationalization criteria – Technical Health

3.1.8 30 minutes

The objective of this exercise is to define the rationalization criteria and disposition settings for technical health.

Input

• Goals and limitations
• Application knowledge

Output

• Rationalization criteria and disposition settings for technical health

Materials

• Whiteboard and Markers
• Application Rationalization Tool

Participants

• Core APM Team
• Relevant Application SMEs

1. Define the technical health rationalization inputs. The tool can support up to seven rationalization criteria. Info-Tech’s default settings apply the following criterion:
1. Maintainability
2. Technical Performance
3. Interoperability
4. Adaptability
5. Security
2. For each rationalization criteria, produce a 1 to 5 scale and determine how each score will impact your recommended dispositions in the Application Rationalization Tool.
3. (Optional) Define or use examples to determine the scale.

See the following page for an example.

Example: Determine your rationalization criteria – Technical Health

3.1.8

Step 3.2 First Iteration Retrospective

This step will walk you through the following activities:

3.2.1 Retrospective

This step involves the following participants:

• Core APM Team
• Application SMEs
• Authorities on Business Value
  • Executive Leadership, Steering Committee, etc.

Outcomes of this step

• Defined rationalization criteria for App Alignment, Business Value, TCO, End-User Perspective, and Technical Health.
• Defined and weighed business value drivers.
• Business value scores for each application.
• TCO measurements and projection each application.
• End-user satisfaction scores for each application.
• Technical health gauge for each application.

Exercise: Retrospective

3.2.1 1-2 hours

The objective of this exercise is simply to review the results generated from the Application Rationalization Tool.

Input

• Application knowledge
• Domain knowledge

Output

• Recommended disposition

Materials

• Application Portfolio Roadmap Tool

Participants

• Core APM Team

1. Review the Recommended Dispositions and “Disposition Selection” tab.
2. Discuss with your teams whether these recommendations align to:
1. The motivations and goals of your rationalization effort.
2. Any preconceived dispositions for the application.
3. With the appropriate participants discuss the results of the exercise. Consider the following:
1. Did the results meet expectations?
2. Did we have the appropriate inputs to perform this analysis?
3. For future iterations, what aspects of this analysis should we stop, start, and continue?
4. Update the table from exercise 2.1.2.

5. Modify your application rationalization framework as appropriate.

Document results in the Application Rationalization Tool in the Rationalization Criteria and Disposition Settings tabs.

Phase 4

Initiate Your Roadmap

Step 4.1 Prioritize and Roadmap Applications

This step will walk you through the following activities:

4.1.1 Determine your dispositions

4.1.2 Prioritize your dispositions

4.1.3 Roadmap your dispositions

This step involves the following participants:

• Core APM Team
• Product Owners or Business Owners

Outcomes of this step

• Expand the recommendations from the rationalization tool to better align with your goals and determine if they are actual candidates to explore further analysis and produce logical business cases.
• Determine the high-level value, technical complexity, effort, and urgency of your applications.
• To prioritize, roadmap, and further expand the business case.

The dispositions assigned to your applications are essentially projects that require the principles of an intake process

To proceed with an application disposition you will have to do some high-level analysis to determine if the item is logical to add to a roadmap and propose to the appropriate decision makers.

Valuable: Achieves business goals in exchange for delivering value to the end user.

Feasible: The expertise required is compatible with business goals, capacity, and limitations.

Usable: The UX matches the end user’s needs and skill sets.

Reconsider Disposition: When no discernable value can be identified, do not add.

Cautiously Add to Roadmap: When value exists, but among concerns or limitations, use discretion.

Accelerate Disposition: When valuable, feasible, and usable, add and prioritize the item.

(Adapted from Product Coalition, 2017)

High-level roadmap considerations for maintaining your applications

Dispositions

RETRAIN

Train users on core functionalities and features of application.

SUPPORT

Develop a custom support model to improve the maintenance and performance of the application.

SUSTAIN

Continue with application as is.

Maintain Can Mean More Than Just the Status Quo

1. Retrain

   Take the appropriate time to discover if the root problems are unfamiliarity with the application’s user interface or a lack of required skill sets. Plan for training or the procurement of the appropriate skills if need be.

2. Restructure Your Support Model

   Optimize your maintenance support models to fit the needs of your applications and application strategy. This will involve assessing your current practices and building a streamlined, standardized operating procedure.

High-level roadmap considerations for modernizing or consolidating your applications

Dispositions

REMEDIATE

Refactor application to a better structure to improve integration and flexibility.

RE-PLATFORM

Move application to a more modern hardware/OS, translate application to new language, or reuse code in a modern environment.

UPGRADE

Move application to a newer version/release.

MERGE

Combine functionality onto a common platform.

ABSORB

Adapt and configure application to handle operations transferred from redundant systems.

Modernization Requires Careful Business and Technical Considerations

1. Enhance, Develop, and Change When Appropriate: Organizations are afraid that modernization will risk business continuity. Dissect the business and technical risks associated with a change and execute your development at a time that minimizes as much disruption as possible.
2. Know Your Constraints: Legacy applications can be limited in portability from one system to another and in flexibility to adjust to business processes. Business and technical consultations are critical to know your organization’s rigidity to change.
3. Develop Realistic Expectations: Previous modernization projects may have disappointed stakeholders because of overpromised results. Build a timeline for your modernization initiatives that considers the business and technical constraints.

High-level roadmap considerations for retiring your applications

Dispositions

REPLACE

Eliminate application and replace with a new or alternative system.

DECOMMISSION

Eliminate application altogether.

Retirement Requires Careful Business and Technical Considerations

1. Replace or Eliminate: The first consideration is whether the function(s) that the current application supports will or will not be kept. The latter option may simplify things, but the former will require additional planning and adherence to any implementation or conversion plan with replacement applications.
2. Data Extraction: Your applications may contain vital information; you need to include in your retirement plans how you will capture and store that data.
3. Integration: This will have already played a role in your decision to retire, but you still need to plan for how you will remove the application with minimal disruption to your systems.
4. Phase Out or Dispose Immediately: This consideration will be influenced by the above. Even without a necessary replacement, data extraction, or integration considerations, there are other constraints to retirement. You will need to plan for employee dependencies and pushback, cost, risk, and other basics of change management.

Exercise: Determine your dispositions

4.1.1 30 minutes

The objective of this exercise is to compile the insights from this project so far and choose your dispositions.

Input

• Application knowledge
• Domain knowledge

Output

• Recommended disposition

Materials

• Application Portfolio Roadmap Tool

Participants

• Core APM Team
• Steering Committee/ Application Leaders

1. Review your strategic Goals established in exercise 1.1.2
2. Review the Recommended Dispositions produced for your applications.
3. Discuss with your team what the appropriate course of action is for each application, considering the results of these activities and your application strategy. Assign each application a course of action, whether it be at a relatively high level, more detailed, or indicating that a more comprehensive individual assessment will take place later. Remember, maintain and status quo are completely viable options when appropriate.
4. Treat this as a project intake exercise. Consider Value, Feasibility, and Usability when determining if this disposition is logical and worthy of the next steps of analysis and/or PPM activities.

Document results of the inventory collection in the Application Portfolio Roadmap Tool in the Application Inventory tab.

Conduct a high-level prioritization of the dispositions assigned to your applications

Your dispositions are essentially projects or large-scale artifacts for your applications. Apply the general principles of a PMO or product backlog intake process.

• Priority: Priority is an assessment that looks at business value, technical complexity & effort, and urgency scores to determine the level of implementation priority for a disposition of a given application. This assessment gives applications a high, medium, or low priority score.
  • Business Value: Business value looks at assessing how the implementation of a disposition for an application achieves certain metrics that map to the organization’s objectives.
  • Effort and Technical Complexity: Technical complexity looks at assessing the level of system and data integration complexity based on the disposition being implemented. This assessment occurs in a diagram fashion.
  • Level of Urgency: Level of urgency looks at assessing the strategic importance and risk of the current application to determine how quickly – or how delayed – the disposition should be implemented.

Use Info-Tech’s Disposition Prioritization Tool to assess your disposition’s value, effort & technical complexity and urgency

Disposition Prioritization Tool

This tool will help you:

Determine the business value, technical complexity & effort, and level of urgency impact for an application’s disposition. The tool will guide you through a series of exercises to determine the impact of the disposition for each variable.

Determine priority levels of each application for your roadmap. The tool will automatically output a 2x2 matrix that will help you visually determine what applications provide greater business value and are urgent for implementation given their disposition. Use this tool for exercise 4.1.2.

Use your rationalization goals as the value drivers to prioritize your dispositions

Based on the dispositions you have approved for each application, establish key indicators of the future state of your application ecosystem.

Align rationalization priorities with IT objectives set out by the business

Define how your rationalization effort will achieve certain benefits through defining drivers. Help the business understand what value your rationalization program provides to the organization.

Convert your business goals/objectives into drivers of your rationalization effort. The top five strategic IT goals include:

• Increase efficiency using IT systems
• Increase productivity
• Cut overall costs for business
• Improve quality of applications
• Enable innovation through new applications (Capgemini)

Establish the indicators that measure the business value of your application disposition to:

• Give your steering committee an approach for measuring what business-value impact an assigned disposition has on an application within the ecosystem that it operates in.
• Determine the goals and objectives that are important to the business.
• Help the business understand what value comes from the disposition.

Determine the level of technical complexity (TC) and effort for each disposition-assigned application

Common high-level assessments of complexity and effort include number of impacted integrations, data migrations or transformations, and impacted lines of code.

Once you have established your business value, the next step is to assess how the assigned disposition for an assessed application will affect how it currently operates within your application ecosystem.

Common considerations include:

Integrations

What is the overall number of impacted connections for the disposition? How many need to be altered, how many need to be created new?

Data

What is the overall impact on the application’s data? How many data models need to be rewritten?

Code

What is the impact of the application code? How many lines of code will need to be refactored?

Overall Complexity

What other factors will dictate the degree of effort? Do you need additional or skilled resources? Will you need to add other peripheral components?

Assess TC using system-level diagrams

• Refer to high-level system diagrams for depictions of your application landscape and how data is transferred between applications.
• It is important to understand the current state of your application landscape through a system-level diagram before creating system-level diagrams respective to an application’s assigned disposition.

• Use Info-Tech’s Enhance Your Application Architecture for advice on building system diagrams.

Determine the level of urgency for implementing the disposition of a given application

Urgency is another important factor, which slightly differs from value. Ensure this factor is prominent when determining the sequence of your disposition execution.

• Alongside evaluating the business value and technical complexity of your applications, it is worthwhile to assess whether an application’s disposition should be expedited or even prolonged.
• While business value and technical complexity looks like what is considered “low-hanging fruit” from an implementation standpoint, urgency is added to the prioritization equation to provide the business with an overview of when the execution of the disposition should occur.
• Establishing a sense of urgency for when disposition implementation should occur can catalyze how often your organization will update your application roadmap. Ensure that appropriate measures are taken to update your roadmap in an accurate manner.

Evaluate the following sub-variables to determine the level of urgency for implementing a given disposition for its respective application:

1. Timeline Sensitivity
   • Are there any factors that impact the immediacy of the disposition (such as the vendor is going through an upgrade or a dependency is being retired)?
2. Severity of Risk and Painpoints
   • Based on the discussion and assessment during rationalization, how severe are the application risks and painpoints (technical performance, reliability, security, business continuity, user experience, etc.)?

Exercise: Prioritize your dispositions

4.1.2 1-2 hours

The objective of this exercise is to conduct a high-level review of the value, effort, and urgency of your application dispositions to consider for your roadmap.

Input

• Dispositions
• Rationalization goals

Output

• Prioritized dispositions

Materials

• Disposition Prioritization Tool

Participants

• Core APM Team
• Development Manager
• PPM, PMO, Steering Committee.

1. Review the goals for rationalization laid out in exercise 1.1.1. In the “rationalization goals” tab list the goals and assign them weights or priority levels based on their relative value.
2. In the “Disposition Value” tab, list your applications and their dispositions.
3. For each application, gauge the impact on the disposition on each goal using a scale of High, Medium, Low, and No.
4. In the “Disposition Urgency” tab, gauge the timeline sensitivity and severity of risk and pain points of the dispositions, using a scale of High, Medium, Low, and No.
5. In the “Disposition Effort and Complexity” tab, determine and weight the factors you will use to measure the effort of the disposition.
6. For each application, gauge the level of each factor of the disposition, using a scale of High, Medium, Low, and No.

Use Info-Tech’s Disposition Prioritization Tool to further assess your applications.

Exercise: Roadmap your dispositions

4.1.3 1-2 hours

The objective of this exercise is to create an initial roadmap (based on high-level estimation and prioritization) that showcases the projected timeline for your applications and their dispositions.

Input

• Prioritized dispositions
• Timeline considerations

Output

• Application portfolio roadmap

Materials

• Application Rationalization Tool

Participants

• Core APM Team

1. Open the Application Inventory tab of the Application Rationalization Tool and scroll to the timeline section. The timeline for the tool is broken down into quarters and years.
2. For your Retire applications: Estimate “beginning of the phase out” period and the “retirement.” Use only those two columns.
3. For your Maintain applications: If you have decided to maintain, with no other actions, leave this section blank. If you have decided to maintain, but retrain or change support model, estimate the beginning and end of the process. Enter those dates into the “Corrective Action” and “Maturity” columns, leaving the other columns blank.
4. For your Modernize or Consolidate applications: Estimate the beginning and end of the process. Enter those dates into the “Modernize” and “Maturity” columns, leaving the other columns blank.

Document results in the Application Rationalization Tool in the Portfolio Roadmap tab.

Example: Review your application portfolio roadmap

Regularly updating your roadmap on an iterative basis will enable your organization to:

• Make application decisions from up-to-date, stable, and accurate information.
• Support future application portfolio decisions.
• Ensure visible roadmap information and transparency across stakeholders.

Step 4.2 Ongoing rationalization and roadmapping

This step will walk you through the following activities:

4.2.1 Next steps, ongoing activities, and roles & responsibilities.

This step involves the following participants:

• Core APM Team

Outcomes of this step

• Defined next steps based on the experiences and results of the first iteration.
• Defined ongoing activities of rationalization, Roadmapping, and other key APM activities.
• Adapted roles and responsibilities for APM practice.

Revisit rationalization and your roadmap on a recurring timeline to make frequent updates

• Rationalization and roadmap updates are often performed when the following triggers occur:
• Changes in business and IT operating models
• Company restructuring events
• M&A events
• Alongside the business events that affect your organization, it is important to establish a recurring time to rationalize (at least at a high level) and review roadmaps that have been created for your organization.
• A common timeline for revisiting a roadmap is semi-annually or quarterly to gauge the business adjustments that affect the timeline of the domain-specific applications.
• If one of the above business events occurs coupled with either noticeably high application maintenance costs or the inability to invest in innovative projects, a rationalization initiative should take place alongside reviewing the application roadmap to determine where cost savings can be realized.

Use Info-Tech’s Build a Product Roadmap for more discussion on when it is appropriate to establish a more frequent roadmap review and distribution cadence.

Info-Tech Insight

By the time you finish all your iterations it will be time to circle back to revisit the progress made with the first roadmap. It is an effective approach to implement a governance process around when to revisit domain-specific roadmaps.

Ensure you have the right roles in place to define and deliver your application portfolio strategy

“Corner of the Desk” Approach

• No one is explicitly dedicated to building a strategy or APM practices.
• Information is collected whenever the application team has time available.
• Benefits are pushed out and value is lost.

“Dedicated” Approach

• The rationalization is given a budget and formal agenda.
• Roles and responsibilities are assigned to team members.

Application portfolio strategy should be viewed as a practice opposed to an initiative. Practices have assigned roles, responsibilities, and accountabilities in place to operate effectively.

Ask

• Who is performing the different assessments?
• Who is providing their subject matter expertise?
• Who is collecting and compiling the information?
• Who is building the artifacts?
• Who is keeping it all accurate and up to date?

Application Portfolio Manager

The individual responsible for the health and evolution of the application portfolio. Accountable for providing portfolio information to various stakeholders and supporting key decisions regarding the strategic direction of applications.

Info-Tech Best Practice

Building your application portfolio strategy is not a one-and-done activity. The artifacts (inventory, roadmap etc.) need to be kept accurate and up to date, and that only happens with dedicated resources and assigned accountability.

Info-Tech Best Practice

The application portfolio manager and their team is who this research is written for. However, the reality is many organizations don’t have explicitly dedicated resources in place. If these roles, and subsequent teams, are not assigned, the strategy is likely to be unsuccessful.

Exercise: Next steps, ongoing activities, and roles & responsibilities

4.2.1. 1-2 hours

The objective of this exercise is to determine the next steps in your completing your Application Rationalization Framework, completing your rationalization efforts or other elements of your application portfolio strategy.

Input

• Experience and results from first iteration

Output

• Next steps
• Ongoing activities
• Defined RACI chart for next steps and ongoing activities.

Materials

• Whiteboard

Participants

• Core APM Team

1. Review the retrospective exercise 3.2.1 and consider the various outstanding changes required for your application rationalization framework.
2. Review the iteration planning exercise 1.2.1 and consider the proceeding iterations your team plans to perform.
3. Review the roles and responsibilities exercise 1.1.3 and expand and adapt the various process steps, artifacts, that your team is or will be responsible for conducting or creating, as well as the information sources necessary for building your application portfolio strategy. Consider the ongoing activities of rationalization, roadmapping, or other key APM functions.
4. Document the distinct activities and/or artifacts that need to occur as you build your application portfolio strategy. Be sure to consider both the activities to complete the current scoped out rationalization effort and any ongoing activities.
5. Discuss the responsibilities and accountabilities for each role directly involved in your application portfolio strategy and how each role is consulted and informed by completing a high-level RACI chart for each activity listed in the previous step of this exercise.
   1. Responsible: Those directly executing the activity.
   2. Accountable: Those ultimately answerable for the outcome of the activity.
   3. Consulted: Those providing vital inputs into the activity.
   4. Informed: Those who should be informed on the outcomes of the activity.

Example: Next steps, ongoing activities, and roles & responsibilities

Example:

Appendix

Understand value drivers that enable revenue growth

Direct Revenue

This value driver is the ability of a product or service to directly produce revenue through core revenue streams.

Can be derived from:

• Creating revenue
• Improving the revenue generation of an existing service
• Preventing the loss of a revenue stream

Be aware of the differences between your products and services that enable a revenue source and those that facilitate the flow of capital.

Funding

This value driver is the ability of a product or service to enable other types of funding unrelated to core revenue streams.

Can be derived from:

• Tax revenue
• Fees, fines, and ticketing programs
• Participating in government subsidy or grant programs

Be aware of the difference between your products and services that enable a revenue source and those that facilitate the flow of capital.

Scale & Growth

This driver can be viewed as the potential for growth in market share or developing new revenue sources.

Does the product or service:

• Increase your market share
• Help you maintain your market share

Be cautious of which items you identify here, as many innovative activities may have some potential to generate future revenue. Stick to those with a strong connection to future revenue and don’t qualify for other value driver categories.

Monetization of Assets

This value driver is the ability of your products and services to generate additional assets.

Can be derived from:

• Sale of data
• Sale of market or customer reports or analysis
• Sale of IP

This value source is often overlooked. If given the right attention, it can lead to a big win for IT’s role in the business.

Understand value drivers that reduce costs

Cost Reduction

A cost reduction is a “hard” cost saving that is reflected as a tangible decrease to the bottom line.

This can be derived from reduction of expenses such as:

• Salaries and wages
• Hardware/software maintenance
• Infrastructure

Cost reduction plays a critical role in an application’s ability to increase efficiency.

Cost Avoidance

A cost avoidance is a “soft” cost saving, typically achieved by preventing a cost from occurring in the first place (i.e. risk mitigation). Cost avoidance indirectly impacts the bottom line.

This can be derived from prevention of expenses by:

• Mitigating a business outage
• Mitigating a risk event
• Delaying a price increase

Understand the value drivers that enhance your services

Enable Core Operations

Some applications are in place to facilitate and support the structure of the organization. These vary depending on the capabilities of your organization but should be assessed in relation to the organization’s culture and structure.

• Enables a foundational capability
• Enables a niche capability

This example is intentionally broad as “core operations” should be further dissected to define different capabilities with ranging priority.

Compliance

A product or service may be required to meet a regulatory requirement. In these cases, you need to be aware of the organizational risk of NOT implementing or maintaining a service in relation to those risks.

In this case, the product or service is required to:

• Prevent fines
• Allow the organization to operate within a specific jurisdiction
• Remediate audit gaps
• Provide information required to validate compliance

Internal Improvement

An application’s ability to create value outside of its core operations and facilitate the transfer of information, insights, and knowledge.

Value can be derived by:

• Data analytics
• Collaboration
• Knowledge transfer
• Organizational learning

Innovation

Innovation is typically an ill-defined value driver, as it refers to the ability of your products and services to explore new value streams.

Consider:

• Exploration into new markets and products
• New methods of organizing resources and processes

Innovation is one of the more divisive value drivers, as some organizations will strive to be cutting edge and others will want no part in taking such risks.

Understand business value drivers that connect the business to your customers

Policy

Products and services can also be assessed in relation to whether they enable and support policies of the organization. Policies identify and reinforce required processes, organizational culture, and core values.

Policy value can be derived from:

• The service or initiative that will produce outcomes in line with core organizational values
• Products that enable sustainability and corporate social responsibility

Experience

Applications are often designed to improve the interaction between customer and product. This value type is most closely linked to product quality and user experience. Customers, in this sense, can also include any stakeholders who consume core offerings.

Customer experience value can be derived from:

• Improving customer satisfaction
• Ease of use
• Resolving a customer issue or identified pain point
• Providing a competitive advantage for your customers

Customer Information

Understanding demand and customer trends is a core driver for all organizations. Data provided through understanding the ways, times, and reasons that consumers use your services is a key driver for growth and stability.

Customer information value can be achieved when an app:

• Addresses strategic opportunities or threats identified through analyzing trends
• Prevents failures due to lack of capacity to meet demand
• Connects resources to external sources to enable learning and growth within the organization

Trust and Reputation

Products and services are designed to enable goals of digital ethics and are highly linked to your organization’s brand strategy.

Trust and reputation can also be described as:

• Customer loyalty and sustainability
• Customer privacy and digital ethics

Prioritizing this value source is critical, as traditional priorities can often come at the expense of trust and reputation.

Research contributors and experts

Geoff Temple, Application Modernization Manager Children’s Aid Society of Toronto

Geoff has a strong development and leadership background. His latest assignment is to plan and coordinate the integration of new applications and technologies within Canada’s largest child protection agency. He facilitates the adoption of new or improved processes and procedures across the organization. He oversees technology implementations, workforce transformations, and corporate policies.

Najam Sahar, Executive Director, Corporate Business Architecture Manitoba Public Insurance Company

Najam has over two decades of experience in designing and executing on business solutions from both an external-to-the-organization view as a consultant and an internal-to-the-organization view as a senior operational leader. Having provided high-level management consulting services to many tier-1 clients in several industry sectors from services to asset-intensive industries, Najam now concentrates on financial services and is principally responsible for the future service delivery model for a major Canadian insurer.

Massimiliano Leo, Senior Manager of IT Applications Epson Europe

Long-standing Information technology manager with experience around enterprise application lifecycle management and a background of enterprise project, change, and delivery management.

Bibliography

Brown, Alex. “Calculating Business Value.” Agile 2014 Orlando – July 13, 2014. Scrum Inc. 2014. Web. 20 Nov. 2017.

Brown, Roger. “Defining Business Value.” Scrum Gathering San Diego 2017. Agile Coach Journal. Web.

Bowling, Alan. “Clearer Visibility of Product Roadmaps Improves IT Planning.” ComputerWeekly.com. 1 Nov. 2010. Web. 29 Sept. 2015.

Craveiro, João. “Marty meets Martin: connecting the two triads of Product Management.” Product Coalition, 18 Nov. 2017. Web. Feb. 2019.

Curtis, Bill. “The Business Value of Application Internal Quality.” CAST. 6 April 2009. Web. 20 Nov. 2017.

Deloitte. “Applications Rationalization during M&A: Standardize, Streamline, Simplify.” Deloitte Consulting LLP. 2016. Web. 20 Nov. 2017.

Fleet, Neville, Joan Lasselle, and Paul Zimmerman. “Using a Balance Scorecard to Measure the Productivity and Value of Technical Documentation Organizations.” CIDM. April 2008. Web. 20 Nov. 2017.

Flexera. “Application Rationalization – Essential Part of the Process for Modernization and Operational Efficiency.” Flexera. 2015. Web. 20 Nov. 2017.

Fowler, Martin. “Application Boundary.” MartinFowler.com. 11 Sept. 2003. Web. 20 Nov. 2017.

LeanIX. “How Application Rationalization Contributes to the Bottom Line.” 2017. Web. 20 Aug. 2019.

Harris, Michael. “Measuring the Business Value of IT.” David Consulting Group. 2007. 20 Nov. 2017.

Intrafocus. “What is a Balanced Scorecard?” Intrafocus. Web. 20 Nov. 2017.

Jayanthi, Aruna. “Application Landscape Report 2014.” Capgemini. 04 March 2014. Web. 20 Nov. 2017.

Lankhorst, Marc., et al. “Architecture-Based IT Valuation.” Via Nova Architectura. 31 March 2010. Web. 20 Nov. 2017.

Mauboussin, Michael J. “The True Measures of Success.” HBR. Oct. 2012. Web. 20 Nov. 2017.

Microsoft. “Business Application Definition.” Microsoft Docs. 18 July 2012. Web. 20 Nov. 2017.

Neogi, Sombit., et al. “Next Generation Application Portfolio Rationalization.” TATA. 2011. Web. 20 Nov. 2017.

Riverbed. “Measuring the Business Impact of IT Through Application Performance.” CIO Summits. 2015. 20 Nov. 2017.

Rouse, Margaret. “Application Rationalization.” TechTarget. March 2016. Web. 20 Nov. 2017.

Van Ramshorst, E.A. “Application Portfolio Management from an Enterprise Architecture Perspective.” Universiteit Utrecht. July 2013.