“Every car in three years is going to have an API”

Earlier this month we had the privilege of inviting a collection of API experts to SmartBear HQ for a panel discussion on the current state and future of APIs.

The panel: Developing an API Strategy for 2017, focused on the challenges, opportunities, and issues facing the API space in the years ahead, and offered takeaway for organizations at any stage of their journey with APIs. Here are some of the best takeaways from that night:

On implementing an API strategy while dealing with legacy systems

“We don’t get to start from scratch. Consumable APIs really started coming out around 2011–2012. Everyone got really excited and wanted to start to putting out APIs. And for people that get to start from scratch — who aren’t in regulated industries and don’t have legacy to deal with — it’s a lot easier. It’s really hard when you have legacy to deal with. Deciding where to even begin is one of the biggest problems.”

Laura Heritage

On providing a great developer experience with your API

“We’re really gravitating more to what Netflix calls “experience APIs.” And also gravitating toward focusing on providing a great developer experience — even if it’s in-house — and providing APIs that allow them to build products that actually provide customer value and not just doing it for the sake of the technical aspect. Because as fun as it is, it doesn’t really drive business in the end.”

Ole Lensmar

On planning from a developer POV

“We have best laid plans, and the second you give it to a customer, you find out how crappy your plans are. For us, with developer experience, it’s about putting whatever we think is a good idea to paper and testing that before we ever commit it to code. Because if we can take that design and show you, the developer, what we’re thinking the first thing you’re going to do is say is “that right there…fix that right there” and it’s going to be the thing we never looked at.”

Matt Bernier

Understanding the value or internal and external APIs

“First we need to think about what problem we are trying to solve. Maybe there are some companies that don’t need to provide APIs. But I think that every single company that has IT department must have at least internal APIs. A few months ago I saw a building company that has internal APIs to provide a mobile application for people who are working for them at building sites all over the world. If a building company can have an internal API, I think everyone can.”

Arnaud Lauret

Explaining the business value of APIs

Looks safe…

“Every car in three years is going to have an API — that’s going to help offer better products. Pretty soon people will say “I’m not going to buy this car because it doesn’t have an integration with Pandora or Spotify.” You’re not going to buy the car because it doesn’t integrate with things. Well, what helps integrate with things? APIs. Ultimately that’s what the business value is.”

Tony Tam

On securing your APIs

“Don’t think that you’re not vulnerable because you are. Don’t overestimate the frameworks that you use that you think will keep you safe. Take security seriously. Don’t just trust the minimal level that you get through the common practices, which is good but you need to take it one level further. Think about the damage it can do, not just to yourself but to your customers indirectly.”

Ole Lensmar

On security in a regulated industry

Favorite cake flavor? API.

“Security is not the icing on the API cake. You have to deal with security from the start.” Arnaud Lauret

On using description formats to help technical and non-technical teams work together

“API design tools have matured to the point that you can document an idea — an idea doesn’t need to be technical — into something. And guided through the process, you can produce some amazing things. I can’t say that we have enough data to say that better APIs come from that but it’s popping up all the time.”

Tony Tam