Establish and Document the Application's Business Criticality, Service Tier, and Service Levels

This chapter explains how to establish and document how critical an Application is to the business, its service tier, and the service levels it must meet.

Why Criticality and Service Levels Matter

Not every Application matters equally. An outage of a customer-facing payment Application has very different consequences from an outage of an internal reporting tool. Business criticality, service tier, and service levels make those differences explicit, and they drive many other decisions: how much redundancy to build, how quickly to recover, how much testing is required, how often to audit, and which conditional practices apply.

Establish Criticality, Service Tier, and Service Levels

• Business criticality describes the impact on the enterprise if the Application is unavailable or performs incorrectly. Establish it through the enterprise’s business impact assessment approach, with the Business Application Owner.

• Service tier places the Application in one of the enterprise’s defined tiers, each associated with standard expectations for availability, support hours, and recovery. Establish it from the Application’s criticality.

• Service levels state the specific targets the Application must meet, such as Service Level Objectives (SLOs) for availability, performance, and recovery, including Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and any Service Level Agreements (SLAs) committed to customers or provided by vendors. Establish them with the Business Application Owner, the Operations and Support Team(s), and, where relevant, vendors.

For example, many enterprises use three or four tiers, with the highest tier reserved for Applications whose failure stops critical business operations or directly affects customers. The scales and tiers used are the enterprise’s own; any example values in this document are common examples that IF4IT recommends and that enterprises can customize.

Document and Share Criticality, Service Tier, and Service Levels

Record the Application’s business criticality, service tier, and service levels in the Application Documentation and in the Application Record. Record, alongside them, the rationale for the criticality rating and the source of each service level, such as a customer contract or a vendor agreement. Review them with every Release and whenever the Application’s business use changes.

Best Practice: Establish and Document the Application’s Business Criticality, Service Tier, and Service Levels

It is a best practice to both establish and document the solution for how much an Application matters and what it must deliver: rate its business criticality, assign its service tier, set its service levels, and record all three with their rationale and sources.

Benefits: Documented criticality and service levels give engineering, operations, and recovery teams a clear basis for how much resilience and support an Application needs, preventing both expensive over-engineering of minor Applications and dangerous under-protection of critical ones. They also let the enterprise apply conditional practices and set audit frequency consistently.

Connections to Related IF4IT Practices and Inventories

The Application Portfolio Management (APM) Best Practices addresses assessing application resilience and recoverability, including Business Impact Analysis, RTO, RPO, and Disaster Recovery readiness, and aligning application SLAs with the service SLAs they underpin. The Service Management Best Practices addresses service levels for the services Applications support. The Non-Functional Requirements (NFRs) Framework for Software Systems addresses availability, performance, and recoverability requirements.