I often see some confusion between service level agreements (SLAs) and operational level agreements (OLAs). I think the easiest way to explain it is to think about like this:
However, in today’s world of complex services sourced from multiple suppliers, the distinction may be a little more confusing. Let’s take a look.
SLAs & OLAs in traditional IT environments
In earlier times, a service consumed by a customer would most likely be supplied and supported within your own organization. You would put in place an SLA with the customer that explains:
- When the customer would be able to access the service
- How reliable it would be
- When it may be unavailable for scheduled maintenance
- Other similar measurements
The SLA would, in turn, be supported by OLAs with other internal suppliers, such as:
- The service desk
- The infrastructure team
- Network administration
- Development
- Any other applicable suppliers
This situation is easy to understand, easy to manage, and normally makes for easier negotiation of the customer-facing SLA.
SLAs & OLAs in complex environments
In an environment where services are put together using components from multiple suppliers, as is the case for most organisations today, this picture is not as clear.
A service will have its customer-facing SLA, just as it did in the earlier scenario. In turn this SLA is likely to be backed up with internal OLAs, as before. But—here’s the difference—the SLA will also be supported by the SLAs that you have negotiated, as a customer, with your own vendors. These should be treated in the same way as OLAs in this scenario: they must support the customer-facing SLA.
This situation can turn negotiating the SLA with your customer into a complex balancing act with often conflicting timeframes that you must consider.
Understanding SLAs
The SLA represents the commitment of the entire IT organization to its customer to provide a service that meets their expectations. In a multi-sourced environment, this includes third-party suppliers.
SLAs address business level requirements. The business will not be interested in how many hours each of the different teams will need to replace disks, backup and restore files, roll forward the database, or restart servers and applications.
Instead, the business wants to know how long they can realistically expect a service to be unavailable following an outage—this is what you’ll outline in the SLA.
SLAs are all about managing expectations.
Understanding OLAs
The OLAs are the tools that you use to set these expectations. Establishing a workable SLA for a complex service is something like putting a jigsaw puzzle together. Each piece needs to fit with the others in order to build a workable picture.
The OLA clearly articulates what each functional IT group will need to do, in relation to each other, to support the SLA. This will include things like:
- What the server team will do for patching of the servers
- What the desktop team will do to patch the desktop systems
- What the DBAs will do to optimize the databases
- How the service desk will respond to incidents and requests
- And more…
The promises that you make in the SLA must be measurable and completely supported by the OLAs that the SLA relies on.
Real-world examples
If your customer requires a service to have no more than two hours of consecutive downtime at any time of the day or night, you must ensure that every OLA that supports that service allows you to promise that level of service.
If the vendor that supports the database for the service, for example, has an OLA with you that gives a two-hour restoration time only during business hours, you cannot agree to a two-hour restoration time, 24-hours a day with your customer. It is likely that your vendor will agree to providing the level of service that your customer is requesting—but is your customer prepared to pay for it?
Consider also that, during a service failure, it is quite likely that you may go through multiple teams or vendors before you are able to resolve the situation. Each of these will be running under their own OLA or SLA with you. Each time a new partner is brought in to look at the failure, their clock starts.
For this reason, all suppliers need to be involved from the outset if you are to meet the SLA timelines agreed with your customer.
Best practice: Negotiate OLAs first
Understanding what your internal service providers and your vendors can provide, and at what cost, is critical. You must understand any limitations, cost differentials, and other factors before you negotiate the SLA with your customer. The OLAs are your building blocks, so they must be in place first.
The biggest and most common mistake I see is this: you agree and sign off on an SLA with a customer. Then, after agreement, the service level manager heads off to negotiate supporting OLAs with internal and external suppliers…only to find that the agreed SLAs are unsupportable, at any cost, sending you back to your customer to start over.
Challenges for service level managers
Today’s service level manager has a job that is far more complex than it was earlier. One service may require input from multiple internal and external teams in order to meet customer requirements. I warn you: the complexities will not stop there.
Imagine you are purchasing infrastructure as a service (IaaS) from one vendor. That vendor, in turn, uses another vendor to supply security gateways. You will have to rely on your vendor having a properly negotiated OLAs with their supplier. While contractually the onus is on the vendor you have the direct relationship with, that does not really matter to your customer—all your customer is concerned with is that the service they’re consuming performs in accordance with their SLA with you.
My recommendation is this: Never assume anything. Ask to see your vendors’ agreements with any suppliers who are supporting services that you consume from them. Your responsibility is to provide the agreed service level to your customer. Telling them that it is ‘not my fault’ is unlikely to go down well—so do your due diligence up front.
While SLAs and OLAs will contain much of the same type of information, they do perform different roles. Make sure that all your building blocks are in place, stable, and well supported from end to end. Without this you will not be able to agree service levels with your customers with any confidence.
SLAs are all about managing expectations. OLAs are the tools that you use to set these expectations.
Additional resources
For more on this topic, explore our BMC Service Management Blog and these articles:
