Who are you?

I can. My name is Daniel.

What is your role?

I'm being a head of API consultancy for CodeCentric in Germany. So doing stuff with customers in regards of APIs.

What is your background?

I actually, um, I'm a native back end developer. Did a lot of stuff in, uh, in, in the past, in, in, in the backend building services, building APIs. Then, um, I get into stuff on the software lifecycle management, doing a lot of Atlassian stuff. That brought me to code centric doing actually things around software lifecycle development. But that was actually not the case with, with the Atlassian software. So everybody wanted, wanted to integrate it. And that was the final thing because I did it earlier in the past doing, doing integration, no stuff all the time. But at that time it was really putting things into contexts where normally Atlassian has no plugins available or something like that, building integrations for customers directly. And that was actually the starting point. All the good Atlassian stuff running on prem, not the things in the cloud anymore. So I'm quite actually 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. Actually in their context, it's quite hard. It needed integration all over the time and, and bring people to the, to the right spot to, to make it actually doing the right things there. So that was, that was actually one of the starting points. And then I went into consultancy with MuleSoft at CodeCentric, which was not one of my favorite things in the, in, in the end, because. When you have a customer who brought a product and is going deeply with the product without understanding what actually APIs and integrational stuff really means, or what is the whole intent of, of having a software suite, like, like, like Nukesoft available, that that's not, not a real point. So I switched really into the, into the topic, into the scene. And that, that was a starting point. So around 2017, 2019. That was the real starting point. And it hit me when I was in the U S in 2019 at the first, I think, 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, and now being in the field for nearly six, seven years with, with one topic, which is really a good thing to do and re and really seeing stuff from the past now happening in, in, in reality.

Why do APIs matter?

In the, in the end, from, 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, 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 every, when everybody speaks here about APIs, it's always rest. So there's nothing more. So we are really switching into more talking about interfaces to, to get into the old thing and say, okay, it's an interface. Forget about the term API, because when, when you say API, you mean maybe something that's, that's not really state of the art anymore. Yeah. Because when we, when we talk here with customers, it's always, yeah, I want to do REST APIs because somebody told us that's the thing to do. You think, ah, yeah, what are the use cases? What do you want to do? So there, there's still a lot of misunderstanding here. And

Do you use OpenAPI?

Yeah, we, we use with the, with the customers we do projects around. It's, it's really about open API 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 open API. So we do a lot of stuff at the moment with, 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 open API 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 in, into a direction, looking at These things from a more programmatically side. So using something like, which is coming up type spec from Microsoft to, to, to really bring more, because this is my, my, my background, the developer side into it and say, okay, I want to program. I want to use stuff I know from, from my days as a developer to, to reuse things and not hoping that a reference is working because I just set a reference tag. And when it's not working, I get in trouble because. I had 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.

Is TypeSpec used for automation?

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

Is TypeSpec used with OpenAPI?

for, for, for me, or for my understanding, it's, it's more in that direction that you really can bundle things together or build specific first description of specifications in that way. And then really move in the end to say, okay, I want to have an open API definition. Here it is. It's it's, it's clearly because we have the guidelines and the guidelines are mapped by type spec so that you, that you don't really need some kind of linting in between maybe. And I think what I see it, it's. Everything is still in the beginning. So we are in the early stage. So any, anybody has to find a way to, to really get it done by all working for them, actually. So the adaption rate and, and all the stuff available. So it's, it's. 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, rethink now OpenAPI. They didn't really have a look because they all generated the stuff over the years. That's how I learned OpenAPI. So there were always generators when, when I built rest APIs in, in, in the past. So it was always generated. Nobody had a really real look at the things. And then Linter came up. A lot of colleagues of of us and at Centra came down and said, oh, we have a mismatch. The generated file is not really working with somebody had in guidelines or have a, the spectral route that is not really working together. And that, that may make somehow people have a click and say, okay, well, maybe it's better to do design first and not really rely on, on the generators. But in the past, everybody was using generators. Yeah. Yeah. And now for me, it's, it's, it's really. Oh, we have open API. And when you look at the history, so it was 2015 and nobody was really interested in having the specification. Everybody said, okay, it's there. Yeah. It should look like this, but, uh, yeah, it works somehow. Yeah. And now everybody's focusing of getting it into work. And, uh, we had, we had that conversation on, on LinkedIn actually with Fabrizio coming from, um, this more technical writer world, which is for me, totally different. Then 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 technical writing. Open APIs or specification descriptions, whatever.

What is needed to make TypeSpec successful?

In the end, it's awareness, thinking about what way I would like to do, because what, what we I still hear even from colleagues, uh, in our company is we going API first. That's for, for us on the, on the consulting side, it's a full stop. We say, okay, nobody will go API first. Maybe. The, 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, if we have a clear understanding what, what is really needed, so that 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 fine tooling, which is, is actually really needed. For, for the beginning side. So if I'm more of a company working now having generators, so coming off from the code first side, maybe it's easier to adapt into, into the direction of type spec because it's. It's a programming language and somehow backed by, by, by TypeScript or anything like that. So it really depends where, where you coming from in the end. So there's, and this is what, 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 there go the way you propose them to do? So it's, it's really, it's, in the end, it's about the people, the, the adoption rate and, and a lot of things actually, not to say, Oh yeah, this is the best tooling. There are so many things to, to, to really think about. And in the end, when you, when you look at the tool side. There are so many tools available and even we on the consult, a consultancy site, I'm not really aware of every tooling in the market. I get, I get, I think free LinkedIn invitations to calls to, to, to have a look at the tooling I get emails. Oh, there's a new version out. And you're always thinking I was, I'll work with customers, their pipelines, everything is running. Why should I change this? It's in the end, it's good when, when you look at something like having spectral running and then see the upcoming of a vacuum and you see the, the, the actually, um, 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.