Service Level Agreements are Dead. Long Live Business Level Agreements

A couple of weeks ago I was reviewing a course on the foundations of Site Reliability Engineering (SRE). Site reliability engineering is a discipline that incorporates aspects of software engineering and applies them to infrastructure and operations problems. The main goals are to create scalable and highly reliable software systems.

In this course, they discussed many topics including SLA (Service Level Agreements), SLO (Service Level Objectives), and SLI (Service Level Indicators). Many of us have heard and know about SLAs. An SLA is an agreement between provider and client about measurable metrics like uptime, responsiveness, and responsibilities. You might not be familiar with the other two.

An SLO is an agreement within an SLA about a specific metric like uptime or response time. So, if the SLA is the formal agreement between you and your customer, SLOs are the individual promises you’re making to that customer.  An SLI measures compliance with an SLO. So, for example, if your SLA specifies that your systems will be available 99.99% of the time, your SLO is likely 99.99% uptime and your SLI is the actual measurement of your uptime. Maybe it’s 99.96%. Or maybe it’s 99.99%.  Nevertheless, to stay in compliance with your SLA, the SLI will need to meet or exceed the agreement.

So, let’s summarize these definitions.  An SLA is an agreement between the service provider and the clients or users. An SLO is an objective a service team must hit to meet that agreement. And the SLI is the real number on that performance.  If the SLA is a valid agreement (i.e., the customer actually agrees that it’s a valid measure of acceptable performance), the SLO and SLI should enable the service provider to take proactive action to ensure that they do NOT violate the SLA. There should be sufficient advanced warning of an impending breach to enable a timely, effective response. Unfortunately, this does not always happen. This means the SLA becomes a “best-effort” on behalf of the service provider.

I believe SLAs are no longer relevant. While the ‘A’ means agreement, it is really more of an “assumption.” Most of the time there is no agreement and customers accept without sufficient understanding of what it all means. To make matters worse, the business gets upset when IT talks about their “numbers are good,” but the business is not getting what they really need.

For starters, these definitions are very service/provider-centric (as they should be). A service-level agreement defines the level of service you expect from a vendor. Service providers use SLAs to communicate their limitations on their ability to meet the needs of the client. As the customer, the business needs to determine our expectations of a service provider. Questions include “are we getting the service that was promised?” or “are we getting sufficient value from the investment?” In most companies, IT is guided primarily by internal and external SLAs.  But what about the business measurements? How do we give IT a voice in, and responsibility for achieving corporate business goals? Is there a way to think of these concepts in terms of the business needs instead of provider (IT) services? Moreover, the “level of service” or LOS is often set by the business objectives without (or with minimal) collaboration with IT. How can we enable IT to plan on achieving these corporate goals rather than simply meeting a set of IT goals?

Let me introduce the concepts of the Business Level Agreements (BLA), Business Level Objectives (BLO), and Business Level Indicators (BLI). The BLA can provide a framework for understanding the business impact of the services being provided. Service providers can use this to properly frame the business needs, allowing the service provider to organize themselves to meet those needs. With the identification of these business metrics (which define the criteria for success), the business can focus on the achievement of operational goals, and the service provider can focus on helping the business achieve these goals. A BLO is an agreement within a BLA about a specific business metric. A BLI measures compliance with BLO. In this article, we will discuss mainly the BLA. BLOs and BLIs will be covered in upcoming articles.

A successful BLA will provide a direct link to enterprise objectives, be under IT’s control to enable this success, and establish a valid business case and approval process that connects business outcomes to technology deployment. Business Level Agreements represent understanding the business service, understanding the measures, understanding the charging model, and finally constructing a contract that motivates the partner in line with the business objectives. Keep in mind that as the business changes, so should the BLA.

At this point, you are probably thinking about the many other 3-letter acronyms usually mentioned when discussing business or IT performance. They include KPIs (Key Performance Indicators), OKRs (Objectives and Key Results), and MBO (Management by Objectives). These concepts/terms have been around for a long time. Don’t get me wrong. There is nothing wrong with these concepts. However, these are service-centric. They don’t apply well when considering the customer side.

It is my opinion that OKRs need updating. According to the website www.whatmatters.com, the Objective defines the WHAT. That is, what is the big goal, the main thing you want to accomplish. This objective will be used to inform your actions. The Key Result is the HOW. It represents the benchmarks you will (or should) track on the path to reach your main objective. The HOW acts as a goal post to help you access progress. However, there is something missing. The missing element is the WHY. Without the WHY it is difficult to ascertain the value of the actions to the organization. A company can have objectives all over the place and monitor the results. But without understanding the reason why they could be focusing on the wrong things. A performance indicator or key performance indicator is a type of performance measurement. KPIs evaluate the success of an organization or of a particular activity in which it engages (from a service and not customer perspective). And again, no effective correlation between this indicator and WHY this indicator is needed.

Management by Objectives (MBO) is a strategic management model that aims to improve the performance of an organization by clearly defining objectives that are agreed to by both management and employees. According to the theory, having a say in goal setting and action plans encourages participation and commitment among employees, as well as aligning objectives across the organization. Critics argue that MBO emphasizes the setting of goals to attain objectives, rather than working on a systematic plan to do so. And once again, the missing variable is the WHY.  Setting particular goals like production targets for example can lead workers to meet those targets by any means necessary, including short-cuts that result in poor quality. As I learned in Agile, it is not about the output, it is about the outcome.

Are BLAs, BLOs, and BLIs the answer? Perhaps they are. Or at least part of the answer. BLAs provide a direct link to business objectives. BLA's interface with IT to enable success. They establish a valid business case and approval process that connects business outcomes to technology deployment. Business Level Agreements represent understanding the business needs, understanding the measures, finally constructs a mutually agreed upon contract that aligns the service provider the business objectives. A thought-out and well-formed set of BLAs can provide a foundation for a more convergent relationship between the business and IT.

About Mark Edmead

Mark Edmead is an IT transformation consultant and trainer. Over the past 28 years, he has provided IT transformation and business improvement services that align information technology with business goals to drive bottom-line performance and growth. Mark’s focus is on change management, process improvement, enterprise architecture, technology road mapping, strategic IT planning, IT organization analysis, IT portfolio management, and IT governance. Mark is TOGAF 9.2 certified. a Lean IT accredited trainer, a DevOps trainer, a certified COBIT 5 assessor, a COBIT 2019 accredited trainer, a Business Relationship Management Professional (BRMP) and Certified Business Relationship Manager (CBRM) accredited trainer, a Certified Information Systems Auditor (CISA) trainer, and was a member of the Malcolm Baldrige National Quality Award Board of Examiners.