‹/› Devsworld News

Devsworld Home

Temasys Trio Readies for All About the API Event

By Paula Bernier
July 14, 2016

Temasys, whose technology is in use by more than 2,500 developers and businesses to provide WebRTC-based solutions, will host the API Live event July 19 at the All About the API show. Also at the Las Vegas show, CMO Chip Wilcox and CTO Sherwin Sim will lead the In-App Real-Time Communications Tips, Tricks, and Traps session, which will cover best practices in building, buying, making and renting platforms to support real-time communications in apps and on the web. And Wilcox will be the featured speaker on the Marketing: You’ve Created Your APIs, Now What? session, which will take place July 21 at 10 a.m.

We recently interviewed director of engineering Nat Currier, Sim, and Wilcox to learn more about Temasys, its customers and why APIs are so important to them. Here’s an excerpt of that conversation.

What new business opportunities are being driven by the API economy?

Business models are really being split up into components because businesses do not have to hire a full team that does everything for every function, including the technology components, from top to bottom.

Now what happens is that businesses can leverage vendors, partners and experts in a given functional area much more easily by using APIs to deliver best-in-class tech and functionality vs. trying to build everything they need in the way of technology and tools by themselves. It reduces execution risk, it can reduce total cost of ownership, it makes businesses scale more effectively/efficiently and it speeds up time to market. This creates opportunities for businesses who are really great at just one thing to help lots of other businesses who don’t want to worry about that one thing, or would otherwise not be able to do it themselves, to access that service, easily.

Is there a market for APIs you would consider the low-hanging fruit? 

Everyone seems to be looking for the bowling alley in terms of the next big thing for APIs. In broad terms, companies that have built a great software-as-a-service product and are looking to get even more reach and stickiness for their service are all most likely looking at ways to open or market an API to at least some parts of their SaaS products and to say they are a platform.

A great example is how companies focused on reporting, analytics and data visualization have popped up all over the place. Take Xero.com as an example – great accounting software; affordable, flexible; a startup CFOs go-to app. While it does reporting, it has pretty weak analytics support. That said, there are quite a few reporting and analytics companies that can use Xero’s API to build really great dashboards and combine Xero’s data with other data from Google Analytics, for example, and create really great insights analysis tools. This all started with companies like Tableau and its desktop apps, but now there are tons of analytic tools companies out there. What’s hot now? We hear fintech, e-learning, health care and a ton of things around the Internet of Things. However, I think people are also starting to understand that IoT means a lot of things to different people, with different types of services and different technologies supporting those services. Wearable tech is old news. [What’s important now is] connecting and learning how to use all the data that’s being generated out of the phone, the wristbands, the sensors, and tying those things together into easy to use services that have practical applications. That’s a few years away yet.

What are the major challenges API developers face?

By itself and from the perspective of a developer, building an API is easy. The tools are mature, and there are countless options out there that work exceptionally well. The real value in an API comes from producing data that has value and which is relevant to the end user’s business, and doing that better than the competition.
The challenge is rooted in the algorithms and intelligent data processing, like forecasting/ trending and analysis.

You also need to have really great documentation. This is often the last thing people think of, but it makes a huge difference in reducing the learning curve for people who are just getting started with a given service.

Once you have users, you need to encourage them to give you feedback, and you have to take that feedback, and build it back into your product. A lot of the developers we talk to get frustrated when they don’t feel they can ask for help or provide feedback when what they really want is to implement their ideas, and just tweaking a couple of things here or there would not only help them, but make our product better all around.

Who should businesses target when marketing their APIs?

This is a good question. APIs really aren’t generic services. Everyone can have one, but usually an API has a specific purpose, and it has to support some functionality that is necessary and do it really well. Assuming you get that right, then you need to market that API to the kinds of people that have that specific problem you can help them solve, or a developer audience that you can define, which focuses on supporting that particular part of the business. Your audience is a lot more fragmented and you can’t really say ‘I target the C-Suite.’ It is also critical to have domain expertise in a given functional area if you’re selling or marketing an API service to a specific vertical. You could be talking to a CTO one day or to a random developer the next.

You could also run into a CEO or other business person on an airplane at any time, and you’ll have to answer that question: So what does your company do? You need to have a message that each of these audiences can digest, which can communicate your value proposition in a way they understand it. Not everyone’s great at talking to C-level people, and it’s even harder to talk to developers.

My favorite advertisement from Silicon Valley, from the last couple of years, is the giant billboard(s) that Twilio put up along Route 405 between San Francisco Airport and downtown San Francisco. In big letters it had the words “Ask Your Developer.” The only other thing on the signboard was the Twilio logo. I think it’s pretty clear they don’t really want to talk to CEOs. This is what I think when I see that sign: Talk to your engineering team, and they’ll talk to us, because we get them. You? We don’t get. Don’t ask us what we do. Talk to your developer!

Companies like Twilio, Stripe, Braintree and others are really great at talking to and talking like developers. Which brings me to my last point: Evangelism.

The role of the developer evangelist is one that is increasingly important and often misunderstood. Being excited about what you’ve built is great. However, it’s the ability to get other people – developers – excited about what they can do with your API that is the most important aspect of marketing an API.

It’s not about what you already did with it (if you’re a SaaS). It’s not about what other people are doing with it, today (though case studies are a good marketing tool). It’s about what your followers and potential customers could do with it, and convincing people that your API can help solve their problem in the best, most elegant, cheapest or fastest way (insert any other USP descriptor you want). Plus, you’re cool to work with.

This is a very particular skill set that a good developer evangelist, and a community support team, will have. So get used to spending lots of money on what will seem like very high-priced engineers who know how to talk business-speak to your CFO, and who like to hang out at meet-ups, hackathons and coffee shops talking about how awesome your APIs are all day long. They are worth every penny if they can convince hordes of developers and the companies they work for to use your API.

There are many other things we could talk about when it comes to marketing an API or SDK, and we will try to cover some of those in the Marketing: You've Built Your API, So Now What? session we’ll be speaking at this week.

How do you measure the ROI of APIs?

If you are building and marketing an API, it’s possible to apply many of the same metrics that you would to software-as-a-service products and services API. Your customer profile changes, but you can measure acquisition costs; other audience metrics, like new users, churn, actual usage; and you can use monthly/annual recurring revenue and other financial metrics that SaaS businesses use. If you’re a business that is using an API, you can evaluate the ROI by looking at the total cost of doing whatever that service helps you do vs. buying a piece of software or building it yourself. Instead of having to build services and infrastructure from scratch, which could, in part, be capitalized, you turn these costs into opex, and you go from fixed to variable costs, as you often pay for API services based upon the capacity and usage you actually incur. You look at productivity/efficiency metrics, from an operational perspective.

What about API security?
This is firmly rooted in the nature of the product of your API. If your API delivers sensitive data, this falls firmly in the realm of the API provider’s responsibility. Given that APIs are generally very structured and by design easily leveraged, this can be a very challenging task. If your users know how to manipulate requests, and you are providing documentation on how to do exactly that, security needs to be your first concern rather than a housekeeping task. The people who will attack your API are not general consumers, they are people who know what they are doing and will make every attempt to outsmart you in hopes that you overlooked something or tried to hide something in plain sight. It’s a game of chess, or a game of whack-a-mole, depending on how much sleep you’ve had in the last two weeks.

Which is better, SOAP or REST? 
REST has the upper hand here for sure, purely in the fact that it’s consumable by more devices, it’s a standard HTTP request that everything from a modern toaster to the latest hyper computing cluster can access off the shelf for the most part. SOAP certainly has its use cases, particularly in large enterprise, but the key to most APIs’ success beyond the data or service itself is reach.

How often are APIs changed or updated, and how do you do that while ensuring minimal disruption to users and their customers?
Here’s the goal: A well-designed API doesn’t change; it evolves and extends itself. In reality, this isn’t always possible. Future enhancements should always be considered at design time, and you want to avoid having to handle constant migrations. Your customers shouldn’t need to continuously invest in learning or re-learning how to use your product. They should be paying you because your product always works as expected, predictably and reliably.

What standardization is needed to drive mass adoption of APIs across verticals?
REST as a practice has already helped by providing a common access mechanism. Within specific verticals, it’s harder to say. Mass adoption of API use has already been achieved. The average software user, or netizen, already uses countless APIs throughout a typical day, despite likely not even being aware of it.

I could certainly see standardization of APIs related to things such as transportation services, government data, environmental data, medical records and the like, which would go a long way to drive adoption in those areas. However standards can also be a barrier to innovation and in many of these spaces innovation is paramount.

How important is building an ecosystem around your API(s)? 

This greatly depends on the nature of your API. Consider the Facebook Graph API as an example. Without the social network that feeds it, it would be almost useless. Facebook’s massive audience and all of the data that its users generate around social interactions are what make the Facebook Graph API really valuable.

Therefore, if your data is self-sustaining, and the value you are adding by exposing an API that accesses that data is worthwhile, then your API can exist purely from that added value proposition without needing an active or vocal community around it. If you’re trying to drive adoption of a new technology or build new services for a given vertical, then it will pay to invest in helping the ecosystem that you’re participating in be successful. You need to respect the other participants, and while you may not want to help them be more successful than you are, competition is a good thing. It inspires innovation and can help drive faster growth for everyone involved. The adage, a rising tide lifts all boats certainly applies.

What differentiates one ecosystem from another?
Ecosystems around APIs can vastly differ from one another in their role in interaction with the API. As we mentioned above, the Facebook user ecosystem and the data that this audience generates fully sustains the API that Facebook exposes to access that data. It doesn’t really need to interact with anything else. It powers itself. On the other hand, if you look at what Google does with the data it collects, it uses it to build lots of APIs that interact with each other and augment each other, complementing the different services and making them more useful than leaving them as standalone apps and APIs. This includes Google Maps, Photos, Google Earth, Google Places and so on.

There are companies that have to build APIs to their services if they want to get any traction at all – look at the ApplePay or SamsungPay services. ApplePay will not work unless it builds a service and API that can speak to the point-of-sale ecosystem players and the tools and services, and the APIs that power that ecosystem. The entire online travel industry has become an incredibly interesting and powerful example of how APIs have transformed an ecosystem over the last few years. Travel APIs are what has created the entire travel comparison and aggregator space, out of necessity, as airlines, hotels, car rental companies, and others have looked to optimize yield and price management and have specifically cut out traditional travel booking services and agencies. And now, those agencies are also building and leveraging APIs as they work to differentiate their services and take back business that the travel aggregators (Orbitz, Kayak, WeGo, etc) have taken from them (look at Nextravel.com).

Why should attendees at All About the API make sure to attend your sessions and visit the Temasys booth?

We have a really cool pong game we use for demos. And we have beer coolers. Plus, we’re really cool to work with. Okay, that’s all true, but we also say we “enable interactions for everyone, everywhere, and in everything.” If you have an app that would benefit from adding real-time interaction points between your users, we can help you do that, quickly and easily. Let us show you how!

Edited by Alicia Young

Executive Editor, TMC

Related Articles

Telecom API Market Set for Big Gains

By: Steve Anderson    3/24/2017

A rapidly increasing need for APIs and similar measures is expected to drive big gains in this market through 2021.

Read More

Flowroute to Discuss Common API Mistakes at All About the API

By: Alicia Young    2/8/2017

Doug Waller of Flowroute will be taking part in a panel at the All About The API event, collocated with ITEXPO, to discuss common mistakes that occur …

Read More

Wear Your Lifestyle with Google's Awareness API

By: Alicia Young    2/8/2017

Google has teamed up with H&M's digital fashion house Ivyrevel to use its Awareness API in a unique way. The duo wants to digitally design customized …

Read More

10 Trends that Will Impact Open-Source Technology

By: Special Guest    2/8/2017

Open source has become an integral piece of every developer's arsenal. The power of the community, the wisdom of many, and the ability to hook into va…

Read More

What the Google Hangouts API Shutdown Means

By: Special Guest    2/6/2017

Google's in an interesting place with Hangouts and chat with both the enterprise and the consumer. One thing is clear - what it's doing with Hangouts …

Read More