3.4 Service Level Agreement (SLA) [1]¶
The integration may involve numerous TDH adherents who expose their APIs. To align on QoS, providers and users of APIs use what are known as Service Level Agreements (SLAs), or service level agreements. An SLA consists of the following elements:
| Purpose | Reasons that led to the definition of the SLA |
| Parties | Interested parties and respective roles (e.g., API provider and user) |
| Validity period | Time interval, expressed by start date and time, end date and time, for which a particular term of agreement is considered valid within the SLAs |
| Perimeter | Operations affected by the specific SLA |
| Service Level Objectives (SLO) | The individual terms of agreement within an SLA. Usually, they are defined using Service Level Indicators (SLI), or service level indicators, which quantify the individual aspects of QoS (e.g., availability) |
| Penalties | Sanctions that apply if the service interface provider does not ensure the objectives specified in the SLA |
| Exclusions | Aspects of QoS not covered by SLAs |
| Administration | Processes by which parties can monitor QoS |
SLAs can be static or dynamic. In dynamic SLAs, the SLOs (with associated SLI) vary over time and the validity periods define the validity intervals of the latter (e.g., during working hours the SLOs can be different from those set during the night). The measurement of QoS levels within an SLA requires the tracking of operations carried out in a multi-domain infrastructure context (geographical, technological and applicational).
| [1] |
«Guidelines on the technical interoperability of Public Administrations» issued by AgID, referred to in paragraph 3.4 of the cited document (please refer to the «Reference Bibliography and Sitography» section at the end of the document for link with redirect to the document) |