We’ve all encountered SLAs with APIs. Well, perhaps not all of us, but let's pretend that we have some experience with it. SLA is shorthand for Service Level Agreement. A service-level agreement (SLA) is a commitment between a service provider and a client. Particular aspects of the service – quality, availability, responsibilities – are agreed upon between the service provider and the service user.
With APIs, the common elements associated with SLA are response time and availability. In the agreement, you’ll see values like 99%, 99,5%, 99,9% for availability, and 100, 200 milliseconds for response time. That’s pretty much all API provider is commonly ready to define and commit to. SLA for Data Products must be better than that!
Providing SLA for data products is probably not that straightforward in all cases. Why? Let's iterate this a little bit.
Data value chains and SLA
It probably is simple when you manage the API which offers the piping to deliver data product content from the data source system that you control. In this case you can say that your data product response time and availability equals the same values for your APIs. In short, you have all the strings and full control of the data value chain.
The downside is that, this model hardly ever scales. As a data owner your interests are not in the digital piping but in providing the value to your customers. You have the data your customer are willing to pay for. You want to deliver value to your customer with minimal effort.
Thus you want to utilize data platform and services provided by other companies instead of building everything from scratch.
Things become tricky when data value chain contains two or more organisations, multiple components deployed in different cloud environment, multiple APIs and data source system is owned and maintained by 3rd party service provider. This is tricky technically, but it’s also tricky legally and for reputation.
In the example data owner is utilizing platform which offers APIs for data product management and consumption. These platform APIs have own SLA.
After the platform we have integrating hosted connector component which again has own SLA. When we go even further down the line we have data hub APIs which again have own SLA. In some worst cases we might have own SLA for data source systems behind the APIs as well since those might be provided by 3rd party. Anyway, you see the overall picture that data value chain SLA might not be that simple thing.
Multiple SLAs in your data product value chain
In this example we have already 4 SLAs. Question is what is the SLA of the data product? It’s a combination of all the SLAs in the data value chain. For example the highest possible availability rate is the lowest in the set of SLAs. Making a guarantee for data product response time might be something your lawyers advice you not to give since you can’t control the value chain components and services.