In this presentation, Andreas Krohn of Dopter explored the impact of private, partner and public APIs has on business. He touched on:

• The pros and cons to providing APIs open for all, for just a few selected partners or internally.
• How to maximise the value of each type of API and what technical impact does the different types of APIs have
• How internal workings of an organisation and the public image of that organisation is impacted by using private and publishing public APIs
• How do you move an API from private to public and how do you pull back from a public API if it does no longer server your business. There are several companies that has already done this and there will be more in the future.

Slides

The slides for his presentation are available on Slideshare:

Video

The session was recorded and is available on YouTube:

Transcript

The full transcript of his presentation follows:

All right. I’m still Andreas Krohn. I am going to talk about the business impact of private partner and public APIs because it impacts the business very differently if you have an open door or if you have the only one with the key. Both of them are very valued used cases, and you can make a lot of money doing both but you need to know when you’re going to do them and why you’re doing them, and make it a conscious decision.

First of all, we’re going to talk about technology. API by definition is something technical, but it’s important to involve the business in this because technology should serve the business. It’s not something programmers want to hear because it’s much more fun if you just need to write a fun code. Unfortunately, we need to make money as well. We need to think about the return of investment. Where do we get the most bank for the buck? Where does it make sense to invest our time, and our efforts, and our marketing?

I am going to compare the private, the partner, and the public APIs. First, let’s see what I think the common picture of reality is, and that is that maybe 15% to 20% of the APIs are private. Be it more partner APIs but mostly, we’re talking about public APIs, Twitter, or Facebook, and so forth. If you look at the return of investment, maybe you can make some money on private APIs. Maybe that represents 10% to 15% of the total ROI for APIs. Be it more for partner for APIs but most of the money you make are public APIs.

This is certainly the picture I had of reality up to a few years ago. When I came to a conclusion that no, this is probably not the way it is, and there is a warning here that this extremely unscientific. I don’t have any official numbers because it’s very hard to get numbers for private APIs because by definition, I don’t know about them.

Let’s look at something that’s a bit closer to reality. There are lots of private APIs. That is most probably the most common type of API in the world. An API that we don’t know about because it’s used internally on New York Times, BMW, or any big bank, and so forth. We don’t know about it. If Maersk has an API to handle their container shipments in Asia, why should I know about it, and they certainly don’t want to give me access to it, but there is still a lot of activity there, and there is a lot partner APIs.

There is actually very few public APIs. Those are the ones we hear about but there are not that many around. Programmable web has a directory of APIs, public APIs. They have about 10,000 there. They’re still only a fraction of the APIs that only actually exist but that’s just public APIs, and I don’t think that’s enough to cover it at all. There is so many more private APIs. We shouldn’t ignore that. It’s easy to ignore because we don’t see it. We can’t play with it.

When we look at the return of investment, I would say that maybe 40% of the money made with APIs is from APIs, about the same from partner, and less from public APIs. The public APIs here, it’s very skewed because there is a few that is super popular, and most of them are not popular at all. It’s actually a very common problem in public APIs. You have an API but you don’t have any users which is a waste of development investment. This is probably closer to the truth. Now, I had done lots of caveats here.

Let’s begin to what is a private API. It’s something used internally in an organization. You trust the users. You know the users. They’re within your firewall. They probably signed the same employment contract you have, and you don’t really have any business relationship with them. There is always internal relationships but you don’t need to sign a new contract. You don’t need to go outside of your business to deal with these guys. If we think about private APIs, you can actually divide that even to two different two types.

The most common is what call Custom. It’s when you have one API to one client. We need an iPhone app. Okay, we do an API for that. The API is built for that iPhone app or that integration, and that’s it. It’s built for one used case to solve one problem. It’s a specific technical solution. It’s not a strategy or anything. It’s an API to solve this specific problem. That means that the business impact is zero. You’re not going to reuse this. You have solved one problem. That’s it. Very, very common, and if you’ve done this which I am sure some of you have, you should consider doing the next step instead which is to have self-served.

That’s when you design a private API as if it was public. You ignore your internal data model. You don’t use your SQL tables’ column names in your API. You rethink how the data is used from the outside in, how would people actually like to use this data? Never mind how the backend looks. Once you’ve done that, you can have some internal portal where other people in your organization can reuse your API without you having to do any manual work because you’ve already done the work. You have already constructed this once.

This is basically service-oriented architecture which was very hard when I started working in IT way too long ago. It’s not that hard work anymore but a lot of companies, I mean there is a lot of money in service-oriented architecture, and this is it, the internal services that you can reuse.

Impact here is medium to high. Again, I wish I had exact numbers here. Maybe next year. Also, you can get high return of investment if you were a big company. If you are General Motors and you have an internal API, there’s lots of potential users. If you’re a three-person startup in Copenhagen, maybe you don’t need to have an internal resource portal because you can just ask the next guy when you have a coffee next time, “How do I use your stuff?” That’s really, the impact really depends on the size of your company. Some examples on private APIs is, New York Times have one which is really good for the internal innovation to get out new infographics, new interactive experiences, and so forth about all their data.

Then, there is private APIs. We look at partner APIs used by trusted partners. These are people you’re already working with. These are people you trust. You know who they are. They are not thousands of them. There’s probably a handful of them. There are a few, and you know them, and you have a manual business relationship with them. You have talked to them. You have called them. You’ve met them. You know who they are. You know what they want and their needs. Much higher level of trust than if you open it to everybody. Even if I say higher level of trust here and in private APIs, you still need to have security on all those levels which is going to be mentioned at later presentations.

Partner APIs are perfect for fast, quick or very easy, fast integrations. Great to be able to take care of new opportunities, find new partners. I have met so many companies that have a partner just because they have an API. The partner was looking for somebody to do invoicing. Okay, who does invoicing? Okay, this, and this, and this company. This company has an API. My developers can spend one day trying to integrate to this company. If it works, we use them.

The other people have to call them. I have to meet things to set things up. I maybe have to FTP things, and fax things, and so forth; and here, I can just get going. That is a big difference. Even if you have a partner API, it might be publicly documented but people can’t use it unless they have an agreement with you. That way, you can market your partner API just by having it publicly documented. Impact here, high. This can change your business a lot. I see people smiling here. I hope it has changed your business a lot because there’s new doors opening, new opportunities. If you don’t do it, your competition will.

This is also a great start for a public API. You’re testing something in a small group of people that you trust, and hopefully can get feedback from. Collect feedback early. Design from the outside in again. How would people like to use this? Ignore how your backend looks but how do you set up the used cases, the data model, and so forth. Absolutely use it yourself like a self-service model. It’s very important.

Public APIs. Open to everyone. It doesn’t mean free. Charge if you need to. It’s your data. It’s your business. Just because it’s open to everybody doesn’t mean that they don’t have to pay to actually use it. What we have here is an automatic business relationship. If you start using Twitter’s API, you don’t need to meet the Twitter sales guy. You go to Developer.Twitter.com, you sign up, you get an API key, you go. Automatic business relationship.

Of course, you have to click agree on a long American legal list contract that you won’t read but you give them rights to their first bonus. It’s fine. Don’t just sign. It’s all automatic. You don’t have to have any manual. You don’t have to do anything manually here which scales much better, but you don’t know who is going to use it and you don’t know what they’re going to use it for, about the impacts and the design of the API, and to say the levels of security, and so forth.

Also, if we think about what’s successful in a private API, it’s if you reuse it internally. If you don’t just build one app and you build five apps on it. Partner API might be successful if one partner use it or if you get two new partners. That might be a success but for a public API, it’s the usage rate. How many people actually use this in production? Not just sign up to get an API key. How many people use this in production? How many API requests do you have in production? That is the level of success which also that means that you have to be much more in marketing and so forth for your product.

Impact there, very high. Question mark? It means that probably you’re not going to have that much impact but if you succeed, you’re going to have very high impact. With that, Twitter and Facebook are very famous ones. Salesforce would not be where they are today without an API, and now, they’re more cloud-platform, API-platform than they are actually at CRM. The potential impact here is very high.

Use your public API for partners. Then, you might have to call them and have that relationship still because you want to push them into using your API but use it for partners as well, and use it internally. If you have a public API that you don’t use for your own website, your own mobile app or widget, whatever, if you don’t use it, something is very, very, very wrong. If you don’t use your own API, back to the drawing board because then, apparently, it’s not powerful enough for anybody to do something with it. If you have a public API but you’re still sneaking behind that and doing queries to your SQL database, you have some work to do. This is important. If you can’t use it, somebody else can’t either.

If we sum this up and compare private partner and public, first on the business relationship. How you fulfill? How do you deliver this API? How do you deliver this data that the API is going to deliver? What’s the potential business impact? What is more realistic, boring view of this business impact?

We’ll start with the private custom APIs. One API to one client, the technical solution. It’s very manual relationship internally because nobody will know about this. You have used this API in your app and that’s it. You haven’t documented it anywhere. If you’re going to do any changes, you need to do manual changes because it’s done for one used case. If you’re going to use it for anything else, you need to invest time to do it more, to generalize it. No business impact whatsoever. Actually, it could have negative impact if you claim that you have an API, and then people want to use it, and back to the drawing board again, but basically no business impact.

If we talk about private self-serve APIs, I i’s automatic, their business relationship. It’s still internal. It’s not external but people can just see, “Oh, there is an internal API. Cool. I can access the time reporting system this way, cool. I’ll do that for my app.” You don’t need to talk to them. The documentation is there and everything. That can just get going. You fulfill this automatically because you already thought about the structure. You already documented everything. It’s there for anybody to use internally. Potentially very high or at least a high business impact if you’re a big company but realistically medium because most companies are not that big that they can take advantage of this.

Partner APIs. Manual business relationship but automatic fulfillment because you’ve gone to work already. Potentially high business impact and very nice realistically. It’s also high. This is the biggest realistic payback you can get on APIs, to have a partner API because it opens so many doors to do new business ventures with other companies, and to be seen in other places, and be part of the ecosystem that’s online.

Public API. Automatic business relationship. Automatic fulfillment. Potentially very high. Realistically medium. Again, if you get that, others think of it where the numbers go straight up and hundreds of thousands of developers just throw free hours on doing apps for you, you will have some nice payday but if they don’t, you don’t really get the return of your investment.

Where are you going to start? If you’re going to start doing an API, and we consider nothing else than this, where are you going to start? You’re going to start where you realistically get high payback. Then, when you have that, when you tested it with partners, what are you going to do? Why not take a chance of something where you can get a very high payback? Consider this if you’re going to have an API. To start with a partner, and then move into public. That’s where you can also test it on a smaller audience.

Very quickly. If you have a private API, and you want to move it more public, how do you do that? You need to make sure that you design it from the outside in again that it’s useful for other use cases than just yours, and you need to fix all that stuff around it that’s not technical: licensing, pricing, even more security than you need privately, documentation, marketing material, and so forth.

If you’re going the other way like Netflix has done, for example, with their API, you might have a backlash because people don’t like that they have an app, and then it doesn’t work anymore. Tell people as soon as you know. Be honest, “In three months, this is not going to work.” They are not going to like it but that’s better than, “It worked yesterday. No, it doesn’t work.” Tell people in time, communicate and turn key users into partners. If you have 5% of the users responsible for 95% of your traffic, it’s pretty. It makes sense to take those five guys and make those into power users, those five companies.

Mix and match as appropriate. Many companies have some privates, some partner, some public. Take the ones that make sense in every different case, and move them up and down this ladder as it makes sense as well. That’s it for me. Thank you very much for your time.