Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Our intended audience is CIO's, CDO's, CTO's and Developers working in organizations whose performance is dependent on meeting Service Level Agreements both internally and externally. Our proposed solution will adhere to the Service Provider - Vendor model but can also be aligned to other technical service management models like those described in the ITIL methodology.

 

  1.  Introduction

A service level agreement (SLA) quantifies the details of a business contract between two business entities (in our case a service provider and a service vendor). These details include the minimum quality of the service provided, service uptime commitments (reliability) and technical support availability (responsiveness). Depending on the nature of them (internal, external etc.), the breach of SLAs could have legal consequences for the breaching party.

The steps of generating an SLA can be introduced as follow:

1- Negotiation and agreement: An essential step to agree on an SLA is quantifying the service levels using performance metrics. For instance the in ISP/Customer SLAs, the service uptime is typically provided by a percentage e.g., 99.999%.

The other vital part of an SLA is the clear description of the consequences of the breach of contract for the parties involved e.g., penalties, compensations etc.


2- Enforcement: The perfect SLA, if not accompanied by an efficient enforcement tool, would not satisfy the parties involved. The enforcement of the SLAs has many challenges:

a- Different interpretations of the SLA

b- Different measurements of the performance metrics (especially the metrics such as latency which are not very straightforward to measure)

c- Manual monitoring of the SLA parameters at all times.


This white paper explains... [start with a brief topic sentence that sums up what’s in the document. This section “tells them what you’re going to tell them.”]

...