Applications Inventory and Attributes

Description — The organizational classification of how critical the application is to business operations: Mission Critical (operations halt if unavailable), Business Critical (significant operational impact when unavailable), Administrative (operational inconvenience when unavailable), or Non-Essential (negligible operational impact when unavailable).

Benefit(s) — Determines the governance tier, recovery priority, SLA requirements, and investment justification for each application. Without Business Criticality, every application is implicitly treated the same regardless of its operational importance — leading to under-investment in mission-critical application resilience.

Source — Manually Entered — validated with the Business Owner.

Examples — Mission Critical (SAP S/4HANA Finance — financial close depends on it), Business Critical (Salesforce CRM — sales operations impacted when unavailable), Administrative (internal training portal), Non-Essential (legacy archive viewer)

Notes — Valid values: Mission Critical, Business Critical, Administrative, Non-Essential.

Description — The maximum acceptable period of time from an application failure or outage to the restoration of the application to operational service — the organization's tolerance for downtime.

Benefit(s) — The governing requirement for disaster recovery investment and infrastructure design. Without documented RTOs, disaster recovery plans cannot be designed to specification, investments in resilience cannot be prioritized by organizational impact, and recovery exercises cannot be validated against a defined success criterion.

Source — Manually Entered — defined by the Business Owner in consultation with IT Operations.

Examples — 0 (no downtime tolerance — payment processing system), 1 hour (Mission Critical ERP), 4 hours (Business Critical CRM), 24 hours (Administrative HR portal), 72 hours (Non-Essential archive system)

Notes — Express as a time duration: for example, 4 hours, 1 hour, 15 minutes, 0 (no downtime tolerance).

Description — The maximum acceptable amount of data loss — measured in time — that the organization can tolerate if the application fails.

Benefit(s) — The governing requirement for backup frequency, data replication strategy, and database recovery investment. Applications handling financial transactions or regulated data typically require RPOs measured in minutes; administrative applications may tolerate RPOs measured in hours or days.

Source — Manually Entered — defined by the Business Owner in consultation with IT Operations.

Examples — 0 (payment processing — no data loss tolerable), 15 minutes (financial transaction system), 4 hours (CRM — acceptable to lose up to 4 hours of sales activity data), 24 hours (HR portal)

Notes — Express as a time duration: for example, 1 hour, 4 hours, 24 hours.

Description — The agreed minimum availability commitment for the application in its production environment — expressed as a percentage of uptime over a defined measurement period.

Benefit(s) — Defines the contractual or internal commitment the organization has made regarding application availability. Availability SLAs drive infrastructure design, monitoring alert thresholds, support model requirements, and the financial consequences of availability failures.

Source — Manually Entered.

Examples — 99.99% (payment processing — approximately 52 minutes downtime per year), 99.9% (CRM — approximately 8.7 hours per year), 99.5% (internal collaboration tool)

Notes — Express as a percentage: for example, 99.9% (approximately 8.7 hours of downtime per year), 99.95%, 99.99%.

Description — The formal disaster recovery tier assigned to the application based on its Business Criticality, RTO, and RPO requirements — typically expressed as a tiered classification (Tier 1 through Tier 4 or equivalent) that maps to a defined set of recovery capabilities and investment levels.

Benefit(s) — Enables systematic allocation of disaster recovery investment across the portfolio in proportion to business criticality and recovery requirements. Without formal DR tier assignment, disaster recovery investment is typically driven by technical preference rather than by business impact.

Source — Manually Entered — assigned in accordance with the organization's DR tier policy.

Description — The support coverage model under which the application is operated: 24x7, Business Hours, On-Call, or No Active Support.

Benefit(s) — Enables cost modeling of support obligations, identification of applications with inadequate support coverage relative to their Business Criticality, and planning for support model changes when applications are migrated or transitioned.

Source — Manually Entered.

Notes — Valid values: 24x7, Business Hours, On-Call, No Active Support.

Support Tier Coverage

[Multi-Value]

Description — The levels of technical support provided for the application — Level 1 (service desk and basic troubleshooting), Level 2 (application-specific technical support), and Level 3 (development-level support for complex issues and defect resolution).

Benefit(s) — Identifies gaps between the support coverage the application requires and the coverage it actually has. Mission Critical applications without Level 3 coverage create incident escalation paths that dead-end at the boundary of available expertise, extending outage duration and business impact.

Source — Manually Entered.

Notes — Valid values (select all that apply): L1, L2, L3.

Description — The count of users who actively use the application within a defined measurement period — typically measured as monthly active users — as distinct from the number of licensed or provisioned users.

Benefit(s) — A foundational proxy for the application's actual organizational value and its usage-to-license ratio. Applications with very small active user bases relative to their license or infrastructure cost are candidates for rationalization review regardless of their technical quality.

Source — Manually Entered or derived from application usage telemetry where available.

Notes — Specify the measurement period: for example, Monthly Active Users (MAU) or Weekly Active Users (WAU).

Description — The degree to which the application is actively used relative to its licensed capacity or provisioned user base — expressed as a percentage (active users divided by licensed users).

Benefit(s) — Essential for identifying high-cost, low-usage applications — one of the most consistently high-value rationalization signals available. An application with 500 licensed users and 40 active users has an 8% utilization rate that warrants a consolidation review regardless of cost level.

Source — Calculated from: Number of Active Users divided by License Count or Seats Licensed within this record, expressed as a percentage.

Description — The direction of change in application usage over the trailing 12-month period: Growing, Stable, Declining, or Minimal.

Benefit(s) — Provides the trend context that makes Utilization Rate actionable. An application with low utilization that is growing is a different investment conversation than one with low utilization that is declining. Usage Trend is a leading indicator for rationalization decisions.

Source — Manually Entered — assessed from usage telemetry or periodic user surveys.

Notes — Valid values: Growing, Stable, Declining, Minimal.

Description — A measure of user satisfaction with the application — expressed as a Net Promoter Score (NPS), a satisfaction rating scale, or the result of a structured periodic user survey.

Benefit(s) — Adds the user perspective to the portfolio assessment alongside technical fitness and financial data. An application with high business value, adequate technical fitness, and very low user satisfaction may represent a higher investment risk than its technical metrics suggest.

Source — Manually Entered — collected through periodic user surveys or in-application feedback mechanisms.

Description — The average time elapsed from the detection of an application failure or production incident to the restoration of the application to normal operational service — measured across the historical incident record for the application.

Benefit(s) — A primary operational quality metric that reveals how efficiently the support model, tooling, and organizational processes resolve application failures. Applications with consistently high MTTR impose greater business impact per incident than their criticality classification may suggest.

Source — Derived from the Risks and Issues Inventory or IT Service Management (ITSM) incident records: average of (resolution time minus detection time) across all incidents for this application in the trailing 12 months.

Description — The date of the most recent production incident — defined as an unplanned interruption or degradation of service — recorded against this application.

Benefit(s) — Provides a recent history signal for operational reliability. Applications with recent incidents warrant heightened operational attention. Combined with MTTR and incident frequency trends, enables prioritization of operational improvement investments.

Source — Derived from the Risks and Issues Inventory or ITSM incident records: date of the most recent incident record for this application with severity classification of Incident or higher.