Number of API calls is a terrible metric, we don’t recommend that because it’s a cost metric, not a success metric
For our latest “What I’ve Learned…” interview at OpenChannel, we spoke with Steve Willmott. Steve is one of the world’s leading API infrastructure and partner ecosystem strategy experts. He’s co-founder and CEO of 3Scale, which recently joined the world’s largest open source company Red Hat, where he’s Senior Director and Head of API Infrastructure. He’s a contributor to community efforts like Open API Initiative, the APIStrat conference series, APICommons and APIS.json. Prior to 3scale, he was a senior researcher in distributed systems, distributed artificial intelligence and semantic web technology, authoring more than 100 publications. He’s also coordinated R&D projects under the European Commission’s Framework and been an evaluator for the European Commission and NASA Intelligent Systems. He’s played major role in the adoption of web APIs, and spent some time with us to share what he’s learned along the way…
OpenChannel: When engaging developers and partners around an API, what can companies do to instill trust in their ecosystem?
Steve Willmott: Great question. Trust is primarily derived from your objectives. You need to clearly communicate the objectives for you and your company over the long term. Then developers can know whether they align with those objectives.
When you have an API and developers using it, you need to know why you want them there. Are they paying you money? Are they enhancing your products? Will they increase your reach? What’s the value to them commercially? People assume developers will just show up and build things. They don’t think about whether they can build something meaningful they’ll get paid for?
Being clear is important, it allows you to communicate your roadmap and say where you’re going and how you’re trying to enable them. If you haven’t thought about your value and their value, then you end up making a U turn. That makes a mess of what developers have built.
OC: What are the indicators a company should look for when building a developer or partner ecosystem?
Steve: A lot of companies come to us and want to build a partner ecosystem. We ask certain questions and there’s two kinds of cases. One is that the company itself has decided this is something they want to do, which can come right from the CEO.
The other is they’ve got demand. Developers and partners are asking for access to APIs they can’t give them today, or they can but it’s really expensive. This can be powerful because you have a driver. You have a set of developers that really want access to data.
Then the questions we ask are “how many requests are there? Will it be ten developers that are going to be driving this or is will it be thousands?” That tells you how to move ahead. Is it marketing driven, or is it going to kept mostly private where you invite partners?
We ask and encourage the company to think about what the target market is. It’s an extension to the product and sometimes there’s too much pie-in-the-sky assumption that developers will just show up and build. Identifying those that really value what you’re doing is important.
Another area is they don’t think through the use case. For example, a large retail API we work with produced an inventory API. You could query what’s in stock, stock location, images of products, pricing and more, but there was no way to transact. Essentially, there was no motivation for anyone to build because there’s no way they can get paid or actually add value. It’s about thinking through the entire effective use case.
OC: You talked about understanding the use case. When creating a partner ecosystem what other critical early steps should a company take?
Steve: One of the most critical is having a beta period. We’ve seen companies launch to big fanfare and as a result commit to the API they launched on that day. The reality is, it’s almost impossible to get it perfect from the beginning. You want to be able to iterate. You don’t want to sign people up to that first version without warning them there could be changes. You’re either going to hurt them or you’re going to lock yourself into something you don’t want to support.
It’s just as exciting and press worthy to launch an API but have it tagged as a beta, it protects you. Do six or nine months of that at least allow yourself to break stuff with people using it.
OC: You answered to this Quora question 5 years ago talking about the web transitioning from a read and browse web to an API driven and programmable web. We’d say you nailed it but how do you think that transition is going?
Steve: I lucked out but there are a lot of things that have gone right. It’s somewhat accidental because it’s driven by mobile and things like single page apps have perpetuated APIs. I think there’s a huge amount of progress that’s been made.
There are areas where the visible progress covers some underlying things that haven’t happened yet. We’re using APIs to communicate between users and end systems but it’s still human driven activity driving most of the traffic.
I would expect the next five or ten years to be more device and sensor driven activity. A lot of APIs will not be responding to a human action but instead be responding to something in the environment. That’s going to be a huge change that we all have to get ready for.
We’re still relatively poor at API design. I’m excited about the OAI (Open API Initiative) and the OAI spec becoming more broadly adopted. It’s come out as the winner of the API definitions. There’s a lot of companies getting onboard and that’s critical. A lot of new tooling is also being built around it and that’s going to help us automate a lot more of the interfaces and design.
There’s still a cloud on the horizon with copyright. I don’t know what’s going to happen with existing court cases, the copyright of APIs and whether they’re even copyrightable. I think it’s a huge problem because the standard argument you’ll see, and the one I think I subscribe to is that a lot of APIs are by nature going to be very similar. So copyright very quickly trespasses on the only logical way to a certain thing. There’s only so many ways you can write a query API. Copyright court cases are chilling because you are worried someone will claim it and then sue you for it.
It would be great if every industry had standard APIs that were copyright free that you could clone the interface for. The data doesn’t have to be free, the service does not need to be be free, I’m talking about the interface being free. That means all the apps and UIs can already call this API with only need a minor tweak to work or even no tweak at all.
OC: You were early in the creation and adoption of web APIs, what do you think people are underrating when you look at the next 5 years?
Steve: One thing that’s going to be recurring is security. It still has a long way to go and it won’t be a single solution that solves everything. APIs will continually need to defend themselves and keep evolving.
Traffic rises could be much more spectacular than people think. There’s a lot of web traffic now but if you look APIs and the web in general, there’s huge growth. I think we’ll get into a situation where many APIs will routinely have enormous amounts of traffic flowing backwards and forwards.
Voice is critical. Amazon Alexa and Google Home have changed the way people interact with information. I think it’s underrated how how different it’s going to be because I’ll no longer open my laptop to browse for information, I’ll just ask, and APIs are at the root of that. You have to change your API design somewhat for voice apps because you need to filter more for the most relevant results. You can’t give people 20 results on a screen and have them click the one they want. I’m expecting desktop and laptop screens to disappear and a lot more stuff to be done by voice.
I bought an Alexa two years ago and I now use it every day. It helps me set timers, I’ll ask what’s my agenda. Simple stuff but compelling. We wrote some apps for some of our customers and I can see it spilling over into the work environment.
OC: When a company has an developer or partner ecosystem, what are the most important metrics to track?
Steve: First of all, “number of API calls” is a terrible metric, we don’t recommend that because it’s a cost metric not a success metric. I want to know how long it takes for someone to get on boarded. It’s their “Time to first hello world“. Another is “Time to first dollar”, being the time it takes someone to release a productive app. “Hello world” is not necessarily productive.
For health of the community, things like NPS (Net Promoter Score) do help. Knowing whether or not people are recommending you is just as important for an API as it is for a product.
I would look at the top 10-20% of active users because those are the ones that are creating the most value. Are they launching more apps? Will those apps become public? Are they being adopted? Are they valuable? There isn’t really a number you can put on it. You have to reach out on a regular basis and see how things are going. I think the health of the top of that pile is your most important thing. What you do to fix that will very likely trickle down as value to the other folks.
There’s one more internally. When an API program has been launched It helps to quantify the dollar value to the company, and often companies don’t do this. Let’s say you’re a car rental company, you should quantify how many bookings or how many new customers go through the API. Then figure out how many dollars that’s worth because that is actually ultimately the only argument that matters for the business.
OC: Does that mean any API program and partner ecosystem have to be monetized?
Steve: People assume that for an API to be valuable you have to be monetizing the API itself. Only about 20% of our customers do that. The rest are successful without monetizing their API. That means they’re driving supporting partners who are driving business to the company’s core business or they’re adding value to customers allowing them to integrate with the API and do more business with the company.
It’s less often that direct monetization and more often a compliment to one of the core products that creates the real value.
OC: What platforms or API communities do you really admire and why?
Steve: One is clearly AWS and for more than the obvious reason of it’s very big. Amazon has a reputation of creating products that can overlap with their partner ecosystem which can be negative, but it’s hard to think of another company that has enabled internet infrastructure in the same way. Not every company is going to be Amazon but it’s a successful mix of an entry level product people can use and then allowing them to build on top. Then they promoting how everybody fits together.
The other area is the API community in itself. There are conferences like API Strat which I’ve been involved in. There’s also GlueCon, RestFest and others. It’s one of the most collaborative industries I know, where companies work well together even if they compete. Everyone’s looking at the big picture and are trying to move the world forward rather than just their own agendas.
OC: What are the major mistakes that you see when pursuing an API and partner ecosystem strategy?
Steve: When you open a partner ecosystem, conflict can come from the fear that the business will commoditize itself and partners will take a piece of their pie. That can happen if you open the wrong things but it just almost never does. So the problem is you get the wrong mindset of not trying to grow the pie. With a partner ecosystem it’s fundamental to think how you can grow the overall pie. It’s sad to see when some great APIs are built and some partnerships start up and then this general fear sets in.
OC: Beyond your experience at 3Scale and RedHat, you’ve done academic work in distributed artificial intelligence networks and global scale networks of service platforms. What unique insights does that give you around building platforms?
Steve: Take the current trend of microservices, APIs, and breaking down monolith providers into more distributed infrastructure. That’s a very powerful trend that I believe in. What most people miss is that just by making things small you don’t remove complexity. What you’re doing is moving complexity from inside the monolith to outside and between the different systems. Building distributed systems is really, really hard.
A lot of benefits come for free when you have one monolithic system. We still haven’t successfully built all of the infrastructure that’s needed to manage these distributed systems properly. There’s often a mantra to push microservices and APIs. That’s great but you need to think about the systems you’re building because the complexity is still there.
From an academic perspective, we built a lot of complex systems that are distributed and it was very difficult and you can’t prove they’re consistent. In the next 10, 20 years we’ll have to get a lot better because systems will get very fragile if we don’t pay attention to this.
Grow Your Partner Ecosystem!
Want more from platform leaders at Shopify, Intuit and Box? Check out the “What I’ve Learned…” series.