The Open API Economy - Opportunities and Risks

Good morning. Good afternoon, ladies.

In terms, when, again, my name is yore from, I'd like to welcome you to this webinar called the open API economy. It will be the first webinar where we can have Craig burden as our speaker Craig Burton, who recently joined us as an Analyst who might know his name from the former Burton group.

Now, now taken over by Gartner Craig Burton. I I'm very much honor that you will talk now about the open API economy. Thank you very much. Thanks your hello, everyone. Today. We're gonna talk about the open API economy as, as you talked about, but before we do that, let me just walk through some details. Some quick things about copping or coal cup co does enterprise research, advisory services, decision and support networking for it, professionals through these three services, subscriptions, advisory, and events, the subscription services you subscribe to.

Obviously that's what they call that advisory is more like a consulting service for both European and us companies and events. Of course, it's the, the European identity and cloud conference that happens in the spring every year. And it's become the premier conference on identity and, and cloud.

So that, that there you go. Oh, so it's in April. We will have a, not a track, but in a session on the API economy and I'll be running that and other people will you'll you'll see, who's gonna attend that as we get that put together. So one more thing here, you, everyone is muted. So you can't say anything cuz we have a hundred people registered. There's not that many on right now, but there could be. So with that many people, it, it could get confusing with if everybody could talk.

So if you have a question, even if it's during the presentation, you, you can either raise your hand or type it in and I'll see it and we can stop and address it. And if you type it in, I'll repeat the question to everybody. And so that they know what was said, we will record the webinar is being recorded and it'll be available tomorrow. So in case you wanna share it or watch it again. The other thing is there's a document that I've written about this called the open API economy and it will be available for free to all of the attendees of the conference.

And it'll be sent out either tomorrow or the next day, probably tomorrow. You should get it. So let's get started here. So the core thesis of this presentation is as the presentation name would indicate is about the API economy. And we're taking the stance that, that faking an organization's core competence into an open API is an economic imperative. It's it's not just a fad or something of interest.

It's fundamental that companies start figuring out how to expose their core competence to developers, partners, even competitors, as soon as, as you can, as you, as I think self-evident, it's important to say that, that there are three big trends that are, that are driving most things in all aspects of technology right now, not just it organizations, but individuals, everybody at social computing, mobile computing and, and cloud computing.

And I would add the fourth and that is the open API economy, which is underpinning all three of these things and is going to have a huge impact on how they're used the possibility of identity issues and so on as, as we'll cover. So let me just give you some facts about this, the, the, the growth of APIs, and this is consumable APIs. In other words, things you can get to is mind boggling, look at, look at this graph.

So, wow. I need to turn off Skype don't I thought I did. So it took eight years from when the company who I got this information from, which is John Muer program of web.com for the first thousand APIs to show up. And it started getting real serious in 2005. As you can see here, then it took 18 months for the next thousand nine months for the next thousand six months. It for the next thousand. And that was sometime in August of 2011. So I checked this morning before I did this presentation and we're at 4,581. Now those are just the APIs that this, these guys covered.

So it's probably a lot higher than that. And I suspect sometime in, in 2012, this, this hockey stick growth that you see is gonna hit a, a different level of growth. And it's not gonna just go up at this rate, but go up at even a more accelerated rate. One of the interesting things of the API economy and why I want to that affects the points I'm trying to make is this commerce versus shopping trend, which is really interesting where there aren't that many commerce APIs right now, but that's where people are headed.

Let me tell you the distinction between those that, that the, the traditional affiliate API has where an app goes and looks at a product and sees it, and then has to go to the merchant site, say Amazon, or, you know, whoever you're buying from to, to conclude the sale. And the trend now is to create a commerce API, where from the app itself, you conclude it regardless of where you see the, the product without having to go to the website to conclude it. And now the, okay, where do I see that? Where's the red end. I can't see it from over here.

Sorry, Craig, if I used used Skype. No, that's good. I just wanted to say there is one first raised hand. Should I moderate that a bit or yeah.

Well, yeah, but let's go ahead and no, let's go ahead and address it, but I can't see it. So, So I will now unmute Matthias freak Peterson from, I think he's from wife in, in Denmark. If I understand everything, right. I recently came across wife. It's a governmental institution and did a, they did a great job in, in providing some kind of public API to many institutions there saving a lot of money to those institutions. Maybe Fred would like to talk about that for half a minute. Sure. Actually we don't provide any. Yes that's okay.

We, we don't provide an API. We are kind of a Federation. Yes. Sorry for using the wrong words. We don't have an API.

So, but I would would like to, to hear about the APIs out there. Oh, which ones there are. Yes.

I, I just wanted to listen in, on your, on your presentation actually. Oh, I see. But you raised the hand, so that's why we unmuted you. Okay. I wasn't aware of any, how did I raise your hand then? I don't know. That was a mistake. If Okay. That's alright. We're glad to hear from you. One of the things you can see about what types of APIs there are, is go to I'll provide the link. I don't think I have it in the presentation here, but I may, I'll make sure before we post it tomorrow or today that, that the links to all of these sources that I'm giving you are on the presentation.

But program of web.com is the company that lists and organizes in categories. These APIs, and I I've subscribed to that. And I get a, I get an email every week. And when I started, it was like 20 APIs a week. And it's now up to 90 APIs a week that I have to, that I go through and I look at and see what's happening. And they are incredible. These APIs matchups are made. So you want, you wanna look at that if you get a chance. Okay. So I also wanted to cover more about what's happening in there. This is the, what the programmable web calls, the billionaire club.

Now these numbers, as you look at the dates are actually dated. They're, they're growing almost exponentially.

So, you know, look at Twitter. Now, when I say Google at 5 billion API calls a day, that's not searches. That's not the number of searches. I don't know what that number is. It's a lot bigger than that. This is somebody actually making calls to the APIs that Google publishes to its various sets of services, 5 billion to Facebook look and Netflix, 20 billion AP API calls a month up at it's higher than that.

Right now, the numbers are, are, as you can see through the roof. I don't know if most European countries know NPR is it's national public radio. That's a United States thing where it's a public radio broadcasters and they, they have really done a great job with their NPI. And look at this 1.1 billion stories delivered per month through that API. It's just the, the, and I think another really significant thing that's happening in this list is the amount, the number of all traffic to salesforce.com is right now is 50% of it is through the API.

What that means is that that 50% of traffic going to the data that Salesforce has is coming from third party applications that are built on the API, not the actual Salesforce app that you buy when you buy Salesforce services. It's the trend is I think set.

So I, I summarize that here and that is, you know, banking, your company's core competency into an open API is an economic comparative. If you don't have an API, you need to be engaged in either generating it or enabling it. I'll talk. What I mean by enabling, or you're not in the game.

It's, it's, it's an imperative that you do this. And of course that's why we're making this presentation. So let's go over a little bit. The state of things we're clear that integrating API mashups into an organization's workflow would be the next common practice of those three Detroit that I started with, of cloud mobile and social computing.

It's, it's not, gee, this is interesting. It's it's happening right now. And if you're not involved with this, then you're missing the boat. You need to get engaged. And all of this of course will just create more emphasis on the importance of identity, identity management and all the elements that, that kapa Cole has spent its lifetime studying and understanding for it organizations. So just to understand this a little bit, I'm gonna just walk quickly over the evolution of the API and how things have worked.

Because, because I think that looking how things worked in the past really helps to understand why things are like they are now, why this is happening in this way and why the trends are happening the way they are. The first APIs on the PC side started in operating systems and were only local. And that changed when we started doing networking APIs, Nobel, who I'm also a co-founder at Noel was really instrumental in starting the trend of understanding how operating systems could do networking APIs. Following that.

I think the biggest thing that, that, that came up after that was something called Corvo stands for common object request. Broker Of course, I, I think this whole initiative is dead, but much of the language that we use right now about APIs was generated by the people who were thinking about what a remote procedure call would look like across the internet, across a network. They didn't call it the internet then.

And, and it was very rigid and very complicated and very hard to do. And I think way over ambitious on what they wanted to accomplish so much so that it throttled its ability to, to even be used a much simpler thing ensued as the internet became popular. And it was XML RPC, again, a remote procedure called thinking though. So with remote procedure calls, things are tightly coupled and, and have early binding. So I know these are programming terms may not mean so much.

I'll try to make them so a little later, but it's important to, again, to understand this, this history next, after that came the emergence of the, of soap, which stands for simple object access protocol or something, I can't even remember what it stands for, but, and it, it was very important and it was kind of the, the successor to XML RRP C and for a long time, me and many others thought that it was gonna be soap was the gonna be the popular architecture. But the one I don't have listed here, which is the next one is a restful API architecture.

And it's very clear that, that this architecture, which, which is based on your eyes has Finally created a API mechanism and encoding and procedure, which matches what's happening on happening on the internet. And the amount of growth that we're watching with APIs is based on the fact that rest is emerging.

And, and the number of, of where is the one I'm looking for now, the number of applications being built based on the rest protocol is just blowing away everything up. So now I want talk a little bit about the nuts and bolts of rests and the advent of OA. Now OA stands for open authentication And how this happened was a group of engineers got together to talk about how they could exchange authentication easily without having to, to change exchange names and passwords, but rather use tokens.

And they built this simple system that would allow you to do both a one, a two-legged and three-legged authorization. I'll explain what those are in a second. And it started to get a little bit of traction, but let me tell you what really caused it to happen was a common practice in Twitter was for a new company to come up with service and, and use Twitter to allow you to log in and, and access their service.

So these guys got together and said, what we're gonna do then is go let people log in with their Twitter name and password to our, to our phone service, collect a bunch of names and passwords from Twitter, and then go sell 'em on the open market. So overnight the people at Twitter got this panic of everybody had to go change their password immediately because they'd just been scammed by some phony service and the, the interest in OAuth overnight changed.

So, so now when you are, let's say you're an application, you provide a service and you want to allow the registered reg potential user of that service to register with their Twitter ID. They use a three-legged authorization and three-legged author authorization is between Twitter. The person provided the service and the person trying to register for the service. Those are the three elements. And now if you already have a Twitter account, you can exchange tokens only, not, not your actual name and password. And then of course, register and get an account.

A two-legged authorization is where a developer for a service, Facebook, Twitter, whatever kind of service I'm I'm. I know I just keep mentioning the social one, but it's not just them, but although they're the ones driving it, a two-legged authorization can occur so that a developer can be given keys and tokens and have access to the service without using names and passwords. And so they can hide their code or hide the details of what gives them that access without exposing important information.

Now, the reason I bring those up is not only because the support trend, but because as you provide an open API for your core confidence, you need to be using these technologies. So, you know, I'm gonna mention and bring up and tell you how they work, cuz you, the more you know about 'em, the more you'll be able to make sure you get it right. So because of O OS, which uses keys and tokens, that brings up the fact that if you're gonna provide an API, that means you've gotta be managing these two and three legged tokens and keys.

You need to be able to generate them, update them, reissue it, them reissue them, audit them. And if somebody's abusing it, you need to be able to replicate revoke them. So this is a set of management features that it professionals probably haven't spent a whole lot of time doing, nor do they have the infrastructure or software or expertise to do that. And so that I'll explain how, what your choices are in, in doing that in a, in a second year. The other element that's really important is the format of the data in restful has, has also changed and it's changed to Jason.

So I'm gonna show you the next slide first and, and, and then come back to the, the slide there. But I, I like many others thought that XML was gonna be the format in which data was gonna be presented. It turns out that XML is top heavy, complicated, and difficult to use to represent data.

It's, it's a document formatting, encoding mechanism, not really a good data representational and coding mechanism. So JS O JS O stands for J O N stands for Java script object notation.

So, and two outta three is not bad. It's not Java script and it's not object oriented, but it is notation.

So, but that's what it stands for. That's what we're stuck with. So we'll just keep using it.

So, so the elements of J O that you wanna know about is that it's based ons. That's really good, but the thing that's changed is that it's not just client server, it's, it's a new bidirectional API mechanism that goes back and forth between a client server mechanism between the two elements, communicating with each other. And since the, the, the thesis of this presentation is more about the imperative, providing an API. I'm not gonna spend a lot of time talking about the programming practices, but it's good to be aware of those.

The other elements of JS O that you want to know about is JS O path. So what JS O path is, is a query mechanism to JS O that's a, that's a basic equivalent to XL path or X for JSUN. And of course, you ought to know a little bit about painting and schema.

If, if you are at all involved in making sure that the way your core competence is being exposed to developers in your constituents, that, that this is done correctly. A couple other things that I want to cover that is relevant to this, the, this API economy imperative are the practices of having things loosely, coupled, and late binding and something called web hooks and the invented web. So let me go over each one of those loosely couple sickly means that, that these elements don't are independent of each other.

And I don't have to have the what's you normally call the marshaling of, of all the elements of an API interaction to occur. I can keep them separate from each other and loosely interacting instead of tightly interacting, like binding again as a programming term, but it just has to do with the fact that, that it makes lets me deal more in real time with what's happening instead of having to have it all up in advance before internet and interaction between a program and a data element can occur.

Now, a really big trend that is happening significant is something called web hooks. Again, this is so oriented towards programmers. I don't wanna try to spend too much describing it other than say that it's a mechanism to do callbacks between the API and the program so that they can interact with each other. And the invented web is, is the new mechanism and trying to deal with what people are calling the contextual web so that the internet of things can correctly interact with each other. They need to use an invented architecture. So you can go to, to invented web org again at the tomorrow.

When I, we present this, I'll have all the links to web hooks, to a late binding conversation to loosely couple than the invented web. So you can read more about that. So obviously since this is complicated and becoming an imperative and very important, a whole cottage industry has Sprung up to help it professionals and organizations deal with these matters. And I know there's probably more than the fact that I've listed here, but these are the most prominent ones. And they're listed alphabetically. All of them have different approaches and benefits. I like all of them.

I wouldn't hesitate in using any one of these in helping you. And of course, what they're gonna help you do is dealing with all these issues, governing access to any usage of the APIs, metering, securing the APIs against attack, implementing other technologies and scaling.

I mean, just imagine if access to your core competence starts to go into, through the roof, like some of these other companies and you you're in the billionaire club and you got a billion hits a month. What are you gonna do with that? So these guys can help you try and figure out and manage that in a way that isn't gonna over tax your its organization and your company.

Again, I'm just gonna go over the, the technologies and practices that you, that someone in your organization is gonna have to pay attention to. As they think about exposing core competence through APIs, OAuth key and token management, loosely, couple of architecture, lead binding web hooks, the offended web. And of course, Jason and Jason on path as the encoding mechanism, and then the query language for accessing that data. So I'm almost done. So there's a couple other issues that are important to just talk about touch on here, relatively opening API economy.

There's a bigger picture about how this fits in with the consumerization of it. And what I mean by consumerization of it is that that lately we started to see that people have equipment that is good as, or better than, than they have at work because of the things, the rate at which technology is growing and the, and the features that are being put into mobile devices and routers and servers that people have at their homes and going to work and bringing that technology with them. And that's, that's really causing the consumerization of it to consider how all this fits in.

And there are some documents that Ricco is publishing that help understand that with and, and be thinking about the layers of orchestration and how you're gonna deal with how theses it services are breaking out and including the APIs. Now, the other side of API publishing is the consumption of APIs. In other words, how does your organization start changing?

Its, it, it, it policies to actually use the benefits of the API economy as it emerges, and we'll be providing another document and probably another webinar that talks about the other side of that coin. And of course, with all this, there's, there's a lot of issues of terms of service and, and the legal issues of doing mashups and as accessing the exposed data of companies and, and all this hasn't been resolved. And that's one of the jobs of company or Cola is to, to watch this and make sure that we communicate clearly about what is happening in that, in that area and keeping you informed.

So in summary, I'm gonna state again, that banking your company's core competency into an open API is in an economic imperative. It's something you need to be engaged in and be thinking about. And where of now, if you want to be participating in this, this revolutionary activity that's happening in it services. It it's not, I don't think you have a choice.

It's, it's something that you gotta do. That's why I call it prepared. Okay. So that's all I had. Are there some questions? So the question set up is one of two ways you can raise your hand and then York will unmute you so that you can ask the question or you can type it in and then I can see it and just field it that way. So we have one raised hand from you.

My Mascar, I will unmute him. Maybe you may introduce yourself for a moment. Hello? Who was it again, York. You ma Makari. I think he doesn't hear us. He dialed in by phones or maybe has a connection problem. There are no more raise standard at the moment. Maybe some questions. Yeah. One question I would have Craig, what if you, if you look into the near future, say the next two years, what will be the main impact? How will the picture change compared to what we have today?

Well, what's what, there, there are two really interesting things happening. I think the main thing is that if you expose your core confidence, what what's gonna happen is the ability for other services to emerge that Mer, that mash up what you do well with, what other people do well, and have it be presented to your employees and your customers and your partners as a way to streamline and change your business in real time to deal with what's happening in the marketplace is going to go through the roof.

The ability to adapt and deal with market relationship technology changes is gonna get easier, better and more complicated. Yeah. Another question I would have is don't you see that this kind, this kind of API economy is a risk for privacy or the other way around that privacy might eventually reduce the impact of the API economy, The desire for privacy. So you meant, Yeah, Yeah. Yes. And this is why I think the understanding, the practices of authentication and access and the mechanisms that, that help control and manage that is really important.

And I just got a, a message on innocent message from James Paal who's can't raise his hand and he wanted to bring up skim and what it means over social evented web interaction, GE excuse me, all that's gonna do of course, is provide more access and also managed access to more APIs and services. And that, and that's, that's what we're after here.

It's, it's just an element of this overall API economy discussion. Okay. So we have one question over here will the standard form of authorization between two APIs that need to talk to each other, for example, a book publisher or a book distributor be open off or will open off or only be used for consumer facing authorization. Oof is not a consumer only thing at all.

Again, I think the two-legged oof dance is where applications can authenticate and get access to data. That's not, that has no ceremony to it. The only ceremony is when the keys get issued to the developers so that they can then have authorized access.

And, and that can be done through, you know, myriad of mechanisms, email, direct communication, or whatever you want to do, whatever mechanism you end up using to manage the keys and tokens. So it's definitely not a consumer. Oof is not only a consumer thing. Okay. Maybe one question related to that I have here, will people have APIs, for example, will there be an API for personal data sharing?

Ah, absolutely. It will be restful or will be the authentication mechanism, both two-legged and three-legged yeah. I mean the, the, the restful API phenomena is not limited. It goes across all boundaries of data, including personal data, corporations, mashups all, all the organizations that I've identified. Yeah. Thank you. Another question on we have here now is how can a large enterprise say a big bank, for example, determine its core comp competency would, what should it expose to the world?

Hmm, that's a really good question. And I think it has to go organization by organization and that what you really want to do. I think rather than just take a stab at O answering that in general is engage with one of the companies that identified or, or one that has that similar type of business, where they help you walk through and, and identify what your core competency is and where the value of what you can expose will bring to your customers and to your partners and to your own internal organization. Oftentimes larger organizations have different groups that don't even talk to each other.

And this is going to enable that, that let's groups that are off doing some other project have access to what that group's core competency is. So it's it, isn't an easy answer, but it is easy to think about that. I need to be engaged with the right companies to help you determine what those things will be. So I'm sure that as we move forward with doing this, that we'll add some of that thinking into the company, call advisory services and help companies figure out what their core competency is.

Yeah, Yeah. Now the same Oscar is stating that this notion of a core comp competency seems to resonate with small companies, not so well with big ones. We have a comment on that. Sure.

I'm I, I think it does resonate with big companies, but it, but often as I'm pointing out a big company is an amalgamation of a lot of little companies. It isn't there oftentimes isn't just one overarching core competency for a large organization, like different groups within that organization have their specialty, their core competency work. That's part of that big organization.

So, so perhaps I, I, I would say that there probably is for a large organization, any single core competency, but more likely how this is going to play out is the way the, the divisions or groups, or even departments in the, those organizations, what they do and provide for the company and how they want to expose that both to each other and to their customers and their partners. Hmm. Does that make sense? I think that make does make sense. At least I didn't get another. Yes. I got the message from the user asked this question that it makes sense to him. Good. One more question I have here.

How does the company discover the APIs that are being published out there that are most relevant to it doing business? For example, the ones it should be designing its own APIs to have a dialogue with.

So, you know, the discovery question, Well, there's two resources that I would talk to. One is this program@we.com. I think those guys do a really good job of tracking a certain type of API and customer. It's a really good place to start.

Clearly, all APIs are not gonna be published there because there's gonna be APIs that, that companies have that, that they don't wanna make public. They just wanna be having those discussions with their partners or customers directly. Those of course you need to do through the channels that you have with your partners and, and customers. But the other are those five companies that I pointed out when I, when I talked to the CEO three scale, he made and I shared this document with him.

He made it really clear that he understood that he knows that there are thousands of more APIs coming available than the ones the guys have program of a web track. So, you know, I'm talking about 4,500 published APIs. Those are just the ones that group knows about.

So, so you wanna be in involved with either one or more of the five groups that I talked about. Let me see if I can find that list again. Okay. Yeah. Thank you very much. We have a few more questions here, but I think they would exceed the timeframe we have. Right. So I propose that we closest this session now and we'll answer the remaining questions directly per email. Maybe one last one I just got in, which is a very nice one. What is the most common method of monetizing a company's API? Is it charging by connection by volume by type of data access? Are there best practices for that?

Do we have information on this? Yeah.

The, the biggest conversation I have about that is when I talk with the guys at aji, clearly they're not the only ones that do that. And again, it completely depends on the company's business oftentimes, and you have a spectrum. So on one side of the spectrum, you have where you wanna charge per what we'll call a concluded access to data through the API, and that you've monetized the API to be able to do that.

And the other act end of the spectrum is that you don't wanna charge anything that access to the API is merely creating more communication between your partners and customers and your core confidence. And so you're not.

So, so let's take, for example, Netflix, Netflix doesn't charge anything for the API access. The API is the free part and what, what they charge for is when you start downloading the movie through that API. And the other end of that of course is say Amazon or best buy where you can use.

Let's see, they don't charge for the API. They just charge once again, the API's free and they can, they can make their money off the conclusion. Yeah. They basically run their business through the API.

Well, as the, you know, 50% of Salesforce dot com's businesses through the API, again, they don't charge anything for access to the API itself, but, but the service that the API exposes. So I think there's a whole gambit, a, a spectrum of mechanisms from which to monetize the core competence that you expose. And it depends on the nature of that core confidence and the, and the intent of your business. Where do you want to focus on making money?

Is it, is it in the communication and the use of the API itself or the services and products that, that the API enables? So, you know, there isn't one answer.

It's, it's a spectrum of answers. Yeah. So thank you very much.

Again, Craig, thank you to everybody who joined us in this great webinar it'll be available for, if you, if you wanna listen to it again, or if you want to tell it, some of your colleagues, it will be available for streaming or downloads as from tomorrow. And also you will receive the research note on this topic from, from UR by email sometime tomorrow. Most probably thank you very much for listening And my email's on the presentation and you can always Send me if you wanna get in touch with this Craig directly. No problem at all.

So have an nice afternoon or day and see you soon for another copy. Call webinar. Bye bye.