Skype for Business Trusted Application API - Part I

Now that the latest interface for programmers to talk to Skype to Business has gone public preview it's a great opportunity for those of us who have been working with it to share what we have learned so far.  So first things first, there are things in the SDK that I am going to abbreviate, because they are too long to type repeatedly.  Here are the abbreviations I will use going forward.

TAP - Trusted Application API
SE - Service Endpoint
SFB - Skype for Business


What is TAP?
TAP is Microsoft's vision of a cloud first replacement for UCMA.  UCMA as you probably know only works with on-prem SFB.  TAP is meant to fill the gap of UCMA feature loss to hybrid and cloud only deployments of SFB.  So is TAP a 100% feature parity replacement for UCMA?  The answer is no, and sadly it is missing several key concepts that I would love to see.  That being said, it is step in that direction, where they was nothing, there is now something.  To me, TAP is more of an extension of UWCA that a new SDK.  I like to think of it as splitting UCWA into 2 pieces, a user interface and a service interface.

Microsoft published this graphic to help developers understand where TAP fits in the SFB Developer world.

What can you do with TAP?
Think of TAP as a service in the cloud that you assign an uri and/or telephone number to.  It can interact with audio/video calls, or instant messages.  Knowing this it doesn't take much imagination to think of some things you could build with it;

Bots that can interact with customers
Notifications from your service triggered by your other apps (the plant is overheating)
Anonymous chat for your help desk to help customers
Anonymous conference calls for same
Custom IVR
Custom Queue / Response Group
Custom Auto Attendant
Call Recording

Advantages of TAP over UCMA
I mentioned before that TAP lacks several key UCMA features at in it's first version, but that doesn't mean it can't do certain things better, I believe it can.  Let's think about an app in both worlds, that answers a call, uses an IVR to find the right team, transfers the call, and records the call.  This can be done in both SDKs.  Since TAP is really built to run on Azure, think about what that can do for you.  Yes, you have a similar amount of work setting up the app, the SE, and deploying it, but let's examine this scenario in the real world.

Company A deploys this app on-prem using UCMA
Company B deploys this app in o365 using TAP

Company A has 500 employees
Company B has 500 employees

A little while down the road...

Company A has to figure out a process for moving recordings periodically and storing them somewhere else, was well as backing them up offsite in case of a disaster.  They have physical disk and cpu limitations.  Yes they can buy bigger servers often and more storage, but that process will never end, especially if the company experiences a large growth in size.  Company A can have times of high CPU utilization with high call volume, as resources can spike for speech to text in IVR, and voice recording.

Company B can automatically scale up their usage during high call volumes, and scale it down when there is no call volume at night, so they only pay for what they use.  Company B can deploy multiple instances with a single click, load balancing, backup, and get pretty much infinite storage space.  Company B is not without it's problems, they are just different, with 500 employees dependent now on a connection to the internet for voice since the only was to get pstn audio to a TAP app currently is with a service number from SFB online.

So as you can see they are things that are certainly potentially things that TAP can do at scale easier than UCMA could.

How Does TAP Work?
As I alluded to earlier TAP is a Restful API just like UCWA (not to be confused with UCMA).  This means a big change in how to write and deploy an application for UCMA developers.  This has been a learning process for me, and starting next week, when we begin to write our first TAP application, I will attempt to impart some of what I have learned along the way.

Doug Routledge, C# Lync, Skype for Business, SQL, Exchange, UC, Full Stack Developer  BridgeOC Bridge Operator Console Twitter - @droutledge @ndbridge