Jon Scheele (00:00)
We're here at apidays Paris and I'm really pleased to see Erik Wilde again.
You are the ambassador for the OpenAPI initiative track here in Paris, as you were in apidays Singapore in April this year. And I hope in apidays Singapore also in 2025.
Erik Wilde (00:25)
Yeah, it'll be great.
Jon Scheele (00:27)
For people who don't know you, tell us about yourself.
Erik Wilde (00:31)
Okay, thank you. Yeah, so thanks for having me. Hello everybody, my name is Erik Wilde. I work with the Open API Initiative as an ambassador, meaning that I just try to spread the message of standards and their value, how to use them, why they make sense, sometimes also stories of how they were used, how people got value out of them.
So as part of that, one thing that we do is we organize these OpenAPI Initiative tracks, which are mostly at apidays conferences, like here in Paris. Here in Paris, we had a full day. So we have a full day of program where we have a whole bunch of speakers. We had 14, I think, so a very good program. And it's just content around standards, sometimes tooling, sometimes governance, sometimes design issues.
Anything that might be relevant and interesting when it comes to how to use standards, how to use them well, and how to get the most out of them. And I hope to be in Singapore next year for sure. Yes.
Jon Scheele (01:24)
So the OpenAPI specification initiative has been around for some time. It's gone through several evolutions from 2.0 to 3.0. Where are we up to?
Erik Wilde (01:37)
3.1 now. 3.1.1.
Jon Scheele (01:39)
There are also several different innovations that have been incorporated in there. But the whole idea of having a standard is, as Gregor Hohpe was saying in his keynote, is standards actually help you to innovate. So what are the sorts of things that you've seen from the track here in Paris that are really driving the conversation around the innovation of the OpenAPI Specification?
Erik Wilde (02:09)
So this image that Gregor has, this nice double-sided pyramid, where you say on the bottom you have the platform.
And then you have kind of the foundation is infrastructure and foundational services. Then the platform is kind of a little bit in the middle where things should be standardized to a certain level. And then you have this inverse platform on top where you said innovation is actually on top of that, right? And the point is if you find the sweet spot of this one point where people can use certain things over and over again.
Then they can actually start and build really interesting new things on it. The example that Gregor is using, which is really good, is that of the automotive industry, so the car platforms. They have, because they, next year, by the way, which I find really fascinating, next year will be the 100th anniversary of platform engineering for cars. So they started in 1925, it was a long time ago. But it's really interesting, because they are able to build a whole lineup of cars based on very few platforms.
So the innovation is in building up the car and the engineering challenge is in providing a platform that allows you to do that. So you need a couple of platforms for maybe smaller cars and bigger cars and faster cars and slower cars and electric cars and non-electric cars and then you build a whole family of models on top of that.
I think it's a really nice analogy to say if we manage to find this good platform that... our people can build on, then they can go and build cool stuff on it.
And one last thing that Gregor also is saying, which I also find really interesting, is that he's saying that you only have a platform if people build something on top of it that you didn't really count on. So if people build something where you said, I didn't know you can do that with my platform, but you can, and that's nice.
So there are things about the OpenAPI specification that help to standardize things and mean that promotes reuse. I think so if you think about how an organization defines a customer or an account, you can develop a schema for that so that you have consistency across all your APIs.
Jon Scheele (04:17)
But then the innovation part, what are things that you've seen that you had not expected to see in any of the sessions that we had? We should have a very long conversation, not today, but a very long conversation about the standardized customer, right? Because I think that's also kind of a contentious issue. Like is there even one customer model that is the one true model for the whole organization? I would argue in many cases there's not because different departments have very different focuses on customers.
Jon Scheele (04:47)
Certainly if you're a large full service bank and you have a retail division, a private bank, wealth management division and corporate institutional division then your idea of a customer is going to be different.
Erik Wilde (05:01)
But anyway, that was not the point. Sorry. That's something that's dear to my heart. But the other thing is that then how do you build on top of that? And I think the interesting point there really is that if you have services around those things, so you would say, well, we have a team that builds services around customers. So I get information about customers, maybe about their purchase history or whatever it is that you're doing with customers. And I have some other teams that maybe...
build good recommendation systems or they come up with good ideas on how we can provide additional services to these customers. Then maybe they come up with really interesting and new ideas how to combine them and how to build a new app that if that customer walks into a certain location, I use their history and I use the recommendation system to provide something new for them.
And maybe that combination of bits and pieces was not something where I thought, you can actually use those three pieces to combine them for that kind of new offering?
Jon Scheele (05:58)
Well, there are certainly some historical examples of that. for example, the introduction of the iPhone, it brought together a GPS that had been designed in the 1980s, 90s with a mapping service with an application.
That enabled companies like Uber or Grab to help drivers find passengers and passengers to find drivers that probably nobody thought of when they created the GPS system and probably nobody thought of when they created the smartphone, and maybe even nobody that when they created the Google map. But when they published the API for that, it enabled that combination to create a completely new service.
Jon Scheele (06:41)
And because you used that example, it's interesting, right? Now you can go one level up and look at Uber. I mean, Uber had initially at least just the plan basically to kind of replace taxis, so to speak, right? Personal transportation. And I'm guessing that initially they also didn't think of Uber Eats, right? That you can deliver food.
Yeah, but I don't know the story really, but I would assume that maybe somebody realized that, we have all these services of routing, mapping, invoicing, right, so what are other things where we could leverage those transportation services for? And then you still had to build some missing pieces into this, right, it's like okay now we need the offering of a restaurant or whatever else is in addition there in UberEats, but they also could reuse a lot of these parts, right, that were already existing and I think this is exactly the kind of innovation bit where it probably took Uber way less to do Uber Eats than it would have taken somebody else who didn't already have all the machinery in place that Uber had.
So, and this I think is the kind of platform thinking where open API, then if they had these interfaces available, right, as APIs that you can just use to build maybe a proof of concept that you just play around with and see how it works, right? And the more easily you can reuse those services in new scenarios, the more easily then people can just try out things and say, well, maybe that wasn't a good idea or say, that's exciting. We need a little bit more, but we already have a good start. And as technical people, we often think about the components that you can assemble.
Jon Scheele (08:12)
It also plays into market development, new product development, because the marketers will do this little matrix where they look, are we going to move in, create a new product for our existing market, or are we going to take our existing product and move into a new market? this is also enabled by the capabilities that we've already built.
So there is a language, there are examples of how you do this with system components as much as with product and market components.
Erik Wilde (08:49)
And I mean, in the end, think APIs aren't magical. So like you say, whether then a company like Uber, let's say, actively explores new opportunities and actually allows people to do that and see, OK, let's build a POC, see how it works. That's much more of a strategic question of how the company is treating innovation. Are they encouraging experimentation? Do they give people some free room to see what else could we be doing?
That's also a lot of the question of the culture of the company, would say. But before you have that culture, you also need that setup that you can actually afford to do those things. If people always have to start at nothing to build these things, it just becomes very expensive to do that. And if you have a good platform with these open things in there that you can play around with, I think it becomes much more realistic to be able to do that.
Jon Scheele (09:39)
So, looking forward to 2025, what are the things that you've seen over the last few days that you think are really going to carry forward into 2025?
Erik Wilde (09:50)
Many, many things. As you may see, there's a lot of stuff going on here. We had 5,000 people over those three days, so there's a lot of things happening. Just to summarize it from maybe my point of view.
I just see a lot of things that really, I would say, show us that the scaling issue becomes more and more important. You have more and more capabilities within companies. We don't have to explain to anybody anymore what an API is and maybe why it's good to have them.
So now I think the work is much more how do we build them more effectively, how do we make sure that we build them securely, like all the bits and pieces where you say, okay, this API thing really seems to be important, but now we want to become much better at doing that. So I think this whole scaling story and AI plays into it and many other things as well.
For me, the theme that is really carrying all these different individual bits and pieces is just scaling the API practice so that you can build up these platforms that allow you to become a better organization in the end.
Jon Scheele (10:51)
Okay. Well, great. Thanks very much for that summary, Erik. And looking forward to seeing you at apidays Singapore in April 2025.
Erik Wilde (11:02)
Yeah, thanks for having me. Thanks, everybody. And yeah, see you in Singapore.
Thanks.
