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

Hello once again, it’s Kin Lane, API Evangelist. I’m here for one of my API Evangelist conversations where I talk to folks who are doing interesting things with APIs. So let’s dive right in and see who I have with us today. Hello there, who are you?

Hi Kin, my name is Daniel Kocot, pleasure to meet you.

Daniel, what’s your role?

I’m the head of API consultancy for Codecentric in Germany, so doing stuff with customers in regards to APIs.

So what’s your background, what brings you to the world of APIs?

Yeah, actually I’m a native backend developer, did a lot of stuff in the past, building services, building APIs, then I got into stuff on the software life cycle management, doing a lot of Atlassian stuff. That brought me to Codecentric, doing things around software life cycle development, but that was actually not the case with the Atlassian software, so everybody wanted to integrate it. And that was the final thing, because I did it earlier in the past, doing integration stuff all the time, but at that time it was really putting things into context, where normally Atlassian has no plugins available or something like that, building integrations for customers directly, and that was actually the starting point. I liked it at all, all the Atlassian, all the good Atlassian stuff running on prem, not the things anymore. So I’m quite off with the whole topic, because at some level, when you know the whole data model of the Atlassian software, which is quite enormous when you see it on paper printed on a really big paper sheet, and you know what is actually happening there, and you know what customers are doing with it in their context, it’s quite hard, and it needed integration all over the time, to bring people to the right spot to make it actually do the right things there. So that was actually one of the starting points. And then I went into consulting with MuleSoft at Codecentric, which was not one of my favorite things in the end, because when you have a customer who bought a product and is going deeply with the product without understanding what actually APIs and integration stuff really means, or what is the whole intent of having a software suite like MuleSoft available, that’s not the real point. So I switched really into the topic, into the scene, and that was a starting point, so around 2017, 2019, that was the real starting point. And it hit me when I was in the US in 2019 at, I think the first or the second Kong Summit, and that was the final part that really hit me hard and said, okay, this is what you want to do for a long time now. Now being in the field for nearly six, seven years with one topic, which is really a good thing to do, and really seeing stuff from the past now happening in reality, it’s really cool what’s happening.

So with APIs, there’s a lot going on in operations and software development, but why do APIs matter, why do APIs elevate to something that you would focus on like this in the end?

For me, everybody’s talking about digital products all the time, so for me an API is a real digital product. I can really use it, I can really make other things possible, drive innovation around the whole thing. So this is for me the starting point. And to be honest, I don’t really like to talk about APIs, because here in Germany they’re very mean, annotated, so when everybody speaks here about APIs it’s always REST, there is nothing more. So we are really switching into more talking about interfaces, to get into the old thing and say, okay, it’s an interface, forget about the term API, because when you say API you mean maybe something that’s not really state of the art anymore.

Yeah.

When we talk here with customers it’s always, yeah, want to do REST APIs because somebody told us that’s the thing to do. And, yeah, what are the use cases, what do you want to do? So there’s still a lot of misunderstanding here.

Yeah, I’m starting to see interface used a lot in standards and government policy and regulation rather than APIs, because it’s a more generalized term, so I agree with that. But one of the things that kind of brought us together here is specifications. There’s a couple specifications that kind of guide the space and get us on the same page, at least from the technical details, and the first one is OpenAPI. So do you use OpenAPI and what are your thoughts?

Yeah, we use, with the customers we do projects around, it’s really about OpenAPI, when we have request-reply APIs or interfaces that need to be available, it’s always that we really think about in the context of OpenAPI. So we do a lot of stuff at the moment with SAP customers, so the developers are doing ABAP and very related stuff to SAP, so they don’t really know the new stuff in software development. So it’s really on them to learn how to write an OpenAPI specification and bring it into the run, which is sometimes hard, because when I say that, for me it’s a text document, so there is no real purpose, I need a lot of software running in parallel to get this YAML file, which is still a text file actually, into action and see what is really happening there. And it is sometimes hard, and that’s why I’m switching more into a direction looking at these things from a programmatic side, so using something like, which is coming up, TypeSpec from Microsoft, to really bring more, because this is my background, the developer side, into it, and say okay, I want to program, I want to use stuff I know from my days as a developer to reuse things and not hoping that a reference is working, because I just set the reference tag and when it’s not working I get in trouble, because I have to do things on my own, or find stuff, or I’m totally heavily relying on having operation pipelines available and everything else in the context so that the things are running smoothly there.

So OpenAPI is often known for, first and foremost I would say documentation, second, as kind of this design-first methodology that’s risen. But what you speak of, would you say that TypeSpec speaks more towards the way developers think and what developers need to build and produce and consume APIs, or is it more about automation and what’s needed there?

In the end it’s about learning something to bring it into automation, because coming from the software development life cycle I’m totally focused on automating the things. So that was one of the first things I did in the API world, when it came up that somebody talked about API operations, that really hit me, saying okay, I want to automate the stuff, not to do things on my own or anybody has to do it on his own machine. So it was really coming into the topic of this continuous integration, continuous delivery, and that’s where I also think there is the need of really having something running like TypeSpec, so maybe have a description more natural when you speak to stakeholders and anything in between there, in persons, and then have the possibility to use TypeSpec to do things in a more programmatic style, and then in a result there will be the OpenAPI definition, the final document, to make clear, okay, we speak the same language, we can test this OpenAPI document, but in between there is some kind of automation actually available.

So they’re related, I mean I spent the last five years in the Postman world, and OpenAPI and Postman collections are very related, but collections are a runtime kind of testing artifact. So it sounds like TypeSpec is in a similar vein but it’s pure automation.

For me, or for my understanding, it’s more in that direction, that you really can bundle things together or build spec-first description of specifications in that way and then really move in the end to say, okay, I want to have an OpenAPI definition, here it is, it’s clear because we have the guidelines, and the guidelines are mapped by TypeSpec, so that you don’t really need some kind of linting in between maybe. And I think, what I see, everything is still in the beginning, so we are in an early stage, so anybody has to find a way to really get it done by all working for them, the adoption rate and all the stuff available. So for me it’s a little tool where we will see in maybe one year, two years where it will actually go, because a lot of people, in my opinion, reinvent now OpenAPI, that didn’t really have a look, because they all generated the stuff over the years, that’s how I learned OpenAPI. There were always generators when I built REST APIs in the past, so it was always generated, nobody had a real look at the things, and then linters came up. A lot of colleagues of us at Codecentric came down and said, oh, we have a mismatch, the generated file is not really working with somebody had in guidelines, or have the Spectral rules, that is not really working together. And that may make somehow people have a click and say, okay, oh, maybe it’s better to do design first and not really rely on the generators, but in the past everybody was using generators.

Yeah.

Now for me it’s really, oh, we have OpenAPI. When you look at the history, so it was 2015, and nobody was really interested in having this specification, everybody said okay, it’s there, yeah, it should look like this, but, yeah, it works somehow. Now everybody’s really focusing on getting it into work. And we had the conversation on LinkedIn actually with Fabrizio, coming from this more technical writer world, which is for me totally different than the people I normally work with, because companies in Germany are not so into the topic of technical writers, it’s rising at the moment but it’s not really that everybody is looking for a person who is really focusing on the technical writing stuff. So having other issues and other ideas how to evolve actually in the field of OpenAPIs or specification descriptions, whatever.

Yeah, and it’s that difference that I think exists, is why, what is OpenAPI making work, is it making the documentation work, is it making code gen work, is it making automation and integration work, I think there’s some significant differences between those intents.

Yeah.

So what tooling, what do you want to get out there as far as, what do you think needs to make TypeSpec rise that next stage? Is it tooling, is it awareness, education?

In the end it’s awareness, thinking about what way I would like to do. Because what I still hear even from colleagues in our company is, we go API first, that’s for us on the consulting side a full stop, where we say, okay, nobody will go API first, maybe the leader of a company, the CEO, can say we go API first, but what you want to do is design first, maybe we get this right. And if we have a clear understanding of what is really needed, so that’s what we see at companies, a glossary, what is an API, what is an interface, and so on and so on, and then really find tooling which is actually really needed for the beginning side. So if I’m more a company having generators, coming more from the code-first side, maybe it’s easier to adapt into the direction of TypeSpec, because it’s a programming language and somehow backed by TypeScript and anything like that. So it really depends where you’re coming from in the end. And this is what people are still looking for, this blueprint, I want to start with APIs, what is the first step, and the answer for us is always, where are you coming from, what is the background, how is the team working now, would they go the way you propose them to do? So it’s really in the end about the people, the adoption rate and a lot of things, and not to say, oh yeah, this is the best tooling. There are so many things to really think about, and in the end when you look at the tool side there are so many tools available, and even we on the consultancy side are not really aware of every tooling in the market.

Yeah, I get, I think, three LinkedIn invitations to calls to have a look at the tooling, I get emails, oh, there’s a new version out, always thinking, our work with customers, their pipelines, everything is running, why should I change this?

Yeah, yeah, and in the end it’s good when you look at something like having Spectral running and then see the coming up of Vacuum, and you see the actually trademarks why you should maybe use Vacuum, and you can stay with the Spectral rule sets, then it’s quite easy to say, okay, we do a switch because we need a faster linter or anything like that. But in the end there are so many tools available in the market right now.

Yeah, it’s tough, I’ve been watching it for 15 years and it’s hard to keep up and understand. Well, that’s all the time we have today, but I’ve got a list here, because you’re going to come back after you do the rounds of conferences and whatnot, because I want to talk about the difference between API first, design first, code first, I want to talk more about API federation versus a centralized approach. So I’ve got a list of things that I want to get you back for, but this really helped on TypeSpec and understanding the difference. I appreciate you coming by and chatting with me.

Was a pleasure joining you here, and see you soon.

All right, thanks Daniel. All right, well I’m still getting up to speed on TypeSpec and understanding where it fits into the overall ecosystem, so that was super helpful. I definitely love this new podcast format, because I can have Daniel back in a couple weeks or a month or two and we’ll talk more about design first, code first, and then I want to hear thoughts on API federation versus centralization. All right, well thanks everyone, until next time.