API Evangelist Conversation with Daniel Kocot, Head of API Consulting at codecentric AG

Uh, hi, I’m Daniel Kocot. So I was with you some time ago, so I’m back again.

It’s actually very difficult because when we work with customers, we normally have, they’re in the position of thinking about partner APIs or anything like that. So it’s naturally from the beginning, more talking about internal for, but for me, that was. Still from the beginning, very hard to handle [00:02:00] because what is internal? Yeah, when we look on the organizational side, is internal a department or a special structure or whatever actually existing there? Or is it really a technical thing? So then it’s just about, because this is what we mostly talk with customers about. Yeah, we’re having stuff internally presented and then there’s going out somewhere. With some partners or some consumers we have outside of our organization and then with just external but sometimes When you even think about onboarding people, I think it’s quite hard just to say it’s an internal api, whatever that means So it could be internal for for this perspective of the department or is it? Shifting boundaries there and and going towards another department so on and so on and that’s why we always have always have these Oh, no discussions being in Germany. It’s always, it’s [00:03:00] mine. I have to do it. It’s not yours. You’re not allowed to do this. You have to ask me. So it’s, it’s, it’s very, very hard to, to, to really, really resonate on that because you’re always getting into the discussion of who is the owner of somebody or something.

Daniel Kocot: being in bigger [00:04:00] organizations. Not really, because what we see is still a lot of centralized API management solutions, not really the thing of say, okay, we talk about the federated stuff that this is, this is actually coming up now to say, okay, we have a specific gateway for specific purpose, but, but in the end, it’s somehow centralized. So you have many platforms, but they are all looking from a centralized perspective, so everybody can push something there. And it’s actually not clear on the other side. Oh, do I leave a boundary? Do I leave something? Is there is there a real as you have have it there a real technical boundary actually there? It’s not really clear because it’s still a central platform so everybody can use it inside the company. Maybe It can be seen on a on a Catalog that is a specific department meant by that or, or special product family or who, whatever we call it actually. But, but this is what [00:05:00] we, what we normally have when I look at projects we do, we do out there actually. So it’s always internal.

it’s it’s normally the old stuff still running and it’s it’s easier because I have a central team. I have this Central platform still available. So it’s actually something we we we are triggering right now saying okay We we take the ideas from team topologies to to really move Into a different direction saying, okay, it might be good to have a more productizing idea of having an API and then, and really moving that, that into a different position then and say, okay, it’s It’s an API product. I have a specific platform for that and, and really move from that direction. And then it totally fits when, when you talk about having a first party API [00:06:00] and maybe some kind of internal stuff, because in the end. For me, internal is something I don’t want to share with people. Actually, it’s really mine. Maybe it’s something when we go really in the older days, what meant older days? So the mid of the 2010s actually when, when this API led connectivity type of thing was, was the, the thing to, to do actually. So the things MuleSoft brought up saying, okay, you have the system API, you have this process API, and then there might be in some kind of experience level. So in the end, this, this system APIs, this is really the internal stuff. Nobody should see this actually outside of, um, of actually. I, I, um, yeah, actually I produce, this is also what, what I, what I used in the past to bring up the, the gateway idea, really saying, okay, so if I say it, [00:07:00] it’s really a door. So I built up a little legal house for that and had a picture about it saying, okay, it’s the door you have to go through there and then go to, to, to something else that you might not see actually. So it’s, it’s really on that. And so this is, this is the internal, the internal thing for me and now having your idea of the first, the first party API makes it maybe more obvious to people that it’s not about just public and internal. There is something in between, which was not really defined in the past. So this is, this is what, what, what I see the

in, in the end, what we did in the past with, with, um, customer project was really to say, okay, every API has an aspect of public, so really high demand [00:09:00] on security. So even to, to fit it then when zero trust came up. So to really say, okay, it’s, it’s the zero trust thing, every API, it doesn’t matter if it’s internal or public or whatever. Has this high amount of security actually, so to really make clear, we don’t really know because when you just had this public and internal, it was not really clear, will an internal API become public at some level? Yeah, it’s the, it’s the same because we, uh, at CodeCentral, we did a blog post about first one, what we call data interface quadrants to really say, okay, we think about data interfaces. So we have an interface, an API, and it’s somehow bringing data to somebody else. You have sometimes the pattern of this back end for front end type of thing. And a lot of people still think, Oh, I have a back end for front end API. [00:10:00] Nobody will see this. And what we saw in the past was. That there was somehow a back end for front end API available with no real security on it. Because somebody said, okay, it’s just for this internal type of thing. And what I see really going into to resonate with what you brought up with the first party API is maybe that we have more shift that’s still relevant to say, okay, it doesn’t matter what type of API you will provide. And from the beginning on, it should be secure, not saying, okay, it’s back end for front end. It will be only used by our specific, whatever product to use it. It’s clear. It could be used by something else because we, we, we don’t really know what will happen there because just to say, okay, we built this and it will last forever. Yeah. Nice try. But reality always looks, looks different when [00:11:00] somebody is searching for something.

it’s, it’s, it’s really still the same. So a lot of people don’t really, really understand that. There is a need for, for security, for, for being more on, on the point when, when thinking about API is not just to say, ah, yeah, yeah, we, we put them somewhere and, uh, we put an API on a, on a, on a marketplace or put it on a, on a portal and nobody really cares about if this portal can be found from, from the outside actually to, to, to make it visible and, and some things like that, because this is also something I did in the past building portals. Yeah, and you, you really had to make people aware of, please be aware that only the people who should see the portal can see the portal, not [00:13:00] make it open to the world because you didn’t know how to configure the stuff, uh, being an Azure web application or whatever. So it was, it was always fun to, to find out if this thing will be found outside of the company, actually that somebody can find then these API. So you always, as you did, we did tests. So I made, there’s one story, I made a portal actually for one customer, uh, and it should get online before the, the winter holidays. So it was the 23rd or something. So we put it online and the colleague working with me from, from, from the customer said, yeah, it’s fine. It’s working now. It’s online. And I said. We have to really prepare if this is not visible to the outside. So if the configuration somebody did for us is really correct. And he was like, Oh, it’s, it’s, it’s, it’s late. We have [00:14:00] to leave it. It’s it’s, it’s working now. And I said, no, no, no, no. We look, we have a look. Lucky enough as we were, we, we didn’t find anything. So it was not possible to get it, but. If it would be, then somebody over the holidays could really get into the CMR data of, um, the company, actually getting information about orders and anything that was possible to find actually. Because it was open. So it was really clear that there are APIs available. And, um, if somebody has, has then keys to get into the company itself, not, not, not the best part. So it’s, it’s, it’s really, I think it’s the most, most thing to really think about, even if we classify APIs to really say, okay, it really doesn’t matter, it has to be secure all the time. Whatever security means if it has to be zero trust or should be zero trust and then then it should be zero trust [00:15:00] But hopefully it’s secured not by just having a basic or for something like that But there must be a security method in in the company or an organization that that should be used actually overall to really make sure that that nobody gets gets access where where he or she should be

Only when there are directors coming from authorities. So we have this Dora, Dora thing right now, we will see the, the, the feeder thing in, in, in Europe actually coming up, then people will, will have an idea of, oh, I’m allowed to share this, okay, but I have to do this and do that. So it’s, it’s, it’s really then that they are, they need these control things. So we are [00:16:00] again with, with Gregor to say, okay, it’s about control. So it’s, it’s really, somebody is pushing you to do that. But in the end, if nobody is pushing you, you will do things just to have it working and to, to, to hit the project deadline actually in the end. So that, that’s, that, that’s the thing really hitting the project deadline, because what we heard in the past, always from, from people working in companies, if it’s not ready, I would, I will be dead. So this is one of the things, so you do just things and don’t really care about because if nobody sets you under control or gives you the control to do so. You’re just

In the end, we are by one of the, of the interesting topics, governance. So if the organization is setting, setting up a governance setup, that’s not a problem because you just rely on, okay, we have linting there. We do testing there. If the tests and the linting work not properly, your API will not push to somebody else. That’s, that’s the best thing. So this is something we did with customers in the past and it always works well. So if somebody’s came, ah, we don’t need this, uh, this off classification in the open API spec, there is a, there’s a pipeline somewhere that is hitting you then and say, okay, you need this.

that’s actually a really interesting question. I’m a, I’m a big fan. They’re also a federation. So really say, okay, everybody can join the party who is doing stuff there and can bring their own perspective. Because sometimes when you, when you work in really big enterprises, There are lots of aspects you don’t really care about because you don’t know them. So when you look in research and development, there are different rules than looking into procurement or other scenes there. So it’s in, in, in the end, it’s, I think it’s, it’s really on to, to get every people’s mind there and not to say, okay, we are the centralized, uh, center of enablement or excellence or whatever we call it. And we decide what to do. So it’s really this federated approach. I think Gartner brought it also up in the past to really care about what is happening and really switch people or bring people into the position to, to really [00:19:00] care or bring their perspective in.