Applications Inventory and Attributes

Description — A unique, human-readable, self-documenting identifier assigned to every application record following a consistent enterprise naming convention. The identifier encodes the inventory type, functional category, and the specific application identity in its structure.

Benefit(s) — Eliminates ambiguity when the same application is referenced across governance systems, conversations, and data sources. Enables AI-assisted cross-inventory traversal and analysis without ETL transformation. Makes reclassification seamless — the identifier travels with the record through any category change, preserving all relationships built against it.

Source — Manually Entered.

Examples — APP-CRM-SALESFORCE, APP-ERP-SAP-S4HANA, APP-COLLAB-MSTEAMS, APP-HRIS-WORKDAY, APP-SCM-ORACLE

Notes — Convention: APP-{Category}-{Name}. Example: APP-CRM-SALESFORCE, APP-ERP-SAP-S4HANA, APP-COLLAB-MSTEAMS. Once assigned, the identifier is permanent and must not be reused if the application is retired.

Description — The full, official name of the application as recognized by its vendor, owner, and organizational stakeholders. This is the primary human-readable identifier for the application across all governance contexts.

Benefit(s) — The foundational identification attribute. Without a consistent, agreed-upon official name, every governance conversation risks ambiguity and misidentification between stakeholders referencing the same application by different informal names.

Source — Manually Entered.

Examples — Salesforce CRM Platform, SAP S/4HANA Finance, Microsoft Teams, Workday HCM, ServiceNow ITSM

Description — A shorter or informal name by which the application is commonly known within the organization — for example, "Salesforce" for "Salesforce CRM Platform" or "SAP" for "SAP S/4HANA Finance."

Benefit(s) — Bridges the gap between formal governance records and the operational language practitioners and business users actually use. Makes the inventory more usable and reduces the friction that causes practitioners to maintain shadow records outside the governed inventory.

Source — Manually Entered.

Description — A concise statement of what the application does, what business problem it solves, and who its primary users are. Written in plain language accessible to both business and technology stakeholders.

Benefit(s) — Enables anyone reviewing the inventory — including AI tools analyzing the portfolio — to understand an application's purpose without needing to access the system directly or consult its owner. Reduces the key-person dependency risk of portfolio knowledge existing only in individuals' memory.

Source — Manually Entered.

Description — Classification of the application by its supply and build model: Custom-Built, Commercial Off-the-Shelf (COTS), Software-as-a-Service (SaaS), Open Source, or Hybrid.

Benefit(s) — Drives fundamentally different governance, financial, and risk approaches. SaaS applications require subscription management; Custom-Built applications carry development and maintenance labor costs; Open Source applications require license compliance monitoring. Without this classification, governance applies the wrong approach to the wrong application type.

Source — Manually Entered.

Examples — SaaS (Salesforce CRM), Custom-Built (internal reporting tool), COTS (SAP S/4HANA), Open Source (Apache Kafka), Hybrid (on-premises ERP with cloud analytics layer)

Notes — Valid values: Custom-Built, COTS, SaaS, Open Source, Hybrid.

Description — Classification of the application by its primary functional domain — for example, CRM, ERP, HRIS, Finance, Supply Chain, Collaboration, Security, Analytics, or Integration.

Benefit(s) — Enables portfolio grouping and analysis by functional area, supports redundancy detection across applications in the same functional category, and provides a consistent taxonomy for cross-portfolio reporting and executive communication.

Source — Manually Entered.

Examples — CRM, ERP, HRIS, Finance, Supply Chain, Collaboration, Security, Analytics, Integration, ITSM

Notes — Use the organization's standard application category taxonomy. Establish and publish the taxonomy before beginning the initial inventory pass to ensure consistency across all application records.

Description — A more granular functional classification below Application Category — for example, within CRM: Field Sales, Customer Service, or Marketing Automation; within Finance: General Ledger, Accounts Payable, or Treasury.

Benefit(s) — Enables detection of fine-grained functional overlap that Category-level grouping misses. An organization may have one ERP but three different Accounts Payable tools — invisible at Category level but immediately surfaced at Sub-Category level.

Source — Manually Entered.

Description — A high-level business domain classification grouping applications by the organizational area they primarily serve — Customer, Finance, Operations, People, Technology, Corporate, or similar organizational domains.

Benefit(s) — Enables portfolio rationalization analysis and investment reporting at the business-domain level — the view most natural for executive leadership comparing technology investment and value across organizational areas. Distinct from Application Category, which classifies by technology function rather than organizational alignment.

Source — Manually Entered.

Examples — Customer (Salesforce CRM), Finance (SAP S/4HANA), People (Workday HCM), Operations (Oracle SCM), Technology (GitHub Enterprise)

Notes — Valid values should align with the organization's standard business domain taxonomy. Common examples: Customer, Finance, Operations, People, Technology, Corporate, Legal, Risk, Compliance.

Description — The primary business unit that owns, funds, or is the principal consumer of the application — identified using the organization's standard business unit taxonomy.

Benefit(s) — Essential for cost chargeback reporting, cross-business-unit redundancy detection, and understanding the organizational distribution of portfolio investment. The pattern of multiple business units independently running applications in the same functional category is only visible when Business Unit is a governed attribute in every application record.

Source — Manually Entered.

Business Function(s) Supported

[Multi-Value]

Description — The specific business functions or processes this application directly enables or supports — for example, Order Management, Claims Processing, Payroll Administration, or Customer Onboarding.

Benefit(s) — Connects application records to the process layer of the enterprise, enabling process-level impact analysis when applications are changed or retired and providing the basis for identifying which applications are critical to specific operational functions.

Source — Manually Entered.

Business Capability Alignment

[Multi-Value]

Description — The business capabilities this application supports, expressed using the organization's capability model — connecting each application to the defined capabilities that underpin organizational strategy.

Benefit(s) — The foundational connection between technology investment and business strategy. Without capability alignment, portfolio rationalization defaults to technical preference rather than business value, and investment decisions cannot be grounded in their relationship to strategic organizational capabilities.

Source — Manually Entered. Each value references a record in the Capabilities Inventory.

Notes — Each value in this set should be a Capabilities Inventory Semantic Identifier where the Capabilities Inventory exists. Free-text capability names are acceptable at Crawl and early Walk maturity pending Capabilities Inventory establishment.

Description — The position of this application in the organization's value chain — the sequence of activities through which the enterprise creates and delivers value to its customers and stakeholders.

Benefit(s) — Distinguishes applications critical to value delivery from those that are internal support functions. Enables investment prioritization grounded in business outcome rather than operational importance alone.

Source — Manually Entered.

Description — The primary URL or access point through which users interact with the application in its production environment — verified and current.

Benefit(s) — Enables direct access verification, automated link-checking, and provides a basic signal for whether the application is actively deployed and accessible. Supports the enterprise service catalog by providing a consistent, governed access point for every application in the portfolio.

Source — Manually Entered.

Description — The current version or release of the application deployed in the production environment, maintained as a current attribute rather than a historical record.

Benefit(s) — Enables identification of applications running outdated or unsupported versions, supports security vulnerability analysis against known CVEs for specific versions, and provides input to End-of-Life status tracking and patch compliance reporting.

Source — Manually Entered.

Keywords and Tags

[Multi-Value]

Description — A set of free-form keywords or governed taxonomy tags associated with the application that support search, filtering, and categorization beyond the formal attribute structure.

Benefit(s) — Increases inventory discoverability for practitioners and AI tools. Enables ad hoc grouping and analysis that the formal category structure does not cover, and supports full-text search across the portfolio when the inventory is loaded into AI-assisted analysis tools.

Source — Manually Entered.

Description — A free-text field for capturing context, history, known issues, special governance considerations, or any information relevant to the application that does not fit a structured attribute.

Benefit(s) — Preserves institutional knowledge about the application that would otherwise exist only in individuals' memory. Reduces key-person dependency risk and ensures that governance decisions are informed by the full context of the application's history.

Source — Manually Entered.