Organizations consider application oversight a low priority and app portfolio knowledge is poor:
Build an APM program that is actionable and fit for size:
Besides the small introduction, subscribers and consulting clients within this management domain have access to:
Enterprises have more applications than they need and rarely apply oversight to monitor the health, cost, and relative value of applications to ensure efficiency and minimal risk. This blueprint will help you build a streamlined application portfolio management process.
Visibility into your application portfolio and APM practices will help inform and guide your next steps.
Capture your APM roles and responsibilities and build a repeatable process.
This tool is the central hub for the activities within Application Portfolio Management Foundations.
Workshops offer an easy way to accelerate your project. If you are unable to do the project yourself, and a Guided Implementation isn't enough, we offer low-cost delivery of our project workshops. We take you through every phase of your project and ensure that you have a roadmap in place to complete your project successfully.
Work with key corporate stakeholders to come to a shared understanding of the benefits and aspects of application portfolio management.
Establish the goals of APM.
Set the scope of APM responsibilities.
Establish business priorities for the application portfolio.
1.1 Define goals and metrics.
1.2 Define application categories.
1.3 Determine steps and roles.
1.4 Weight value drivers.
Set short- and long-term goals and metrics.
Set the scope for applications.
Set the scope for the APM process.
Defined business value drivers.
Gather information on your applications to build a detailed inventory and identify areas of redundancy.
Populated inventory based on your and your team’s current knowledge.
Understanding of outstanding data and a plan to collect it.
2.1 Populate inventory.
2.2 Assign business capabilities.
2.3 Review outstanding data.
Initial application inventory
List of areas of redundancy
Plan to collect outstanding data
Work with the application subject matter experts to collect and compile data points and determine the appropriate disposition for your apps.
Dispositions for individual applications
Application rationalization framework
3.1 Assess business value.
3.2 Assess end-user perspective.
3.3 Assess TCO.
3.4 Assess technical health.
3.5 Assess redundancies.
3.6 Determine dispositions.
Business value score for individual applications
End-user satisfaction scores for individual applications
TCO score for individual applications
Technical health scores for individual applications
Feature-level assessment of redundant applications
Assigned dispositions for individual applications
Work with application delivery specialists to determine the strategic plans for your apps and place these in your portfolio roadmap.
Prioritized initiatives
Initial application portfolio roadmap
Ongoing structure of APM
4.1 Prioritize initiatives
4.2 Populate roadmap.
4.3 Determine ongoing APM cadence.
4.4 Build APM action plan.
Prioritized new potential initiatives.
Built an initial portfolio roadmap.
Established an ongoing cadence of APM activities.
Built an action plan to complete APM activities.
Many lack visibility into their overall application portfolio, focusing instead on individual projects or application development. Inevitably, application sprawl creates process and data disparities, redundant applications, and duplication of resources and stands as a significant barrier to business agility and responsiveness. The shift from strategic investment to application maintenance creates an unnecessary constraint on innovation and value delivery.
With the rise and convenience of SAAS solutions, IT has an increasing need to discover and support all applications in the organization. Unmanaged and unsanctioned applications can lead to increased reputational risk. What you don’t know WILL hurt you.
You can outsource development, you can even outsource maintenance, but you cannot outsource accountability for the portfolio. Organizations need a holistic dashboard of application performance and dispositions to help guide and inform planning and investment discussions. Application portfolio management (APM) can’t tell you why something is broken or how to fix it, but it is an important tool to determine if an application’s value and performance are up to your standards and can help meet your future goals.
Hans Eckman
Principal Research Director
Info-Tech Research Group
Research Navigation
Managing your application portfolio is essential regardless of its size or whether your software is purchased or developed in house. Each organization must have some degree of application portfolio management to ensure that applications deliver value efficiently and that their risk or gradual decline in technical health is appropriately limited.
Your APM goals |
If this describes your primary goal(s) |
|
|
|
|
|
|
|
|
Your Challenge |
Common Obstacles |
Info-Tech’s Approach |
|
|
|
Modern software options have decreased the need for organizations to have robust in-house application management capabilities. Your applications’ future and governance of the portfolio still require a centralized IT oversight to ensure the best return on investment.
Source: National Small Business Association, 2019 |
Having more applications than an organization needs means unnecessarily high costs and additional burden on the teams who support the applications. Especially in the case of small enterprises, this is added pressure the IT team cannot afford. A poorly maintained portfolio will eventually hurt the business more than it hurts IT. Legacy systems, complex environments, or anything that leads to a portfolio that can’t adapt to changing business needs will eventually become a barrier to business growth and accomplishing objectives. Often the blame is put on the IT department. |
56%
of small businesses cited inflexible technology as a barrier to growth Source: Salesforce as quoted by Tech Republic, 2019 |
A hidden and inefficient application portfolio is the root cause of so many pains experienced by both IT and the business.
The benefits of APM
APM identifies areas where you can reduce core spending and reinvest in innovation initiatives.
Other benefits can include:
Application Inventory
The artifact that documents and informs the business of your application portfolio.
Application Rationalization
The process of collecting information and assessing your applications to determine recommended dispositions.
Application Alignment
The process of revealing application information through interviewing stakeholders and aligning to business capabilities.
Application Roadmap
The artifact that showcases the strategic directions for your applications over a given timeline.
The ongoing practice of:
Product Lifecycle Management
Align your product and service improvement and execution to enterprise strategy and value realization in three key areas: defining your products and services, aligning product/service owners, and developing your product vision.
Product Delivery Lifecycle (Agile DevOps)
Enhance business agility by leveraging an Agile mindset and continuously improving your delivery throughput, quality, value realization, and adaptive governance.
Application Portfolio Management
Transform your application portfolio into a cohesive service catalog aligned to your business capabilities by discovering, rationalizing, and modernizing your applications while improving application maintenance, management, and reuse.
Inefficiencies within your application portfolio are created by the gradual and non-strategic accumulation of applications.
You have more apps than you need.
Only 34% of software is rated as both IMPORTANT and EFFECTIVE by users.
Directionless portfolio of applications |
Info-Tech’s Five Lens Model |
Assigned dispositions for individual apps |
||||
Application Alignment |
Business Value |
Technical Health |
End-User Perspective |
Total Cost of Ownership (TCO) |
Maintain: Keep the application but adjust its support structure. Modernize: Create a new initiative to address an inadequacy. Consolidate: Create a new initiative to reduce duplicate functionality. Retire: Phase out the application. Disposition: The intended strategic direction or implied course of action for an application. |
|
How well do your apps support your core functions and teams? |
How well are your apps aligned to value delivery? |
Do your apps meet all IT quality standards and policies? |
How well do your apps meet your end users’ needs? |
What is the relative cost of ownership and operation of your apps? |
||
Application rationalization requires the collection of several data points that represent these perspectives and act as the criteria for determining a disposition for each of your applications. |
Determine Scope and categories | Build your list of applications and capabilities | Score each application based on your values | Determine outcomes based on app scoring and support for capabilities | |||
---|---|---|---|---|---|---|
1. Lay Your Foundations 1.1 Assess the state of your current application portfolio. 1.2 Determine narrative. 1.3 Define goals and metrics. 1.4 Define application categories. 1.5 Determine APM steps and roles (SIPOC). |
⇒ |
2. Improve Your Inventory 2.1 Populate your inventory. 2.2 Align to business capabilities. *Repeat |
⇒ |
3. Rationalize Your Apps 3.1 Assess business value. 3.2 Assess technical health. 3.3 Assess end-user perspective. 3.4 Assess total cost of ownership. *Repeat |
⇒ |
4. Populate Your Roadmap 4.1 Review APM Snapshot results. 4.2 Review APM Foundations results. 4.3 Determine dispositions. 4.4 Assess redundancies (optional). 4.5 Determine dispositions for redundant applications (optional). 4.6 Prioritize initiatives. 4.7 Determine ongoing cadence. *Repeat |
INDUSTRY: Retail
SOURCE: Deloitte, 2017
Supermarket Company The grocer was a smaller organization for the supermarket industry with a relatively low IT budget. While its portfolio consisted of a dozen applications, the organization still found it difficult to react to an evolving industry due to inflexible and overly complex legacy systems. The IT manager found himself in a scenario where he knew the applications well but had little awareness of the business processes they supported. Application maintenance was purely in keeping things operational, with little consideration for a future business strategy. As the business demanded more responsiveness to changes, the IT team needed to be able to react more efficiently and effectively while still securing the continuity of the business. The IT manager found success by introducing APM and gaining a better understanding of the business use and future needs for the applications. The organization started small but then increased the scope over time to produce and develop techniques to aid the business in meeting strategic goals with applications. Results The IT manager gained credibility and trust within the organization. The organization was able to build a plan to move away from the legacy systems and create a portfolio more responsive to the dynamic needs of an evolving marketplace. |
The application portfolio management initiative included the following components: Train teams and stakeholders on APM Model the core business processes Collect application inventory Assign APM responsibilities Start small, then grow |
1. Lay Your Foundations |
2. Improve Your Inventory |
3. Rationalize Your Apps |
4. Populate Your Roadmap |
|
---|---|---|---|---|
Phase Activities |
1.1 Assess your current application portfolio 1.2 Determine narrative 1.3 Define goals and metrics 1.4 Define application categories 1.5 Determine APM steps and roles |
2.1 Populate your inventory 2.2 Align to business capabilities |
3.1 Assess business value 3.2 Assess technical health 3.3 Assess end-user perspective 3.4 Assess total cost of ownership |
4.1 Review APM Snapshot results 4.2 Review APM Foundations results 4.3 Determine dispositions 4.4 Assess redundancies (optional) 4.5 Determine dispositions for redundant applications (optional) 4.6 Prioritize initiatives 4.7 Determine ongoing APM cadence |
Phase Outcomes |
Work with the appropriate management stakeholders to:
|
Gather information on your own understanding of your applications to build a detailed inventory and identify areas of redundancy. |
Work with application subject matter experts to collect and compile data points and determine the appropriate disposition for your apps. |
Work with application delivery specialists to determine the strategic plans for your apps and place these in your portfolio roadmap. |
Each step of this blueprint is accompanied by supporting deliverables to help you accomplish your goals.
Application Portfolio Management Foundations Playbook |
Application Portfolio Management Snapshot and Foundations Tool |
This template allows you to capture your APM roles and responsibilities and build a repeatable process. |
This tool stores all relevant application information and allows you to assess your capability support, execute rationalization, and build a portfolio roadmap. |
Key deliverable:
Blueprint Storyboard
This is the PowerPoint document you are viewing now. Follow this guide to understand APM, learn how to use the tools, and build a repeatable APM process that will be captured in your playbook.
DIY Toolkit |
Guided Implementation |
Workshop |
Consulting |
“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.” | “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.” | “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.” | “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
Phase 1 | Phase 2 | Phase 3 | Phase 4 |
---|---|---|---|
Call #1: Establish goals and foundations for your APM practice. |
Call #2: Initiate inventory and determine data requirements. |
Call #3: Initiate rationalization with group of applications. Call #4: Review result of first iteration and perform retrospective. |
Call #5: Initiate your roadmap and determine your ongoing APM practice. |
Note: The Guided Implementation will focus on a subset or group of applications depending on the state of your current APM inventory and available time. The goal is to use this first group to build your APM process and models to support your ongoing discovery, rationalization, and modernization efforts.
A Guided Implementation (GI) is a series of calls with an Info-Tech analyst to help implement our right-sized best practices in your organization. A typical GI, using our materials, is 3 to 6 calls over the course of 1 to 3 months.
Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889
1. Lay Your Foundations | 2. Improve Your Inventory | 3. Rationalize Your Apps | 4. Populate Your Roadmap | Post Workshop Steps | |
---|---|---|---|---|---|
Activities | 1.1 Assess your current 1.2 Determine narrative 1.3 Define goals and metrics 1.4 Define application categories 1.5 Determine APM steps and roles | 2.1 Populate your inventory 2.2 Align to business capabilities | 3.1 Assess business value 3.2 Assess technical health 3.3 Assess end-user perspective 3.4 Assess total cost of ownership | 4.1 Review APM Snapshot results 4.2 Review APM Foundations results 4.3 Determine dispositions 4.4 Assess redundancies (optional) 4.5 Determine dispositions for redundant applications (optional) 4.6 Prioritize initiatives 4.7 Determine ongoing APM cadence |
|
Outcomes | Work with the appropriate management stakeholders to:
| Work with your applications team to:
| Work with the SMEs for a subset of applications to:
| Work with application delivery specialists to:
| Info-Tech analysts complete:
|
Note: The workshop will focus on a subset or group of applications depending on the state of your current APM inventory and available time. The goal is to use this first group to build your APM process and models to support your ongoing discovery, rationalization, and modernization efforts.
Contact your account representative for more information.
workshops@infotech.com 1-888-670-8889
Outcomes |
1-Day Snapshot |
3-Day Snapshot and Foundations (Key Apps) |
4-Day Snapshot and Foundations (Pilot Area) |
---|---|---|---|
APM Snapshot
|
✓ | ✓ | ✓ |
APM Foundations
|
✓ Establish APM practice with a small sample set of apps and capabilities. |
✓ Establish APM practice with a pilot group of apps and capabilities. |
APM Lead/Owner (Recommended) ☐ Applications Lead or the individual responsible for application portfolio management, along with any applications team members, if available Key Corporate Stakeholders Depending on size and structure, participants could include: ☐ Head of IT (CIO, CTO, IT Director, or IT Manager) ☐ Head of shared services (CFO, COO, VP HR, etc.) ☐ Compliance Officer, Steering Committee ☐ Company owner or CEO Application Subject Matter Experts Individuals who have familiarity with a specific subset of applications ☐ Business owners (product owners, Head of Business Function, power users) ☐ Support owners (Operations Manager, IT Technician) Delivery Leads ☐ Development Managers ☐ Solution Architects ☐ Project Managers |
1.Diagnostic |
5. Foundations: Chart
|
2. Data Journey
|
6. App Comparison
|
3. Snapshot
|
7. Roadmap
|
4. Foundations: Results
|
Examples and explanations of these tools are located on the following slides and within the phases where they occur.
One of the primary purposes of application portfolio management is to get what we know and need to know on paper so we can share a common vision and understanding of our portfolio. This enables better discussions and decisions with your application owners and stakeholders.
|
TCO, compared relatively to business value, helps determine the practicality of a disposition and the urgency of any call to action. Application alignment is factored in when assessing redundancies and has a separate set of dispositions.
Phase 1 1.1 Assess Your Current Application Portfolio 1.2 Determine Narrative 1.3 Define Goals and Metrics 1.4 Define Application Categories 1.5 Determine APM Steps and Roles |
Phase 2 2.1 Populate Your Inventory 2.2 Align to Business Capabilities |
Phase 3 3.1 Assess Business Value 3.2 Assess Technical Health 3.3 Assess End-User Perspective 3.4 Assess Total Cost of Ownership |
Phase 4 4.1 Review APM Snapshot Results 4.2 Review APM Foundations Results 4.3 Determine Dispositions 4.4 Assess Redundancies (Optional) 4.5 Determine Dispositions for Redundant Applications (Optional) 4.6 Prioritize Initiatives 4.7 Determine Ongoing APM Cadence |
This phase involves the following participants:
Applications Lead
Key Corporate Stakeholders
Additional Resources
Building an APM process requires a proper understanding of the underlying business goals and objectives of your organization’s strategy. Effectively identifying these drivers is paramount to gaining buy-in and the approval for any changes you plan to make to your application portfolio.
After identifying these goals, you will need to ensure they are built into the foundations of your APM process.
“What is most critical?” but also “What must come first?”
Discover |
Improve |
Transform |
---|---|---|
Collect Inventory Uncover Shadow IT Uncover Redundancies Anticipate Upgrades Predict Retirement |
Reduce Cost Increase Efficiency Reduce Applications Eliminate Redundancy Limit Risk |
Improve Architecture Modernize Enable Scalability Drive Business Growth Improve UX |
One of the primary purposes of application portfolio management is to get what we know and need to know on paper so we can share a common vision and understanding of our portfolio. This enables better discussions and decisions with your application owners and stakeholders.
Estimated time: 1 hour
Download the Application Portfolio Management Diagnostic Tool
Input | Output |
|
|
Materials | Participants |
|
|
|
|
|
|
|
Portfolio Governance |
Transformative Initiatives |
Event-Driven Rationalization |
Improves:
Impact on your rationalization framework:
|
Enables:
Impact on your rationalization framework:
|
Responds to:
Impact on your rationalization framework:
|
Different motivations will influence the appropriate approach to and urgency of APM or, specifically, rationalizing the portfolio. When rationalizing is directly related to enabling or in response to a broader initiative, you will need to create a more structured approach with a formal budget and resources.
Estimated time: 30 minutes-2 hours
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
Root Cause |
IT Pain Points |
Business Pain Points |
Business Goals |
Narrative |
Technical Objectives |
---|---|---|---|---|---|
Sprawl Shadow IT/decentralized oversight Neglect over time Poor delivery processes |
Back-End Complexity Disparate Data/Apps Poor Architectural Fit Redundancy Maintenance Demand/ Low Maintainability Technical Debt Legacy, Aging, or Expiring Apps Security Vulnerabilities Unsatisfied Customers |
Hurdles to Growth/Change Poor Business Analytics Process Inefficiency Software Costs Business Continuity Risk Data Privacy Risk Data/IP Theft Risk Poor User Experience Low-Value Apps |
Scalability Flexibility/Agility Data-Driven Insights M&A Transition Business Unit Consolidation/ Centralization Process Improvement Process Modernization Cost Reduction Stability Customer Protection Security Employee Enablement Business Enablement Innovation |
Create Strategic Alignment Identify specific business capabilities that are incompatible with strategic initiatives. Reduce Application Intensity Highlight the capabilities that are encumbered due to functional overlaps and complexity. Reduce Software Costs Specific business capabilities come at an unnecessarily or disproportionately high cost. Mitigate Business Continuity Risk Specific business capabilities are at risk of interruption or stoppages due to unresolved back-end issues. Mitigate Security Risk Specific business capabilities are at risk due to unmitigated security vulnerabilities or breaches. Increase Satisfaction Applications Specific business capabilities are not achieving their optimal business value. |
Platform Standardization Platform Standardization Consolidation Data Harmonization Removal/Consolidation of Redundant Applications Legacy Modernization Application Upgrades Removal of Low-Value Applications |
Estimated time: 1 hour
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
Goals |
Metric |
Target |
||
---|---|---|---|---|
Short Term |
Improve ability to inform the business |
Leading Indicators |
|
|
Improve ownership of applications |
|
|
||
Reduce costs of portfolio |
|
|
||
Long Term |
Migrate platform |
Lagging Indicators |
|
|
Improve overall satisfaction with portfolio |
|
|
||
Become more customer-centric |
|
|
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? |
“Essentially applications are social constructions.”
Source: Martin Fowler
APM focuses on business applications.
“Software used by business users to perform a business function.”
Unfortunately, that definition is still quite vague.
1. Many individual items can be considered applications on their own or components within or associated with an application. |
2. Different categories of applications may be out of scope or handled differently within the activities and artifacts of APM. |
Different categories of applications may be out of scope or handled differently within the activities and artifacts of APM.
|
Apps can be categorized by generic categories
|
Apps can be categorized by bought vs. built or install types
|
|
Apps can be categorized by the application family
|
Apps can be categorized by the group managing them
|
Apps can be categorized by tiers
|
Set boundaries on what is an application or the individual unit that you’re making business decisions on. Also, determine which categories of applications are in scope and how they will be included in the activities and artifacts of APM. Use your product families defined in Deliver Digital Products at Scale to help define your application categories, groups, and boundaries.
Estimated time: 1 hour
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
Category |
Definition/Description |
Examples |
Documented in your application inventory? |
Included in application rationalization? |
Listed in your application portfolio roadmap? |
Business Application |
End-user facing applications that directly enable specific business functions. This includes enterprise-wide and business-function-specific applications. Separate modules will be considered a business application when appropriate. |
ERP system, CRM software, accounting software |
Yes |
Yes. Unless currently in dev. TCO of the parent application will be divided among child apps. |
Yes |
Software Components |
Back-end solutions are self-contained units that support business functions. |
ETL, middleware, operating systems |
No. Documentation in CMDB. These will be listed as a dependency in the application inventory. |
No. These will be linked to a business app and included in TCO estimates and tech health assessments. |
No |
Productivity Tools |
End-user-facing applications that enable standard communication of general document creation. |
MS Word, MS Excel, corporate email |
Yes |
No |
Yes |
End-User- Built Microsoft Tools |
Single instances of a Microsoft tool that the business has grown dependent on. |
Payroll Excel tool, Access databases |
No. Documentation in Business Tool Glossary. |
No | No |
Partner Applications |
Partners or third-party applications that the business has grown dependent on but are internally owned or managed. |
Supplier’s ERP portal, government portal |
No | No |
Yes |
Shadow IT |
Business-managed applications. |
Downloaded tools |
Yes |
Yes. However, just from a redundancy perspective. |
Yes |
Application Portfolio Manager
|
Business Owner
|
Support Owner
|
Project Portfolio Manager
|
Corner-of-the-Desk Approach
Dedicated Approach
Create the full list of applications and capture all necessary attributes.
Engage with appropriate SMEs and collect necessary data points for rationalization.
Apply rationalization framework and toolset to determine dispositions.
Present dispositions for validation and communicate any decisions or direction for applications.
Estimated time: 1-2 hours
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
Suppliers |
Inputs |
Process |
Outputs |
Customers |
---|---|---|---|---|
|
|
Build Inventory Create the full list of applications and capture all necessary attributes. Resp: Applications Manager & IT team member |
|
|
|
|
Collect & Compile Engage with appropriate SMEs and collect necessary data points for rationalization. Resp: IT team member |
|
|
|
|
Assess & Recommend Apply rationalization framework and toolset to determine dispositions. Resp: Applications Manager |
|
|
|
|
Validate & Roadmap Present dispositions for validation and communicate any decisions or direction for applications. Resp: Applications Manager |
|
|
|
|
Project Intake Build business case for project request. Resp: Project Manager |
|
|
Discovery | Rationalization | Disposition | Roadmap |
---|---|---|---|
Enter your pilot inventory.
|
Score your pilot apps to refine your rationalization criteria and scoring.
|
Determine recommended disposition for each application.
|
Populate your application roadmap.
|
Phase 1 1.1 Assess Your Current Application Portfolio 1.2 Determine Narrative 1.3 Define Goals and Metrics 1.4 Define Application Categories 1.5 Determine APM Steps and Roles | Phase 2 2.1 Populate Your Inventory 2.2 Align to Business Capabilities | Phase 3 3.1 Assess Business Value 3.2 Assess Technical Health 3.3 Assess End-User Perspective 3.4 Assess Total Cost of Ownership | Phase 4 4.1 Review APM Snapshot Results 4.2 Review APM Foundations Results 4.3 Determine Dispositions 4.4 Assess Redundancies (Optional) 4.5 Determine Dispositions for Redundant Applications (Optional) 4.6 Prioritize Initiatives 4.7 Determine Ongoing APM Cadence |
This phase involves the following participants:
Additional Resources
Document Your Business Architecture
The more information you plan to capture, the larger the time and effort, especially as you move along toward advanced and strategic items. Capture the information most aligned to your objectives to make the most of your investment.
If you completed Deliver Digital Products at Scale, use your product families and products to help define your applications.
Learn more about automated application discovery:
High Application Satisfaction Starts With Discovering Your Application Inventory
Estimated time: 1-4 hours per group
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
For the purposes of an inventory, business capabilities help all stakeholders gain a sense of the functionality the application provides.
However, the true value of business capability comes with rationalization.
Upon linking all the organization’s applications to a standardized and consistent set of business capabilities, you can then group your applications based on similar, complementary, or overlapping functionality. In other words, find your redundancies and consolidation opportunities.
Important Consideration
Defining business capabilities and determining the full extent of redundancy is a challenging undertaking and often is a larger effort than APM all together.
Business capabilities should be defined according to the unique functions and language of your organization, at varying levels of granularity, and ideally including target-state capabilities that identify gaps in the future strategy.
This blueprint provides a simplified and generic list for the purpose of categorizing similar functionality. We strongly encourage exploring Document Your Business Architecture to help in the business capability defining process, especially when visibility into your portfolio and knowledge of redundancies is poor.
For a more detailed capability mapping, use the Application Portfolio Snapshot and the worksheets in your current workbook.
A business capability map (BCM) is an abstraction of business operations that helps describe what the enterprise does to achieve its vision, mission, and goals. Business capabilities are the building blocks of the enterprise. They are typically defined at varying levels of granularity and include target-state capabilities that identify gaps in the future strategy. These are the people, process, and tool units that deliver value to your teams and customers.
Info-Tech’s Industry Coverage and Reference Architectures give you a head start on producing a BCM fit for your organization. The visual to the left is an example of a reference architecture for the retail industry.
These are the foundational piece for our Application Portfolio Snapshot. By linking capabilities to your supporting applications, you can better visualize how the portfolio supports the organization at a single glance. More specifically, you can highlight how issues with the portfolio are impacting capability delivery.
Reminder: Best practices imply that business capabilities are methodologically defined by business stakeholders and business architects to capture the unique functions and language of your organization.
The approach laid out in this service is about applying minimal time and effort to make the case for proper investment into the best practices, which can include creating a tailored BCM. Start with a good enough example to produce a useful visual and generate a positive conversation toward resourcing and analyses.
We strongly encourage exploring Document Your Business Architecture and the Application Portfolio Snapshot to understand the thorough methods and tactics for BCM.
Having to address redundancy complicates the application rationalization process. There is no doubt that assessing applications in isolation is much easier and allows you to arrive at dispositions for your applications in a timelier manner.
Rationalization has two basic steps: first, collect and compile information, and second, analyze that information and determine a disposition for each application. When you don’t have redundancy, you can analyze an application and determine a disposition in isolation. When you do have redundancies, you need to collect information for multiple applications, likely across departments or lines of business, then perform a comparative analysis.
Most likely your approach will fall somewhere between the examples below and require a hybrid approach.
Benefits of a high-level application alignment:
Estimated time: 1-4 hours per grouping
The APM tool provides up to three different grouping comparisons to assess how well your applications are supporting your enterprise. Although business capabilities are important, identify your organizational perspectives to determine how well your portfolio supports these functions, departments, or value streams. Each grouping should be a consistent category, type, or arrangement of applications.
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
Capability, Department, or Function 1 |
Capability, Department, or Function 2 |
Capability, Department, or Function 3 |
Capability, Department, or Function 4 |
Capability, Department, or Function 5 |
Capability, Department, or Function 6 |
|
---|---|---|---|---|---|---|
Application A |
x | |||||
Application B |
x | |||||
Application C |
x | |||||
Application D |
x | |||||
Application E |
x | x | ||||
Application F |
x | |||||
Application G |
x | |||||
Application H |
x | |||||
Application I |
x | |||||
Application J |
x |
In this example:
BC 1 is supported by App A
BC 2 is supported by App B
BC 3 is supported by Apps C & D
BCs 4 & 5 are supported by App E
BC 6 is supported by Apps F-G. BC 6 shows an example of potential redundancy and portfolio complexity.
The APM tool supports three different Snapshot groupings. Repeat this exercise for each grouping.
Phase 1 1.1 Assess Your Current Application Portfolio 1.2 Determine Narrative 1.3 Define Goals and Metrics 1.4 Define Application Categories 1.5 Determine APM Steps and Roles | Phase 2 2.1 Populate Your Inventory 2.2 Align to Business Capabilities | Phase 3 3.1 Assess Business Value 3.2 Assess Technical Health 3.3 Assess End-User Perspective 3.4 Assess Total Cost of Ownership | Phase 4 4.1 Review APM Snapshot Results 4.2 Review APM Foundations Results 4.3 Determine Dispositions 4.4 Assess Redundancies (Optional) 4.5 Determine Dispositions for Redundant Applications (Optional) 4.6 Prioritize Initiatives 4.7 Determine Ongoing APM Cadence |
This phase involves the following participants:
Additional Resources
Application Rationalization | Additional Information Sources | Ideal Stakeholders |
---|---|---|
| Business Value
| |
| End User
| |
| TCO
| |
| Technical Health
| |
| Application Alignment
|
Disposition: The intended strategic direction or course of action for an application.
Directionless portfolio of applications |
Assigned dispositions for individual apps High-level examples: |
---|---|
Maintain: Keep the application but adjust its support structure.
Modernize: Create a new project to address an inadequacy.
Consolidate: Create a new project to reduce duplicate functionality.
Retire: Phase out the application.
|
Directionless portfolio of applications | Info-Tech’s Five Lens Model | Assigned dispositions for individual apps | ||||
Application Alignment | Business Value | Technical Health | End-User Perspective | Total Cost of Ownership (TCO) | Maintain: Keep the application but adjust its support structure. Modernize: Create a new initiative to address an inadequacy. Consolidate: Create a new initiative to reduce duplicate functionality. Retire: Phase out the application. Disposition: The intended strategic direction or implied course of action for an application. | |
How well do your apps support your core functions and teams? | How well are your apps aligned to value delivery? | Do your apps meet all IT quality standards and policies? | How well do your apps meet your end users’ needs? | What is the relative cost of ownership and operation of your apps? | ||
Application rationalization requires the collection of several data points that represent these perspectives and act as the criteria for determining a disposition for each of your applications. Disposition: The intended strategic direction or implied course of action for an application. |
The Business | Business Value of Applications | IT |
---|---|---|
Keepers of the organization’s mission, vision, and value statements that define IT success. The business maintains the overall ownership and evaluation of the applications. | Technical subject matter experts of the applications they deliver and maintain. Each IT function works together to ensure quality applications are delivered to stakeholder expectations. |
First, the authorities on business value need to define and weigh their value drivers that describe the priorities of the organization.
This will then allow the applications team to apply a consistent, objective, and strategically aligned evaluation of applications across the organization.
In this context…business value is the value of the business outcome that the application produces and how effective the application is at producing that outcome.
Business value IS NOT the user’s experience or satisfaction with the application.
Financial vs. Human Benefits Financial benefits refer to the degree to which the value source can be measured through monetary metrics and are often quite tangible. Human benefits refer to how an application can deliver value through a user’s experience. Inward vs. Outward Orientation Inward orientation refers to value sources that have an internal impact and improve your organization’s effectiveness and efficiency in performing its operations. Outward orientation refers to value sources that come from your interaction with external factors, such as the market or your customers. |
Increased Revenue |
Reduced Costs |
Enhanced Services |
Reach Customers |
---|---|---|---|
Application functions that are specifically related to the impact on your organization’s ability to generate revenue and deliver value to your customers. |
Reduction of overhead. The ways in which an application limits the operational costs of business functions. |
Functions that enable business capabilities that improve the organization’s ability to perform its internal operations. |
Application functions that enable and improve the interaction with customers or produce market information and insights. |
Record the results in the APM Snapshot and Foundations Tool
Input | Output |
|
|
Materials | Participants |
|
|
For additional support in implementing a balanced value framework, refer to Build a Value Measurement Framework.
MAINTAINABILITY (RAS)
RAS refers to an app’s reliability, availability, and serviceability. How often, how long, and how difficult is it for your resources to keep an app functioning, and what are the resulting continuity risks? This can include root causes of maintenance challenges.
SECURITY
Applications should be aligned and compliant with ALL security policies. Are there vulnerabilities or is there a history of security incidents? Remember that threats are often internal and non-malicious.
ADAPTABILITY
How easily can the app be enhanced or scaled to meet changes in business needs? Does the app fit within the business strategy?
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. Does the app fit within your enterprise architecture strategy?
BUSINESS CONTINUITY/DISASTER RECOVERY
The degree to which the application is compatible with business continuity/disaster recovery (BC/DR) policies and plans that are routinely tested and verified.
Unfortunately, the business only cares about what they can see or experience. Rationalization is your opportunity to get risk on the business’ radar and gain buy-in for the necessary action.
Estimated time: 1-4 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Data Quality
To what degree do the end users find the data quality sufficient to perform their role and achieve their desired outcome?
Effectiveness
To what degree do the end users find the application effective for performing their role and desired outcome?
Usability
To what degree do the end users find the application reliable and easy to use to achieve their desired outcome?
Satisfaction
To what degree are end users satisfied with the features of this application?
What else matters to you?
Tune your criteria to match your values and priorities.
When facing large user groups, do not make assumptions or use lengthy methods of collecting information. Use Info-Tech’s Application Portfolio Assessment to collect data by surveying your end users’ perspectives.
Estimated time: 1-4 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
LICENSING AND SUBSCRIPTIONS: Your recurring payments to a vendor.
Many commercial off-the-shelf applications require a license on a per-user basis. Review contracts and determine costs by looking at per-user or fixed rates charged by the vendor.
MAINTENANCE COSTS: Your internal spending to maintain an app.
These are the additional costs to maintain an application such as support agreements, annual maintenance fees, or additional software or hosting expenses.
INDIRECT COSTS: Miscellaneous expenses necessary for an app’s continued use.
Expenses like end-user training, developer education, and admin are often neglected, but they are very real costs organizations pay regularly.
RETURN ON INVESTMENT: Perceived value of the application related to its TCO.
Some of our most valuable applications are the most expensive. ROI is an optional criterion to account for the value and importance of the application.
The TCO assessment is one area where what you are considering the ”application” matters quite a bit. An application’s peripherals or software components need to be considered in your estimates. For additional help calculating TCO, use the Application TCO Calculator from Build a Rationalization Framework.
Estimated time: 1-4 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Phase 1 1.1 Assess Your Current Application Portfolio 1.2 Determine Narrative 1.3 Define Goals and Metrics 1.4 Define Application Categories 1.5 Determine APM Steps and Roles | Phase 2 2.1 Populate Your Inventory 2.2 Align to Business Capabilities | Phase 3 3.1 Assess Business Value 3.2 Assess Technical Health 3.3 Assess End-User Perspective 3.4 Assess Total Cost of Ownership | Phase 4 4.1 Review APM Snapshot Results 4.2 Review APM Foundations Results 4.3 Determine Dispositions 4.4 Assess Redundancies (Optional) 4.5 Determine Dispositions for Redundant Applications (Optional) 4.6 Prioritize Initiatives 4.7 Determine Ongoing APM Cadence |
his phase involves the following participants:
Additional Resources
Estimated time: 1-2 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Estimated time: 1-2 hours
The APM Foundations Results dashboard (“App Rationalization Results” worksheet) provides a detailed summary of your relative app scoring to serve as input to demand planning.
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
|
TCO, compared relatively to business value, helps determine the practicality of a disposition and the urgency of any call to action. Application alignment is factored in when assessing redundancies and has a separate set of dispositions.
Estimated time: 1-4 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Solving application redundancy is a lot more complicated than simply keeping one application and eliminating the others.
First, you need to understand the extent of the redundancy. The applications may support the same capability, but do they offer the same functions? Determine which apps offer which functions within a capability. This means you cannot accurately arrive at a disposition until you have evaluated all applications.
Next, you need to isolate the preferred system. This is completed by comparing the same data points collected for rationalization and the application alignment analysis. Cost and coverage of all necessary functions become the more important factors in this decision-making process.
Lastly, for the non-preferred redundant applications you need to determine: What will you do with the users? What will you do with the data? And what can you do with the functionality (can the actual coding be merged onto a common platform)?
Disposition |
Description & Additional Analysis |
Call to Action (Priority) |
---|---|---|
Keep & Absorb Higher value, health satisfaction, and cost than alternatives |
These are the preferred apps to be kept. However, additional efforts are still required to migrate new users and data and potentially configure the app to new processes. |
Application or Process Initiative (Moderate) |
Shift & Retire Lower value, health satisfaction, and cost than alternatives |
These apps will be decommissioned alongside efforts to migrate users and data to the preferred system. *Confirm there are no unique and necessary features. |
Process Initiative & Decommission (Moderate) |
Merge Lower value, health satisfaction, and cost than alternatives but still has some necessary unique features |
These apps will be merged with the preferred system onto a common platform. *Determine the unique and necessary features. *Determine if the multiple applications are compatible for consolidation. |
Application Initiative (Moderate) |
Estimated rime: 1 hour per group
This exercise is best performed after aligning business capabilities to applications across the portfolio and identifying your areas of redundancy. At this stage, this is still an information collection exercise, and it will not yield a consolidation-based disposition until applied to all relevant applications. Lastly, this exercise may still be at too high a level to outline the full details of redundancy, but it is still vital information to collect and a starting point to determine which areas require more concentrated analysis.
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Account Management |
Call Management |
Order/Transaction Processing |
Contract Management |
Lead/Opportunity Management |
Forecasting/Planning |
Customer Surveying |
Email Synchronization |
|
---|---|---|---|---|---|---|---|---|
M | M | M | M | S | S | C | W | |
CRM 1 |
✓ |
✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
CRM 2 |
✓ | ✓ | ✓ | ✓ | ||||
CRM 3 |
✓ | ✓ | ✓ |
Estimated time: 1 hour per group
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Roadmaps are used for different communication purposes and at varying points in your application delivery practice. Some use a roadmap to showcase strategy and act as a feedback mechanism that allows stakeholders to validate any changes (process 1). Others may use it to illustrate and communicate approved and granular elements of a change to an application to inform appropriate stakeholders of what to anticipate (process 2).
Select Dispositions & Identify New Initiatives |
Add to Roadmap |
Validate Direction |
Plan Project |
Execute Project |
Select Dispositions & Identify New Initiatives |
|
Approve Project |
Add to Roadmap |
Execute Project |
The steps between selecting a disposition and executing on any resulting project will vary based on the organization’s project intake standards (or lack thereof).
This blueprint focuses on building a strategic portfolio roadmap prior to any in-depth assessments related to initiative/project intake, approval, and prioritization. For in-depth support related to intake, approval, prioritization, or planning, review the following resources.
A roadmap should not be limited to what is approved or committed to. A roadmap should be used to present the items that need to happen and begin the discussion of how or if this can be put into place. However, not every idea should make the cut and end up in front of key stakeholders.
Estimated time: 1-4 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Info-Tech’s Build an Application Rationalization Framework provides additional TCO and value tools to help build out your portfolio strategy.
Determine scope and categories | Build your list of applications and capabilities | Score each application based on your values | Determine outcomes based on app scoring and support for capabilities |
---|---|---|---|
1. Lay Your Foundations
|
2. Improve Your Inventory
|
3. Rationalize Your Apps
|
4. Populate Your Roadmap
|
Repeat according to APM cadence and application changes
Estimated time: 1-2 hours
Input | Output |
|
|
Materials | Participants |
|
|
Record the results in the APM Snapshot and Foundations Tool
Artifact | Owner | Update Cadence | Update Scope | Audience | Presentation Cadence |
---|---|---|---|---|---|
Inventory | Greg Dawson |
|
|
|
|
Rationalization Tool | Judy Ng |
|
|
|
|
Portfolio Roadmap | Judy Ng |
|
|
|
|
Worksheet Data Mapping | Application and Capability List | Group Alignment Matrix (1-3) | Rationalization Inputs | Group 1-3 Results | Application Inventory Details | App Rationalization Results | Roadmap | App Redundancy Comparison |
---|---|---|---|---|---|---|---|---|
Application and Capability List | App list, Groupings | App list | App list, Groupings | App list, Categories | App list, Categories | App list | App list | |
Groups 1-3 Alignment Matrix | App to Group Tracing | |||||||
Application Categories | Category | Category | Category | |||||
Rationalization Inputs | Lens Scores (weighted input to Group score) | Lens Scores (weighted input) | ||||||
Disposition Options | Disposition list, Priorities list, Recommended Disposition and Priority | Lens Scores (weighted input) | ||||||
App Rationalization Results | Disposition |
Attribute | Description | Common Collection Method |
---|---|---|
Name | Organization’s terminology used for the application. | Auto-discovery tools will provide names for the applications they reveal. However, this may not be the organizational nomenclature. You may adapt the names by leveraging pre-existing documentation and internal knowledge or by consulting business users. |
ID | Unique identifiers assigned to the application (e.g. app number). | Typically an identification system developed by the application portfolio manager. |
Description | A brief description of the application, often referencing core capabilities. | Typically completed by leveraging pre-existing documentation and internal knowledge or by consulting business users. |
Business Units | A list of all business units, departments, or user groups. | Consultation, surveys, or interviews with business unit representatives. However, this doesn’t always expose hidden applications. Application-capability mapping is the most effective way to determine all the business units/user groups of an app. |
Business Capabilities | A list of business capabilities the application is intended to enable. | Application capability mapping completed via interviews with business unit representatives. |
Criticality | A high-level grading of the importance of the application to the business, typically used for support prioritization purposes (i.e. critical, high, medium, low). | Typically the criticality rating is determined by a committee representing IT and business leaders. |
Ownership | The individual accountable for various aspect of the application (e.g. product owner, product manager, application support, data owner); typically includes contact information and alternatives. | If application ownership is an established accountability in your organization, typically consulting appropriate business stakeholders will reveal this information. Otherwise, application capability mapping can be an effective means of identifying who that owner should be. |
Application SMEs | Any relevant subject matter experts who can speak to various aspects of the application (e.g. business process owners, development managers, data architects, data stewards, application architects, enterprise architects). | Technical SMEs should be known within an IT department, but shadow IT apps may require interviews with the business unit. Application capability mapping will determine the identity of those key users/business process SMEs. |
Type | An indication of whether the application was developed in-house, commercial off-the-shelf, or a hybrid option. | Consultation, surveys, or interviews with product owners or development managers. |
Active Status | An indication of whether the application is currently active, out of commission, in repair, etc. | Consultation, surveys, or interviews with product owners or operation managers. |
Attribute | Description | Common Collection Method |
---|---|---|
Vendor Information | Identification of the vendor from whom the software was procured. May include additional items such as the vendor’s contact information. | Consultation with business SMEs, end users, or procurement teams, or review of vendor contracts or license agreements. |
Links to Other Documentation | Pertinent information regarding the other relevant documentation of the application (e.g. SLA, vendor contracts, data use policies, disaster recovery plan). Typically includes links to documents. | Consultation with product owners, service providers, or SMEs, or review of vendor contracts or license agreements. |
Number of Users | The current number of users for the application. This can be based on license information but will often require some estimation. Can include additional items of quantities at different levels of access (e.g. admin, key users, power users). | Consultation, surveys, or interviews with product owners or appropriate business SMEs or review of vendor contracts or license agreements. Auto-discovery tools can reveal this information. |
Software Dependencies | List of other applications or operating components required to run the application. | Consultation with application architects and any architectural tools or documentation. This information can begin to reveal itself through application capability mapping. |
Hardware Dependencies | Identification of any hardware or infrastructure components required to run the application (i.e. databases, platform). | Consultation with infrastructure or enterprise architects and any architectural tools or documentation. This information can begin to reveal itself through application capability mapping. |
Development Language | Coding language used for the application. | Consultation, surveys, or interviews with development managers or appropriate technical SMEs. |
Platform | A framework of services that application programs rely on for standard operations. | Consultation, surveys, or interviews with infrastructure or development managers. |
Lifecycle Stage | Where an application is within the birth, growth, mature, end-of-life lifecycle. | Consultation with business owners and technical SMEs. |
Scheduled Updates | Any major or minor updates related to the application, including the release date. | Consultation with business owners and vendor managers. |
Planned or In-Flight Projects | Any projects related to the application, including estimated project timeline. | Consultation with business owners and project managers. |
”2019 Technology & Small Business Survey.” National Small Business Association (NSBA), n.d. Accessed 1 April 2020.
“Application Rationalization – Essential Part of the Process for Modernization and Operational Efficiency.” Flexera, 2015. Web.
“Applications Rationalization during M&A: Standardize, Streamline, Simplify.” Deloitte Consulting, 2016. Web.
Bowling, Alan. “Clearer Visibility of Product Roadmaps Improves IT Planning.” ComputerWeekly.com, 1 Nov. 2010. Web.
Brown, Alex. “Calculating Business Value.” Agile 2014 Orlando, 13 July 2014. Scrum Inc. 2014. Web.
Brown, Roger. “Defining Business Value.” Scrum Gathering San Diego 2017. Agile Coach Journal. Web.
“Business Application Definition.” Microsoft Docs, 18 July 2012. Web.
“Connecting Small Businesses in the US.” Deloitte Consulting, 2017. Accessed 1 April. 2020.
Craveiro, João. “Marty meets Martin: connecting the two triads of Product Management.” Product Coalition, 18 Nov. 2017. Web.
Curtis, Bill. “The Business Value of Application Internal Quality.” CAST, 6 April 2009. Web.
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.
Fowler, Martin. “Application Boundary.” MartinFowler.com, 11 Sept. 2003. Web.
Harris, Michael. “Measuring the Business Value of IT.” David Consulting Group, 2007. Web.
“How Application Rationalization Contributes to the Bottom Line.” LeanIX, 2017. Web.
Jayanthi, Aruna. “Application Landscape Report 2014.” Capgemini, 4 March 2014. Web.
Lankhorst, Marc., et al. “Architecture-Based IT Valuation.” Via Nova Architectura, 31 March 2010. Web.
“Management of business application.” ServiceNow, Jan.2020. Accessed 1 April 2020.
Mauboussin, Michael J. “The True Measures of Success.” HBR, Oct. 2012. Web.
Neogi, Sombit., et al. “Next Generation Application Portfolio Rationalization.” TATA, 2011. Web.
Riverbed. “Measuring the Business Impact of IT Through Application Performance.” CIO Summits, 2015. Web.
Rouse, Margaret. “Application Rationalization.” TechTarget, March 2016. Web.
Van Ramshorst, E.A. “Application Portfolio Management from an Enterprise Architecture Perspective.” Universiteit Utrecht, July 2013.
“What is a Balanced Scorecard?” Intrafocus, n.d. Web.
Whitney, Lance. “SMBs share their biggest constraints and great challenges.” Tech Republic, 6 May 2019. Web.