Service Management, or lack thereof, in B2B APIs

With the advent of (Robotic) Process Automation, (IT Operations) Automation, (Industrial) Internet of Things, Service Integration and Management,  the importance of the internal and external APIs has been steadily rising. One thing I constantly feel is missing is the Service Management side of the equation. I briefly mentioned the need for Service Management in my previous post here and now I am continuing on that idea.

Missing Service Level Agreements

Over the course of my career, I have been architecting and developing numerous integrations between vendors and customers for (IT) Service Management purposes. At times I have been working for the customer, other times for the vendor and sometimes even both sides or just internally within either party. During all of that time, I do not recall ever hearing customers OR the vendors stating any Service Level related requirements for the integrations.

Error handling has always been on the agenda, but never have I heard that a vendor promises their API to be e.g. 99,95% available or being able to handle so-and-so many API calls per minute. Nor have I heard the customer requiring for 99,99% pass rate for correctly formatted API calls. There are usually multiple systems through which the calls must pass so there are breaking points after the initial API.

For the average (IT)SM system to (IT)SM system integration the issues with integrations are usually handled by Service Desk on either side calling the Service Desk on the other side in order to continue solving the original issues reported by the customers. As long as the volume of information to pass back and forth is small enough, everyone agrees to go along but weekly or monthly meetings are held to complain about the situation.

Why you should define and require SLAs for the APIs?

So if everything is (sort of) working, why do I feel the issue with API Service Management needs to be brought up?

As a customer, the API your vendor provides for any purpose is a SERVICE you are paying for. Hell, you may have even directly paid for the implementation of the integration. Even if you do not see a line item in your invoice, the price is baked into other services like Service Desk or Capacity Services, so you should know what level of service you can expect. Another thing is that in future the amount of data being passed back and forth is set to increase and your Service Desk will no longer be able to pass the information to your vendor fast enough in error situations. Additionally your organization is losing boatloads of money to lost productivity outside the SD and IT Dept when there are unnecessary issues.

As a vendor you should be able to tell your customer what level of service they can expect, in order to avoid needless confrontation and associated monetary and brand damage in error situations. If you are a SIAM broker, you are a customer to your vendors and you should read the customer paragraph as well. As the data amounts increase, your Service Desk will be in even more dire situation if there are issues with integrations as they will be fielding calls from customer and vendors alike while trying to get hold of the 2nd and 3rd level teams to fix what ever is broken.

So while the SLA will not necessarily remove the issues it sets the expectation for both sides and allows each party to quantify the associated risks and resourcing needs. When the expectation is set, the unnecessary escalation and blame games should reduce to zero as long as parties maintain the promised level of service.

Scenarios

In order to prove a point, let us consider a realistic situation in a  hypothetical organization.

Imaginary Leprechaun Inc (IL from now on) is a toy company which has a thin internal IT organization. Most of the IT has been outsourced to Big Outsourcing Company Inc (BOC from now on), which acts as a SIAM broker and for example manages cloud capacity from Amazon Web Services (AWS). IL has an internal service portal through which the IL’s Lines of Business (LOB) can instantiate new IT environments to AWS. As the AWS account is behind BOC, the calls will need to be passed via BOCs system to AWS and back again. In general the larger outsourcing vendors, and customers, have one or more integration platforms thrown into the mix, so this is a simplified diagram.

As the Service Manager for Cloud Services at IL, what level of service can you promise to your LoBs if you have no idea what the level of service you can expect from BOC’s APIs or your own system’s APIs? What level of service can you promise to IL as the account manager at BOC if you do not know what level of service your APIs promise or the APIs of the AWS and IL?

While the aforementioned is quite strictly ITSM related, the same logic applies to any other business to business API use.

If the imaginary company was Mad Vegetables Inc (MV), which specializes in growing vegetables in automated growing facilities, they would have a datacentre’s worth of sensors and automation in those facilities. All feeding huge amounts of telemetry data to a management system(s). When telemetry data indicates an issue, the management system would alert an internal or external party. E.g. if there’s an issue with watering system, the management system could alert a plumbing company. If the plumbing company does not provide any indication of the service level of their API, how can MV trust that their vegetables do not die because of an issue in plumbing company’s API? Or due to an issue in the management system’s APIs? As the business decision maker or IT decision maker in MV, can you take that non-quantifiable risk?

Conclusions

I leave the conclusions part to you in this case, but I have a question to you. Do you know what service level you can promise to your internal or external customer or what level of service can you expect from your vendors?

I am planning on writing a separate post regarding what an SLA for an API should contain, so stay tuned. (EDIT: the next article can be found here)

If you are interested in discussing Service Management in the age of automation and APIs, do not hesitate to contact us via our pages or engaging with us via LinkedIn, Twitter or just plain old skype/phone call directly to us in person.

Julkaistu 17.02.2017