Is a communications API SLA strong enough for enterprises?
When downtime occurs, an API service-level agreement should pinpoint customer and vendor responsibilities. Enterprises will need to monitor their API SLA closely.
API service-level agreements are strong enough for enterprise customers. At the same time, they are not. But before we delve into that conundrum, let's explore your options.
In the case of a contact-center application, for example, an enterprise can select a ready-made cloud-based service and simply use it. Or, the enterprise can deploy an on-premises contact center from a vendor. The enterprise could also pick a cloud-based communications API and self-develop a contact center. Or, it can do the same with an on-premises offering, but that's less likely.
Which of these options offers the best service-level agreement (SLA)?
The on-premises offering can have a great SLA. In this case, the vendor only needs to deal with a support SLA, indicating how long it takes for the vendor to respond to a new ticket and the time to resolution. The enterprise is in charge of installing and managing the deployment, keeping uptime, upgrading the system, dealing with security patches and other issues.
While on-premises deployments give you a lot of control, they also require great responsibility. Issues such as high availability and geo-redundancy come to mind, especially during natural disasters or a total failure of a data center. In these instances, the enterprise is largely responsible for its own downtime problems. But, in many cases, it will be hard-pressed to solve them without huge upfront costs.
Cloud-based services could also leave you stranded. When the cloud service is down, you can only wait for someone out of your span of control to solve the issue. For example, is the vendor doing everything possible? Is it favoring other customers while trying to resolve the issue? You'll never know. You are at someone else's mercy, which isn't a great feeling.
Assuming the vendor is big enough, this shouldn't be an issue. Since this is the vendor's core business, it's probably doing a better job than you can.
So, in any event, be prepared. Downtime will occur with cloud services, but it also occurs with on-premises systems -- and probably at a higher frequency and for longer periods of time.
APIs could trigger blame game
Communications API services require integration to use them. Taking a communications API and stitching it into your business processes will only work once that integration takes place. It is also tailor-made for your enterprise, which is a blessing and a curse.
It's a blessing because the communications API fits your business perfectly. And when it doesn't, you modify it to fit.
The important part is how downtime is managed and how the owner of that downtime improves as time progresses.
It's a curse because communications API services create more dependencies and moving parts. As you control the final application, things can go awry, and you'll spend time finding the culprit -- is it you, or is it the API vendor? You'll need to monitor for that. Keep your own SLA and monitor the SLA of your API supplier.
Ready-made services usually fit your exact objectives. A contact center is an example. You can use it with little integration into other systems. It's a stand-alone piece that is less dependent on other business applications running alongside it. API-based products require more intimacy.
With ready-made services, understanding and maintaining an SLA is easier because you have a single throat to choke when things go wrong.
What is the SLA all about?
With any on-premises service, the enterprise customer manages it, so you ultimately own the SLA.
Infrastructure as a service is hosting the application in a public cloud. In that instance, you manage everything from the operating system level and above, including the middleware, runtime, data and application.
API platforms tend to manage everything up to runtime, as in platform as a service, leaving you to manage the data and application itself. This could create some ambiguity in where the API stops and your application starts, which can cause friction with issue resolution.
Software as a service is ready-made cloud-based applications. They manage everything from top to bottom. You have less control on managing and running the system. But, more often than not, vendors can do it better than you because of their scale and focus.
You will experience downtime no matter where you are headed. The important part is how downtime is managed and how the owner of that downtime makes sure to improve as time progresses.
Next Steps
Heed the three roles of API management and administration.
Take a holistic approach when evaluating vendor API services.
Forecast communications traffic before deploying APIs.
Dig Deeper on Communications platforms and integrations
