Availability Agreements in Digital Portfolio Management
1 Introduction
This whitepaper defines the architecture and configuration of Availability Agreements within the ServiceNow platform, aligned with the Common Service Data Model (CSDM). It covers the data structures that underpin availability commitments, the outage-recording mechanism that feeds availability calculations, and the portfolio contexts in which the resulting metrics are surfaced.
The document is structured in two parts. The first part provides a specification-level description of the data model and processing logic. The second part presents a worked example that traces an availability commitment through its full lifecycle — from commitment definition, through incident-triggered outage recording, to portfolio-level visualisation.
2 Availability Commitments — Data Model
An availability commitment formalises the uptime guarantee that an IT organisation extends for a given service or service instance. Within ServiceNow, availability commitments are a subtype of Service Level Agreement (SLA) artefact and are persisted in the Service Offering Commitment table.
Table: service_offering_commitment
The record is bound to its parent entity through one of two mutually exclusive reference fields, depending on the portfolio context in which the commitment is defined (see Section 3).
|
Reference Field |
Resolved Target |
|
Service Offering |
Business Service Offering or Technology Management Service Offering (Service Portfolio context) |
|
Configuration Item |
Service Instance (Enterprise Portfolio context) |
3 Portfolio Structures
Availability commitments are anchored within two distinct portfolio hierarchies defined by the CSDM. Each hierarchy terminates at a different granularity, and the choice of hierarchy determines which reference field on the commitment record is populated.
3.1 Service Portfolio
The Service Portfolio organises services into a taxonomy-based hierarchy and exposes two parallel branches.
Business Service Portfolio
Business Service Portfolio → Taxonomy Node₁ → … → Taxonomy Nodeₙ → Business Service → Business Service Offering
The availability commitment is associated via the Service Offering reference field.
Technical Service Portfolio
Technical Service Portfolio → Taxonomy Node₁ → … → Taxonomy Nodeₙ → Technology Management Service → Technology Management Service Offering
The same association mechanism applies — the commitment's Service Offering field references the Technology Management Service Offering record.
3.2 Enterprise Portfolio
The Enterprise Portfolio provides an application-centric view, terminating at the Service Instance level.
Portfolio → Taxonomy Node₁ → … → Taxonomy Nodeₙ → Business Application → Service Instance
In this context, the availability commitment is associated via the Configuration Item reference field, which resolves to the target Service Instance.
4 Outage Records — Structure and Classification
Operational availability is quantified through outage records. Each record represents a discrete interval of unavailability for one or more Configuration Items and carries a begin timestamp and an end timestamp that together define the outage window.
Table: cmdb_ci_outage
|
Attribute |
Description |
|
Type = Outage |
Unplanned service interruption. The task reference typically resolves to an Incident record. |
|
Type = Planned Maintenance |
Scheduled downtime window. The task reference typically resolves to a Change Request record. |
|
Begin / End |
Timestamps delineating the outage window. Both fields are required for the availability calculation to consume the record. |
|
Task |
Reference to the originating process record (Incident or Change Request). |
4.1 Multi-CI Association
A single outage event may affect multiple Configuration Items. This many-to-many relationship is managed through a dedicated association table.
Table: cmdb_outage_ci_mtom
Platform architects should note that the association table is the authoritative source for determining the full blast radius of an outage event; the CI field on the parent outage record reflects only the primary affected item.
5 Availability Calculation Engine
The platform ships a scheduled job — Calculate Availability — that executes on a daily cadence. The job performs the following processing:
- It queries all outage records of type Outage where the End timestamp is non-null (i.e., the outage has been resolved).
- For each qualifying record, it computes the outage duration as the delta between Begin and End.
- It aggregates total downtime per Configuration Item over the applicable commitment period and derives the percentage availability against the committed target.
Records with a null End timestamp (open outages) are excluded from the calculation. This ensures that availability metrics reflect only confirmed, bounded downtime intervals.
6 Table Reference
|
Table |
Label |
Role in Availability |
|
service_offering_commitment |
Service Offering Commitment |
Persists the availability target and binds it to a Service Offering or Service Instance. |
|
cmdb_ci_outage |
CI Outage |
Records discrete outage intervals with begin / end timestamps and a task reference. |
|
cmdb_outage_ci_mtom |
Outage–CI Association |
Many-to-many join enabling a single outage to be attributed to multiple CIs. |
7 Worked Example — Deposit Account Service
The following walkthrough traces an availability commitment through its full lifecycle using a fictional Deposit Account service. All screenshots are drawn from a ServiceNow demonstration environment.
7.1 Service Model
The service model establishes the dependency chain from the Business Service Offering down to the underpinning infrastructure. The diagram below shows the Deposit Account service and its constituent CIs.
Figure 1 - Service Model for the Deposit Account service
7.2 Portfolio Configuration
Two portfolios are defined to surface availability metrics at different levels of abstraction.
Figure 2 - Portfolio hierarchy overview
Business Service Portfolio
Business Portfolio → Financial Services → Retail Banking → Deposit Accounts → Deposit Accounts — Netherlands
This taxonomy path terminates at a Business Service Offering record. The portfolio structure parents Business Services and their associated Business Service Offerings.
Enterprise Portfolio
ACME OE BeNeLux → ACME OE Netherlands → Financial Branch → Oracle Flexcube → Oracle Flexcube — PROD
This taxonomy path terminates at a Service Instance record. The portfolio structure parents Business Applications and their downstream Service Instances.
Availability commitments are defined on both the Service Instance (Oracle Flexcube — PROD) and the Business Service Offering (Deposit Accounts — Netherlands). Digital Portfolio Management aggregates data from both portfolios.
Commitment on Service Instance: Oracle Flexcube — PROD
Figure 3 - Availability commitment on the Flexcube — PROD Service Instance
Commitment on Business Service Offering: Deposit Accounts — Netherlands
Figure 4 - Availability commitment on the Deposit Accounts — Netherlands offering
7.3 Incident-Triggered Outage
A monitoring alert generates an Incident against an underpinning CI within the service model.
Figure 5 - Incident created on an underpinning CI
Service Operation Workspace provides a real-time operational view of the incident and its service impact.
|
|
Figure 6 - Service Operation Workspace: incident detail and impact view
The platform's impact analysis engine traverses the service model and determines that the following entities are affected:
- Service Instance: Oracle Flexcube — PROD
- Business Service Offerings: Deposit Accounts — Netherlands, Deposit Accounts — Germany
To register this disruption against the availability commitment, an outage record is created.
Figure 7 - Outage record linked to the Incident
7.4 Outage Resolution
Once the incident is resolved and the service restored, the outage record's End timestamp is populated. The outage record maintains its reference to the originating Incident and to the primary affected CI (typically the Service Instance). Additional impacted CIs are linked through the cmdb_outage_ci_mtom related list.
|
|
Figure 8 - Resolved outage record with Begin and End timestamps
When the scheduled job Calculate Availability next executes, it consumes this closed outage record and recalculates the availability percentage for all associated CIs and their parent commitments.
7.5 Portfolio Visualisation
Following the availability recalculation, the updated metrics are surfaced in both portfolio views within Digital Portfolio Management.
Enterprise Portfolio View / Business Service Portfolio
Figure 9 - Enterprise Portfolio and Business Service Portfolio reflecting the recalculated availability
Appendix — Outage Entity Relationship Diagram
