Application Portfolio Management (APM) Best Practices - Glossary of Terms and Phrases
Application Portfolio Management (APM) Best Practices
Glossary of Terms and Phrases
Overview
The following glossary defines terms and phrases used throughout this document. Terms are listed alphabetically. All definitions are specific to the context of Application Portfolio Management as described in this document.
Terms and Definitions
| Term or Phrase | Abbreviation or Acronym | Definition |
|---|---|---|
| Application | App | A discrete software solution used to support one or more business capabilities or user functions. For APM purposes, an application is a distinct, nameable unit of software with an identifiable owner, a defined purpose, and an associated cost. Applications are the primary unit of management in the application portfolio. |
| Application Lifecycle | The defined stages an application passes through from initial proposal through active operation to eventual retirement. A well-defined lifecycle includes the stages Proposed, Active, Deprecated, and Retired, each with defined entry criteria, governance requirements, and transition processes. | |
| Application Owner | The individual accountable for the strategic direction, governance, performance, and lifecycle of a specific application. The Application Owner is a named individual - not a team or role title - and is the authoritative point of contact for all questions and decisions related to their application. | |
| Application Pipeline | The collection of all applications in the Proposed lifecycle stage - applications that have been approved for development or evaluation and are in active progress but are not yet deployed to production and available to their intended users. The pipeline represents planned future portfolio capability, not current operational capability. | |
| Application Portfolio | The complete collection of all applications that an organization owns, operates, licenses, or depends upon to conduct its business. The application portfolio includes active applications, applications under development, applications being deprecated, and recently retired applications maintained as historical records. | |
| Application Portfolio Management | APM | The organizational discipline of understanding, governing, optimizing, and strategically evolving the application portfolio in service of business goals. APM encompasses governance and ownership, data and inventory management, financial management, assessment and rationalization, lifecycle management, strategic planning, and continuous improvement. |
| Application Rationalization | The process of systematically evaluating applications in the portfolio to identify and act on opportunities to retain, invest in, migrate, consolidate, or retire applications based on their business value, technical fitness, cost, and strategic alignment. Rationalization is governed by the IF4IT Rationalization Postures framework. | |
| Architecture Review Board | ARB | A cross-organizational governance body that reviews and approves significant technology decisions, including new application approvals, major modernization investments, and adoption of new technology standards. APM governance should be formally connected to the ARB where one exists, or recommend the creation of one where it does not. |
| Business Capability | A defined ability or capacity that an organization possesses or requires to achieve its strategic objectives. Business capabilities are the bridge between business strategy and the applications that enable it. In APM, every application should be explicitly mapped to the business capabilities it supports. | |
| Business Owner | The business-side individual accountable for the business outcomes that an application delivers. The Business Owner defines and communicates business value requirements, participates in application assessment reviews, and authorizes business-impacting lifecycle decisions. Distinct from the Application Owner, who is the IT-side accountability. | |
| Capital Expenditure | CapEx | In the context of APM, the costs associated with purchasing, developing, or significantly upgrading applications that are capitalized on the balance sheet and depreciated over their useful life. Understanding the CapEx classification of application investments is important for financial reporting, budget governance, and investment option comparison. |
| Chargeback | A financial accountability model in which the cost of IT services and applications is calculated and directly charged against the budget of the business unit that consumes them, creating direct financial accountability for technology consumption decisions. Contrast with showback, which provides cost visibility without direct billing. | |
| Commodity Application | An application that performs generic business functions - such as expense reporting, HR administration, or email - where the market offers mature, cost-effective solutions and the organization gains no competitive advantage from custom development or extensive customization. Commodity applications should be purchased and standardized rather than built or heavily customized. | |
| Crawl-Walk-Run | The three-stage APM maturity framework described in this document. Crawl establishes the basics: discovery, inventory, ownership, and minimum viable data. Walk adds rigor: assessment, financial data, rationalization, and governance formalization. Run achieves strategic capability: full lifecycle management, enterprise roadmapping, AI-assisted analytics, and full organizational integration. | |
| Differentiating Application | An application that enables capabilities unique to the organization’s competitive position, embodies proprietary processes or institutional knowledge, or delivers customer experiences that cannot be replicated by standard market solutions. Differentiating applications deserve custom development investment and active product management as strategic organizational assets. | |
| End of Life | EOL | The point at which an application vendor stops providing updates, security patches, or technical support for a software product or technology component. Applications running on EOL technology carry unresolvable security vulnerabilities and should be treated as elevated security risks requiring funded remediation plans, not merely as technical debt. |
| Enterprise Model | EM | The aggregate of all enterprise inventories and the relationships between them - a connected intelligence layer that describes what the enterprise is, has, does, and depends upon. The Applications Inventory is one of the most important nodes in the Enterprise Model, and APM is the discipline that governs it and its connections to the broader model. |
| ETL Tax | The accumulated cost - in engineering effort, maintenance burden, and operational fragility - of Extract, Transform, and Load processes required to reconcile inconsistent identifiers and naming conventions across inventory sources. Consistent semantic naming across APM-relevant inventories eliminates the ETL tax by design. | |
| FinOps | A financial operations discipline that brings financial accountability to cloud and SaaS spending by combining engineering, finance, and business perspectives. FinOps practitioners enable organizations to understand, govern, and continuously optimize their variable cloud and subscription costs in near-real time, complementing the periodic financial management approach of traditional IT financial governance. | |
| Minimum Viable Data Set | MVDS | The smallest collection of data attributes for an application that allows the portfolio to support meaningful management decisions. At minimum, the MVDS includes a semantic identifier, a human-readable name and description, the Application Owner name, the business capability or organizational unit served, the current lifecycle status, and a high-level cost estimate by order of magnitude. |
| Operating Expenditure | OpEx | In the context of APM, the ongoing costs of running, supporting, and maintaining applications, including licensing, hosting, support contracts, and operational staffing. SaaS applications and cloud-hosted services are typically treated as OpEx. Understanding the OpEx classification of application costs is important for budget governance and investment option comparison. |
| Platform | A foundational technology layer on which other applications are built or hosted. Platforms are distinct from applications in that they provide shared capabilities - compute, data storage, integration, or development runtime - that multiple applications depend on, rather than directly delivering a specific business function to end users. | |
| Portfolio Roadmap | A forward-looking plan that captures the major changes, investments, migrations, and retirements planned across the application portfolio over a defined time horizon. The portfolio roadmap connects the current state of the portfolio to the target architecture state and integrates with enterprise strategic planning as a defined input to organizational investment decisions. | |
| Rationalization Postures | RPs | The IF4IT framework for classifying every application in the portfolio by the investment and action direction appropriate to its current assessment. Four postures are defined: Tolerate — low or moderate business value with acceptable technical fitness; maintain at current investment levels and reduce cost where possible. Invest — high business value with good technical fitness; continue or increase investment to evolve the application. Migrate — high business value with poor technical fitness or significant technical debt; the business need is real but the current application is not the right long-term vehicle. Eliminate — low business value with poor technical fitness; retire and redirect resources to higher-value investments. This framework is commonly referenced in the industry as the Gartner TIME model, and organizations familiar with that terminology will recognize the same four postures under that name. |
| Semantic Identifier | Semantic UID | A human-readable, self-documenting identifier assigned to an application or inventory item that encodes meaningful information about the item in its structure. Example: APP-CRM-SALESFORCE communicates the inventory type, category, and specific identity without requiring a lookup. Semantic identifiers are AI-friendly, reduce the ETL tax, and make portfolio data self-documenting. |
| Service | A defined capability delivered to customers or internal users that may be enabled by one or more applications but is defined from the customer’s perspective rather than the technology perspective. In APM, every application should be connected to the services it enables through the Service Catalog, making service impact analysis possible when application changes or retirements are planned. | |
| Shadow IT | Applications and technology services procured and operated by business units or individuals outside the visibility and governance of the central IT organization. Shadow IT creates unquantified cost, unmanaged security exposure, unaddressed compliance risk, and hidden integration complexity that the organization cannot govern because it does not know these assets exist. | |
| Showback | A financial accountability model in which the cost of IT services and applications is calculated and reported to business units for visibility and awareness purposes, without directly reducing their budget or requiring direct payment. Showback builds cost awareness and behavioral change as a precursor to chargeback in organizations not yet ready for direct financial accountability. | |
| System | A broader collection of applications, data stores, and infrastructure components that work together to deliver a more complex capability than any single application provides. Systems are distinct from applications in that they encompass multiple discrete software components and their integration relationships rather than a single nameable software solution. | |
| Technical Debt | The accumulated cost of shortcuts, outdated technology, deferred maintenance, and architectural compromises in an application’s design and implementation. Technical debt manifests as slower delivery velocity, higher incident rates, increasing maintenance costs, and difficulty attracting engineering talent. It has a quantifiable financial cost that should be included in application TCO calculations and investment decisions. | |
| Technical Fitness | An assessment of an application’s technical quality, currency, maintainability, security posture, and alignment with current architecture standards. Technical fitness is one of the two primary dimensions of application assessment - alongside business value - and directly determines which Rationalization Posture is appropriate for each application. | |
| Technology Review Board | TRB | A cross-organizational governance body that reviews and approves significant technology decisions. Similar in function to an Architecture Review Board, a TRB may have a broader technology scope covering infrastructure, security, and vendor decisions alongside application architecture. APM governance should be formally connected to the TRB where one exists. |
| TIME Model (by Gartner) | A general industry portfolio rationalization framework created and published by Gartner that classifies applications into four strategic dispositions based on assessment outcomes. Tolerate: low value, acceptable fitness - maintain as-is, reduce cost where possible. Invest: high value, good fitness - continue or increase investment. Migrate: high value, poor fitness - modernize or replace. Eliminate: low value, poor fitness - retire and redirect resources. It is equivalent to IF4IT Rationalization Postures. | |
| Total Cost of Ownership | TCO | The complete financial cost of an application across its entire lifecycle, including licensing, infrastructure, integration development and maintenance, vendor support contracts, internal operational staffing, training, incident management, and the ongoing cost of managing technical debt. TCO is typically two to five times the license cost alone and provides the complete financial picture needed for sound portfolio investment decisions. |
| Two-Tier Inventory Ownership Model | The APM data ownership framework in which cross-enterprise inventories with no natural operational home - such as the Applications Inventory, Software Licenses Inventory, and Data Integrations Inventory - are centrally owned by Enterprise Architecture or an equivalent function, while operationally-homed inventories - such as defect records, incident records, and change records - remain with their operational owners and are consumed by APM as a data consumer. |
Copyright for the International Foundation for Information Technology (IF4IT): 2008 - Present
Legal Disclaimers