No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Enhancing the RFP with APIs

I am not a big fan of RFPs (Request for Proposal) and feel that all too often they are a race to the bottom. Instead of proposing the best and potentially more expensive solution, respondents describe the cheapest solution that minimally meets the customer's needs. So, rather than comparing one great solution to another, the customer is often faced with the choice of adequate versus acceptable. In today's business climate where passable just doesn't cut it, a poorly written and managed RFP (which is often the case) rewards the solution that may not be in the enterprise's best interests.

If you've been following my most recent articles here on No Jitter, you will have noticed a great deal of attention being paid to APIs. Whether it's an on-premises API like Breeze, cloud APIs from the likes of Twilio or Zang, or something closer to the bare metal of an IoT (Internet of Things) device, I am interested in what manufacturers are doing to open up their services to third-party developers. For me, it's not enough to simply come up with an out-of-the-box solution. I want to know how that solution can be uniquely shaped to meet an enterprise's specific needs.

So, what does this have to do with RFPs? Actually, quite a bit. I've seen a lot of RFPs over the years -- some I've responded to, some I've helped develop, and some I've simply examined to better understand industry trends. Sadly, very few of them ever mention APIs. They are quick to discuss cost, hardware, maintenance, functionality, and day two service requirements, but APIs are at best barely mentioned or more commonly, completely ignored.

As businesses continue to look for ways to create workflows that increase productivity, lower expenses, and allow them to differentiate themselves from their competitors, the need for comprehensive APIs grows ever stronger. We've long passed the days when dial tone was king. In today's world of multimodal communications, the openness of a system is as important as the features it provides.

In my perfect world, there would be a single API that gives me access to every nook and cranny of a communications system no matter how big it is or who developed it. I would love to write one piece of code that affected everything from calls at the carrier level to that lowly analog telephone hiding out on the loading dock. I want one interface that can be embedded into Web browsers, PCs, tablets, and backend business applications.

Unfortunately, my perfect world doesn't exist, and although some APIs have a pretty impressive reach in terms of what they can do and what they can do it to, there isn't one place where I can go to monitor and control everything. Some of that is due to different products from different companies, but it's not uncommon for a single company to offer different APIs for their range of products. Fortunately, even the worst offenders are beginning to consolidate their interfaces under a single pane of glass.

Given that there are a number of places for APIs to exist, allow me to take a peek into the most common.

For communications, the starting place is typically the API that controls the signaling and media used in voice calls, instant messages, and video. When I first began programming communications systems, the only tools at my disposal were of a proprietary nature (e.g. Nortel's Meridian Link), but by the mid 90s, vendors had adopted industry standard APIs such as TAPI, JTAPI, and TSAPI. While they were more complicated than they needed to be and required a great deal of telephony knowledge to use, they were a positive step in allowing one application the ability to run on many different vendors' systems.

These days, solution providers are moving away from those older interfaces and are supporting RESTful Web services to more gracefully accomplish what TAPI/JTAPI/TSAPI did. However, this ease of use comes with the loss of application portability. Sadly, most vendors' Web services interfaces are as proprietary as Meridian Link was.

Not too long ago, an enterprise didn't have a great deal of control over what happened to a call before it left the carrier. While some carriers offered applications such as AT&T's Route It that altered call flows at the network level, those tools were very static in nature. It was difficult to near impossible to control calls in real-time.

Thankfully, the world of carrier routing is undergoing a revolution and companies such as Twilio, Dialpad, Flowroute, Zang, RingCentral, and 8x8 have opened up their services with some very exciting APIs. Not only can you change the way calls are delivered, but some vendors provide APIs to record calls, send and receive SMS text messages, look up numbers, create conferences, transcribe audio into text, queue calls, and apply treatments. These platform-as-a-service (PaaS) solutions offer everything from SIP trunks to an enterprise-grade, cloud-based communications system.

While many carriers provide Web portals to access and change configuration and routing data, this should not be confused with an API to do the same. Web portals require fingers on a keyboard, while an API allows an enterprise to add these capabilities to backend business applications. With an API, changes can be made in real time without any human intervention.

Enterprises are interested in doing more than controlling signaling and media. They want to programmatically access all aspects of configuring and maintaining their communications data. This extends from password management to adding a new user to assigning that user to a contact center skill set.

It's possible to find vendors that support APIs for this, too, and the best of breed will provide them via RESTful Web services. This allows for standalone applications as well as integration into an enterprise's existing management system.

It's rare to find an enterprise that buys every piece of communications equipment from the same vendor. It may have Avaya in its core, but use Genesys for its contact center. It may buy telephones from Cisco, but its voice mail comes from Microsoft.

The chances of finding common APIs for all these disparate systems is nil, but it's still important that they exist no matter how different they are from one another. Clever enterprises and systems integrators will find ways to tame those differences and create fairly cohesive amalgamations.

Despite the fact that I cringe when I hear the letters R, F, and P, I understand why they are written and jump for joy when I find those that are crafted to find an amazing solution at a great price. However, even the best RFP writers need to step up their game when it comes to APIs. As my article points out, they can exist in many places and a well-written RFP must ferret out who does what and how it can be incorporated into an enterprise's current business. A great product becomes that much greater when it comes equipped with powerful, well documented, and open interfaces.

Andrew Prokop writes about all things unified communications on his popular blog, SIP Adventures.

Follow Andrew Prokop on Twitter and LinkedIn!
@ajprokop
Andrew Prokop on LinkedIn