Service level agreements (or requirements) have been mentioned over and over in IT sphere. Determining what they are and whether they are needed is essential to understanding a high availability need.
Basically, a service level agreement (SLA) is a contract between an application owner (custodian) and an application user. For example, an employee of a company is the application user of a self-service benefits application, and the HR department is the application owner. The HR department signs up (via an internal SLA) to have this application be available to employees during normal business hours. This is what the HR department is held to (measured against). Then, in turn, the HR department might have its own SLA with the IT department that administers and maintains the application. An SLA has the following basic elements:
- Application owner
- Application user
- Application description
- Application hours of operation/availability
- Agreement terms, including the following:
- Duration of agreement (often yearly)
- Levels of response time (to failures, application enhancements, so on)
- Procedures/steps to follow
- Penalties (very often monetary) if levels are not met
Describing penalties is especially important if you want this kind of agreement to have “teeth,” as it should have. Companies such as application service providers (ASPs) probably have the most comprehensive and most severe SLAs on the planet. Of course, their livelihood depends on meeting their SLAs, and perhaps they get huge bonuses when they exceed their SLAs as well.
