Glossary of Terms and Phrases Used in Application Management - Application Management Best Practices

Glossary of Terms and Phrases Used in Application Management

(Chapter 134 of Application Management Best Practices)

Authored and Published By: The International Foundation for Information Technology (IF4IT), LLC

This glossary defines the terms and phrases used throughout Application Management Best Practices.

Term or Phrase	Abbreviation or Acronym	Definition
Active Application Lifecycle Management	Active ALM	The practice of ensuring that every Application has a named Business Application Owner, a current lifecycle status, a current Strategic Disposition, and a scheduled review cadence; the opposite of passive neglect.
All Eyes On The Documentation	—	An approach in which Application Documentation is published to a centralized Digital Library that is open for both reading and writing by everyone with a stake in the Application, protected by version control and guardrails such as restriction by exception, Application Manager accountability, attributed edits, and formal approval of controlled documents.
Alternate Names	—	All other names by which an Application is known, such as its short name, Vendor Application Name, Business Application Name, IT Application Name, acronyms and abbreviations, former names, and colloquial aliases.
Application	—	A logical, uniquely identifiable software system, composed of a grouping of any combination of technical components, that provides specific capabilities and performs specific functions and services in an automated and highly repeatable manner, and that is deployed (or intended for deployment) to one or more IT Operating Environments, where it is instantiated as one or more in-computer-memory processes.
Application Boundary	—	The defined limit of an Application’s controlling scope: the set of technical components, functions, and services that the Application’s designers have determined to be part of the Application, as distinct from everything outside it with which the Application interacts.
Application Documentation	—	The complete, governed body of data and information that describes an Application. It includes everything required to populate the Application’s record in the Application Inventory, plus the more detailed design, build, test, deployment, operational, support, user, reference, and code-level information that goes beyond, and is not intended to be part of, that record. It is published in a Digital Library (such as a wiki or Document Management System) or, at a minimum, another Document Repository, and, for code-level documentation, may also reside in the Application’s Code Repositories.
Application Documentation Template	—	A standardized, reusable structure that defines the sections, fields, and expected content of an Application’s Documentation, so that every Application is documented consistently, completely, and in a way that is easy to find, read, and compare. It distinguishes the minimum required content (including everything needed to populate the Application Record) from additional recommended content, includes conditional sections that apply only where relevant (such as Vendor information), and provides for Application Instance–specific information wherever Instances differ. At a minimum, it is a templated document (such as a word-processing template); preferably, it is implemented as an online form, or set of forms, within the enterprise’s Digital Library.
Application Instance	—	A uniquely identifiable, configured, and deployed occurrence of an Application within a specific IT Operating Environment Instance that, when active, is instantiated as one or more in-computer-memory processes that may interact with one another and with technical components outside the Application’s own boundary, including other Application Instances.
Application Instance Decommissioning	—	The permanent removal of an Application Instance from its primary purpose within its IT Operating Environment Instance. A Decommissioned Instance may remain installed and running in a restricted capacity until it is Torn Down, for example to provide access to historical data for a required compliance retention period, or as a fallback while a replacement Application becomes adequately stable. Often shortened to Application Decommissioning or Decommissioning.
Application Inventory	—	The enterprise inventory, also known as the Application Registry, that holds the Application Record of every Application.
Application Lifecycle Management	ALM	The strategy and direction for a single Application across the span of its life, from inception through Full Application Retirement, tied to the enterprise’s strategy management and owned by the Business Application Owner; Application Management carries out the work needed to execute it.
Application Management	—	The professional discipline encompassing the planning, delivery, operation, and support of one or more Application Items; practiced for each Application individually.
Application Management Organization	—	The organization, or organizational unit, to which an Application’s Application Manager belongs and which is accountable for the Application’s day-to-day operation, including work performed on its behalf by other organizations or vendors. It may be a sub-organization within the broader business organization the Application serves.
Application Manager	—	The role accountable, on behalf of the Business Application Owner, for the day-to-day management of one or more Applications, including their operation, changes, and support. Also known as Product Manager.
Application Name	—	The single, official, enterprise-approved name of an Application, used in its Application Record and Application Documentation; it must be unique within the Application Inventory.
Application Owner	—	A collective term for an Application’s Business Application Owner and IT Application Owner together.
Application Portfolio Management	APM	The management of a defined group of Applications, such as a business unit’s Applications or the enterprise’s entire portfolio, to decide which to keep, invest in, consolidate, replace, or retire.
Application Portfolio Owner	—	The role that owns a defined group of Applications, and is often also the Business Application Owner of those Applications.
Application Programming Interface	API	A defined, documented interface through which an Application exposes specific functions, services, or data for use by other Applications or Systems (a Published API), or through which it uses those of another (a Consumed API).
Application Record	—	The governed record of an Application in the Application Inventory; a subset of the Application’s Documentation. One Application Record covers all of the Application’s Instances in all environments.
Architecture Decision Record	ADR	A record of a significant architecture decision, capturing its context, the options considered, the decision and its rationale, its consequences, and its status.
Build	—	The process of transforming an Application’s source code, configuration, and dependencies into executable or deployable artifacts, using defined tools and Build rules.
Business Application Owner	—	The role that holds ultimate accountability for an Application and owns its lifecycle strategy. Also known as Business Owner or Product Owner.
Change History	—	The chronological record of the Releases and other changes made to an Application and its Instances, including what changed, why, when, by whom, and under what approval.
Conditional Practice	—	A practice required only for Applications whose business criticality, regulatory classification, data sensitivity, or exposure calls for it, such as penetration testing, regulatory validation, or performance and load testing.
Consumed API	—	An Application Programming Interface provided by another Application or System that an Application uses.
Defect	—	A type of Issue: a flaw in an Application that causes it to behave differently from its requirements or expected outcomes.
Deployment	—	The governed technical movement, installation, configuration, activation, publication, or implementation of Release content into a target IT Operating Environment.
Development or Engineering Organization	—	The organization that designs, builds, and changes an Application.
Development or Engineering Primary Contact	—	The primary contact for an Application within the Development or Engineering Organization that designs, builds, and changes it.
Digital Library	—	An online Application that, at a minimum, enables the creation, editing, curation, and publishing of documents, with interlinkages between them, such as a wiki or a Document Management System (DMS).
Document Repository	—	Any centralized store for documents, including Digital Libraries as well as simpler forms such as centralized file systems and shared folders, which offer only a minimal solution.
Documentation as Code	—	The practice of keeping certain documentation, such as code-level documentation and API specifications, in an Application’s Code Repositories, versioned and reviewed together with code changes; a complement to, not a replacement for, the Digital Library.
Enhancement Request	—	A request to add to or improve an Application, such as a new capability, an improvement to an existing function, or a change in behavior; most are tied to desired or needed future requirements. Enhancement Requests are not Issues.
Enterprise Application	—	An informal label in common industry usage for large, enterprise-class software, such as ERP, CRM, and HR systems, typically used across many organizations within an enterprise. The term is vague and inconsistently applied; IF4IT recommends avoiding it as a classification and, where it is used, stating explicitly which Applications it includes.
Enterprise Application Management	—	1. (IF4IT primary sense) Application Management applied consistently to every Application the enterprise owns, operates, licenses, or depends upon. 2. (Common industry sense) The management of Enterprise Applications. IF4IT recommends avoiding the second sense and adhering to the first.
Enterprise Risk Register	—	The enterprise’s record of identified risks, each with an owner, assessment, mitigation or acceptance, and status; known Application documentation gaps are recorded in it.
Fast Follower	—	Documentation that is permitted, under an approved, justifiable exception, to be delivered by a defined deadline shortly after a Release is deployed, with the gap recorded in the Enterprise Risk Register and further Releases blocked until it is delivered.
Full Application Retirement	—	The Permanent Decommissioning and Tear-down of all of an Application’s Instances across all IT Operating Environments, together with the closure of its Application-level obligations, such as data archival or disposal, contracts, licenses, and support, and the transition of its inventory record to a Retired lifecycle status. Also known as Application Retirement or Full Retirement.
Hosting Model	—	The characteristic of an Application that describes where it is hosted and who operates it; IF4IT-recommended values are On-Premise, Cloud <Platform Name>, SaaS <Vendor Name>, and Hosted <Vendor Name>, and an Application may have more than one.
Hypercare	—	A defined period immediately after go-live during which the team that built an Application remains closely engaged, providing heightened support while the Application stabilizes, ending when defined exit criteria are met.
Instantiation	—	The act of starting an Application’s deployed content within an IT Operating Environment Instance so that it runs as one or more in-computer-memory processes, thereby creating or activating an Application Instance.
Integration	—	A governed connection between Systems through which data and information flow. An API is an interface; an Integration is a connection that may use one.
Issue	—	A generic term for any known, open condition or task affecting an Application that has some negative impact if it is not addressed, categorized into more specific types such as Defects, Risks, Technical Debt Items, and Problems. Enhancement Requests are not Issues.
IT Application Owner	—	The role accountable for the design, development, and engineering of an Application, including its architecture, configuration, automation, deployment, technical validation, and technical Releases. Also known as Technical Owner.
IT Operating Environment	—	A governed logical or physical setting in which technology Assets, configurations, data, integrations, controls, and supporting services are researched, engineered, built, tested, trained on, staged, operated, maintained, or supported.
Key-Person Risk	—	The risk that an enterprise’s ability to operate, support, change, or recover an Application depends on one person or a very small number of people.
Knowledge Debt	—	The backlog of missing, hidden, fragmented, implicit, outdated, inconsistent, inaccessible, or poorly governed enterprise meaning and know-how that must eventually be remediated because it increases cost, risk, complexity, delay, misunderstanding, and poor decision-making.
Knowledge Debt Item	—	A recorded entry in the enterprise’s inventory of Knowledge Debt that identifies one or more Knowledge Gaps, together with the information needed to govern their remediation, such as the affected Application, impact, owner, remediation plan, deadline, and status.
Knowledge Gap	—	A specific, identifiable piece of knowledge needed to understand, operate, support, change, or govern an Application that is missing, inaccessible, or unreliable.
Known Error	—	A Problem whose cause has been identified, often with a documented workaround, but which has not yet been permanently resolved.
Minimum Application Documentation Policy	—	An enterprise policy, mandated and enforced by both business and IT leadership, that defines the minimum complete and vetted Application Documentation every Application must have, and keep current, before any of its Releases may be deployed to Production. The minimum is set by the enterprise and agreed with each critical stakeholder whose work depends on it; it must be thorough (well beyond what is required to populate the Application Record) and is verified by those stakeholders at every Release. Missing, incomplete, or outdated documentation blocks Production Deployment, except through a documented, justifiable exception, such as an emergency, whose documentation gap is recorded in the Enterprise Risk Register and must be closed before any further Release.
No Documentation, No Deployment	—	The summary of the Minimum Application Documentation Policy: no documentation, or incomplete documentation, means no Production Deployment.
Non-Functional Requirement	NFR	A requirement describing a quality an Application must have, such as availability, performance, scalability, security, privacy, usability, accessibility, maintainability, recoverability, or data retention.
One-Off Utility	—	A disposable tool used in support of an Application, such as a data migration utility, a cut-over or conversion script, or a one-time data-fix tool, documented under a lighter but mandatory standard.
Operational Documentation	—	Documentation used to run and support an Application’s Instances, such as runbooks, monitoring and alert-response procedures, incident and escalation procedures, start and stop procedures, backup and restore procedures, and Disaster Recovery procedures.
Operations and Support Primary Contact	—	The primary contact for an Application within the Operations and Support Team(s) that run and support it in Production.
Operations and Support Team(s)	—	The team or teams that run and support an Application’s Instances in Production.
Packaging	—	The process of assembling an Application’s built artifacts, configuration, and supporting files into versioned, distributable units (Packages) suitable for Deployment.
Payment Card Industry Data	PCI	Payment card and cardholder data; one of the most common forms of regulated data.
Personal Financial Information	PFI	Financial information about identifiable individuals; one of the most common forms of regulated data.
Personally Identifiable Information	PII	Information that can identify an individual; one of the most common forms of regulated data.
Problem	—	A type of Issue: the underlying cause of one or more incidents.
Protected Health Information	PHI	Health information about identifiable individuals; one of the most common forms of regulated data.
Published API	—	An Application Programming Interface through which an Application exposes specific functions, services, or data for use by other Applications or Systems.
Recovery Point Objective	RPO	The maximum acceptable amount of data loss, measured in time, when an Application is recovered.
Recovery Time Objective	RTO	The maximum acceptable time within which an Application must be recovered after a disruption.
Red-Amber-Green Reporting	RAG	Reporting of Application documentation conformance in which Green means conforming to the current policy and template version, Amber means updates are scheduled or in progress within the allowed time, and Red means overdue or unable to conform.
Reference Documentation	—	Business and technical reference material that readers consult for facts about an Application rather than for procedures, such as business rules, data dictionaries, API references, configuration references, and the standards the Application follows.
Regulated Data	—	Data whose handling is governed by laws, regulations, or industry standards; there are many forms, of which PII, PHI, PCI data, and PFI are the most common examples.
Release	—	A governed package of approved changes that is planned, validated, authorized, deployed or activated, and transitioned into use through an approved SDLC Path.
Risk	—	A type of Issue: a potential future event or condition that could harm an Application, its users, or the enterprise.
Security Review	—	Any structured examination of an Application’s security, including security design and architecture reviews, vulnerability scans, and penetration tests.
Security Secret	—	Any confidential value used to authenticate, authorize, or protect access or data, such as passwords, API keys, tokens, private keys, and credential-bearing connection strings, whose disclosure would compromise security. Application Documentation records each Secret’s purpose, storage location, owner, access rules, and rotation, never its value.
Semantic Identifier	—	The durable, unique identifier assigned to an Application in the Application Inventory; unlike its name, it never changes.
Service Level Agreement	SLA	A committed level of service agreed with customers or provided by a vendor.
Service Level Objective	SLO	A target level of service, such as for availability or performance, that an Application must meet.
Software Application	—	A System that is the result of applying Software to a specific operations or solutions space. In this document, “Application” almost always means Software Application.
Software as a Service	SaaS	A hosting arrangement in which a vendor hosts, operates, and upgrades a shared, typically multi-tenant, Application in its own cloud, and the enterprise subscribes to it and configures it within the vendor’s limits.
Software Bill of Materials	SBOM	A list of the components, including third-party and open-source components, contained in a Release of an Application.
Sourcing Type	—	The characteristic of an Application that describes who created it; IF4IT-recommended values are Custom-Built (Internal), Vendor, Open Source Community, and Composite.
Strategic Disposition	—	A declared intent for an Application’s future, such as invest, maintain, migrate, or retire.
Subject Matter Expert	SME	A person with expert knowledge of some aspect of an Application on whom others rely.
System	—	Any combination of people, processes, tools, technologies, materials, and data and information, including other Systems, that work together to achieve one or more defined purposes, such as solving a specific problem or challenge.
Systems Development Lifecycle	SDLC	The lifecycle through which technology-enabled capabilities, including Applications, are conceived, developed or acquired, validated, operated, and retired; the IF4IT SDLC defines thirteen phases.
Systems Integration Testing	SIT	The SDLC phase in which integrated technical behavior, interfaces, data flows, dependencies, and controls are verified.
Tear-down	—	The de-installation of an installed version of an Application, or of an entire Application Instance, from an IT Operating Environment Instance, performed to make way for the installation of a newer version, or to complete the removal of a Decommissioned Instance. The Application continues to exist unless it is being Fully Retired. Also known as De-installation.
Technical Debt Item	—	A type of Issue: a recorded shortcut, deficiency, or outdated element in an Application that makes it harder, riskier, or more costly to change and operate.
User Acceptance Testing	UAT	The SDLC phase in which business users validate that an Application satisfies their intended needs.
User Documentation	—	Documentation that explains how users interact with an Application to perform their work, such as user guides, how-to instructions, FAQs, training materials, and descriptions of screens and functions.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Glossary of Terms and Phrases Used in Application Management | Application Management Best Practices. https://if4it.org/best-practices/application-management-best-practices/glossary-of-terms-and-phrases-used-in-application-management/ (accessed 2026-10-30).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers