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 between the service provider and the service user.
With APIs, the common elements associated with SLA is 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 product is probably not that straight forward in all cases. Why? Let's iterate this a little bit.
Watch the video below or continue reading
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.
How can I guarantee that my data product has 99% availability, it’s content is valid and coherent, if I don’t have full control of the value chain? The answer is that you can’t. You can’t guarantee it. It’s a risk you can minimize with agreements and by selecting your partners carefully, but you can never guarantee any SLA. In the worst case, you pay the penalty fees defined in the agreement.
11 data product quality attributes
Since a significant part of any SLA is to define expected quality, Data Product Specification takes a strong clear stand on data product quality. The specification contains 11 quality attributes:
Correctness verification level,
Harmonization level,
Interoperability level,
Availability rate,
Update frequency,
Accuracy,
Precision,
Faultlessness rate,
Completeness rate,
Security level and
Response Time.
As you can see, data product quality is not just response time or availability like with APIs at best.
This results in a more complex but also more fine-grained and standardized SLA definition between customers and data product owners. This is exactly what is needed. Customers expect a clear and detailed SLA. Customers know more about the quality of the product they purchase. Thus 11 quality attributes tackle reasons not to purchase your data product!
Utilize data platforms to ensure quality data product delivery
What can you do? How to manage such fine-grained quality monitoring? The answer is simple.
Let the data platform take care of the monitoring of 11 quality aspects for you to ensure SLA. That is more often built-in to data platforms such as Platform of Trust. With help of the platforms, you can verify SLA levels, get alerts if problems arise in the value chains.