Align technology availability and support SLAs with the service SLAs they underpin

Overview

Every service SLA that IT commits to is ultimately constrained by the availability and support commitments of the technologies on which that service depends. A service that commits to 99.9 percent availability cannot reliably deliver that commitment if the database platform it depends on has a vendor support SLA of 99.5 percent or a maintenance window that falls within the service’s committed availability window. A service that commits to a four-hour incident resolution time cannot reliably deliver that commitment if a critical technology component lacks vendor support coverage during the hours when incidents most commonly occur. The alignment between technology-level SLAs and service-level SLAs is a governance prerequisite for service commitments that can actually be kept.

This alignment is a TPM responsibility, not solely a service management responsibility. The Technologies Inventory family contains the data — vendor support hours, maintenance window schedules, version support status, patch deployment requirements — that service management needs to set service SLAs that are grounded in the actual availability and support characteristics of the underlying technology stack. Without the TPM governance connection, service SLAs are set based on aspiration rather than evidence, and the gap between committed availability and achievable availability remains invisible until a service breach makes it visible.

Best Practice

Establish a formal alignment process between technology-level availability and support data in the Technologies Inventory family and the service SLA commitments in the Service Catalog. For each service in the Service Catalog, identify the technology components — drawn from the Software Technologies, Hardware Technologies, and Cloud and Infrastructure Services Inventories — that are material to the service’s availability and performance. For each material technology component, document the relevant availability and support characteristics: vendor uptime SLA, supported maintenance windows, patch deployment requirements that create planned downtime, vendor support hours and escalation response times, and the technology’s current lifecycle stage and associated support posture.

Derive the achievable service SLA from the aggregate of the technology component SLAs, applying the appropriate compound availability calculation where multiple technology components must all be available for the service to function. The derived SLA ceiling — the maximum availability the technology stack can reliably support — should be compared against the service SLA that is committed or under consideration, and any gap between the committed SLA and the derived ceiling should be escalated to the service owner and the technology governance function for resolution before the commitment is made or renewed.

When a technology in a service’s dependency stack changes its availability or support characteristics — through a vendor SLA change, a lifecycle stage transition that reduces support posture, a version end-of-support event, or a Standards Register status change to Deprecated — automatically trigger a service SLA review for every service that depends on that technology. The technology-to-service impact chain established in the Service Catalog connection part should be used to identify the affected services and initiate the review without requiring manual discovery of the dependency.

Benefit(s)

Aligning technology availability and support SLAs with service SLAs produces service commitments that are grounded in the actual capabilities of the technology stack rather than in aspirations that the technology stack cannot reliably support. Service breaches attributable to technology SLA misalignment — the most preventable category of service failure — are reduced because the gap between technology capability and service commitment is identified and resolved at commitment time rather than discovered during an incident. Technology lifecycle decisions that reduce the availability or support posture of a technology — deprecation, version end-of-support, or a reduction in vendor support coverage — are evaluated for their service SLA impact as part of the lifecycle decision process rather than after the service impact has already materialized. And the service management and TPM governance functions develop a shared understanding of the technology foundation of service delivery that makes both disciplines more effective.