API as Business Capabilities with Daniel Luebke

Speaker A: Foreign.

Speaker B: Welcome to the API Governance for Scale podcast. My name is Iken Ngwiwu and I am principal consultant consultant at Ikenna Consulting. I give engineering leaders evidence, independent evidence based independent reviews on their uh, API governance risks and uh, API delivery posture. Today I have Daniel with me, uh, who is the CEO of Digital Solution Architecture. And I'm going to let uh, Daniel introduce himself uh, and tell you all about what he does. So good to see you again, Daniel. I know last time I saw you was at a conference a while ago, but good to see you. So for our listeners, can you just maybe uh, give them a bit intro to kind of who you are and what you do.

Speaker A: Thanks for having me on your podcast, Ikenna. So I'm Daniel Lucca. So my parents decided to give me international first name to compensate for my last name which outside any German speaking country in the world won't pronounce. So. But Daniel is a fine man. It's a great name. I am well, um, a software architect who probably call me a solution architect, software developer. So I'm working and my colleagues, my team is working on projects, digitizing business processes. So usually we need to integrate many systems, we build custom software systems to help companies actually automate the essential business processes. So that's what we're doing, that's what I'm interested in. And um, I'm doing this now for an astonishingly long time. So I'm feeling quite old sometimes. But yeah, so that's I think the very short version.

Speaker B: Good, good. Great to have you on the, on the show, Daniel. The first question I want to ask you is how you've written speak on APIs API design. Um, you have this great book on API design patterns which I've really enjoyed kind reading, going through and referencing and showing others. But tell us a bit of how you, how you go into. Yeah, yeah, I'm gonna m gonna show that very soon. Tell us how you got into APIs, into APIs, the whole thing around API design and got into curating this huge patterns book, you know, pattern book or, or this huge library of patterns on, on API, on API.

Speaker A: Well I think that's a long story going back to 2000, uh, probably 07 or so. So I did my PhD back then what we called Service Oriented Architecture. So back then it was called a service, not an API, but the idea was the same. So essentially from the corporate days where Paradigm was to develop distributed object oriented system, the focus shifted to services so that you don't have objects but you have functions which you call which are always available. And um, after my PhD I went into industry and well there you have integration topics all the time. So it's not as you can say, hey, I'm working in the software industry and I never call them the system. So these days are uh, probably gone except you building your own small little mobile app. But apart from this everything is connected and uh, this means APIs as we call them nowadays is something which you need to do every day essentially. And so you have discussions with other teams running other software systems. And um, my second project actually was a very large scale platform in Switzerland where We integrated around 700 systems throughout Switzerland. So land registries, notaries, banks. Switzerland is famous for its banks when they're quite some m. And this means momentum. Well uh, hell of integrations and hell of interface discussions. And at the time um, Olaf Zimmerman approached me so we knew from he's from similar region as I am and we met at a conference and ah, then we met in Zurich, back again interestingly and he asked me hey, I want to do this book, do you want to join? And at the time I was thinking about doing something similar not with design patterns, uh, but for covering governance and APIs because these were the discussions we had quite, quite often. So how to stay compatible, what time ranges, what changes can be made safely. And so I said to one of yeah, well great, let's do this. Knowing that we would spend like next five, six years together developing these API pattern catalog. Yeah, there was quite a long journey actually and no one would have imagined that at this time. Um, but we went through many projects which we individually did, we went through many open source repositories and we did pattern mining and then the initial pattern versions, had them presented at different conferences and then we thought we are ready. So we had all of these 40 plus patterns reviewed and it was only writing the book and uh, only writing the book. That took another two years in the cycle until it was ready and it got much thicker, much longer than also expected. But it's, it's very interesting to, to have this journey for many reasons. So first of all if you want to write a book then I think it's a great thing. But be uh, prepared that it's more hassle. I mean back then there wasn't chatgpt and so on. So it's all handwritten. Um, and on the other hand it's interesting how you. Well uh, how it's not special anymore. So if you have like four years depending on the same topics it seems like yeah, that's self explanatory. So when this book was released and then people said hey, well it's a great reference and that helps us quite a lot. It was insofar interesting as we were so used to these things that they weren't special anymore. But then people said hey, that's great. And it was quite relieving actually. So that's the story behind the book. And since it has been released I've been speaking quite a lot of contradicts about these design patterns and we did lots of articles. We have now launched a pattern a day where you can get a daily email featuring a pattern just to learn, uh, in small chunks every day. So there's quite some things going around around this book.

Speaker B: Yeah, look uh, Dan, I'll tell you, the book is very handy to me. I actually have it on my desk, you know, very near my um, my, on my bookshelf here. So this is my copy. I hope I'm holding up the right way for, for people who are seeing on this on YouTube. So you know, it's a great reference and I kind of reference it as well. So that's uh, really, really, you know, I find it really, really valuable. I'll follow up just from that on kind of that patterns. You talked about projects where you've worked on APIs across the whole country. You know, integrating different companies, banks and things like that. What do you think are the biggest risks with how organizations kind of Design and deliver APIs based on your experience?

Speaker A: Um, it depends a little bit on the scope of the API. Um, let's start from this project. Obviously there are different risks. So if you see banks are quite conservative, organizations, land registries are even way more conservative. So you have change cycles around um, like measured in years, not weeks, not months, but years. So everything you got wrong, it takes you two years to make the next change and roll this out across hundreds of systems. And that's obviously requires more diligent and less agile way of designing APIs. So if we look at API evolution, these APIs evolve quite slowly and they evolve differently. So the bank side APIs evolve quicker than the land registered APIs. For example, if you are more internal organizations, um, you can go more agile. You still have dependencies and changes heard regardless uh, of what experts say. And also you won't have endless backwards compatibility regardless of what some experts say. But you can iterate quicker, you can learn quicker and I think that's the important thing. There are certain guidelines which you can follow to make good decisions upfront. They're good questions to come to good initial decisions, but you need to have the uh, need to be able to make changes going forward because you will learn about the domain and the world around you is changing and forces you to change. So this mantra, for example, talk about endless backwards compatibility. If you look at online banking today, at least in Europe, in Germany we now pay with euros and we have these international bank account numbers, which is completely different than let's say the online banking in 1999 we had German marks and national bank accounts. So there's no way of having compatible online banking APIs. There's just no way. And especially regulatory things and also security things will force you regardless of your business domain, will force you to make breaking changes. And the ability to adopt those I think is the very important prerequisite to everything you do. And the problem is we like to build stuff and ship stuff initially. So no one cares about how to evolve an API until usually it's too late or they run into the first problem.

Speaker B: Yeah, yeah, absolutely, absolutely. And I think that um, the other thing as well, talking about risks is this thing about the business capabilities of the API. You know, I've heard you talk about how, you know, APIs are there to model business capabilities. But sometimes I find uh, that when people talk about APIs and API design, you know, they start thinking straight about, you know, open API and you know, rest endpoints and things like that. Um, without thinking a lot about the cross cutting business capabilities on the pinning that how do you surface those capabilities, how do you describe them, ah, and then what should their interfaces be? So I mean, you know, I know you talk about this a lot about making sure that APIs reflect business capabilities. Um, how do you think that changes how we design APIs? Especially who should be in, involved in designing APIs and how we design it. It'll be interesting to hear like the project you talked about in Switzerland, across many organizations doing that kind of API design, uh, or should I say integration work at that scale. Who would you say should be involved in an API design process?

Speaker A: I think there are different concerns you need to bring to um, the table to discuss this. So one is obviously you need people from the provider sides who are the ones building or implementing the API. And you need to have uh, client side knowledge. So what do the clients calling you actually want? And that's something very important. So usually you see people, hey, we need to build an API. And um, then the average developer just says okay, we just expose something from our business layer, uh, like these typical crud operations and then we are done. And usually these don't reflect a good business perspective, which is usually the client perspective. And that's I think the important point. So an uh API should not be easy to develop or it should be easy to consume, to use, because hopefully there are many more clients using an API than you are the one developing. If you're good, you have like 10 to 1 or uh, 20 to 1 ratio. And if you're very good like a big corporation, then it's millions to one. So to get this client perspective, you need to understand what the client's use case, the business case, is actually to call you. And once you understand this, it's much easier to design an API which works and which has good developer experience. That's another buzzword. But I think all these buzzwords and many quality characteristics come down to understanding the use case and the context in which your API is actually called. If you don't understand this or don't have the knowledge, you doing some are you making assumptions which might be, if you're lucky, might be true, but usually many of them will fail over the time. So for example, one common thing which I encounter is you get these crud operations and what is it? It's get by id, get product, get order, get customer, get whatever, buy ID and update one customer, change one customer, delete one customer. And many use cases, for example, involve a set of domain objects with these naive APIs or accidental APIs, which I like to call them, you get just a simple version and you don't understand actually what the current use case is. So we had another project, but still we had a very simple API built by uh, a team like 10 years ago. And you can argue about technology, it's a message MQ thing. And then people will say, hey, that's a better API because it's MQ and Not REST or GraphQL or ERPC or whatever you have. But that's not the issue. Thing is this API is bad because our use case is transferring 400,000 items and this API offers single operations. So it's just impossible to do a loop over 400,000 items plus regardless of whether it's MQ or rest. So these technical decisions come and go, or technical standards come and go. So I have my great hair here. So I know karma, I know soap, I have seen the headlines. Xml, uh, will save the world. Kava, uh, will save the world. Rest will save the world, whatever it is. But interestingly, the design problems have remained the same. Mhm. So whether it's now JSON or whether it was XML before the problems. So like saying what's the bulk operations, the signal, uh, operations, what is our transaction context? And so on. It remains the same regardless of the technology we have. So we need, obviously we need technology experts to make things work here. But the more important and more costly decisions happen outside of this technical realm and that's uh, very important. And this means that you need to have someone on the team actually dealing with these business questions.

Speaker B: Yeah, yeah, absolutely. On that. Many times I see that, you know, imagine someone who's I don't know, head of API platforms or I don't know, director of engineering, someone with that title. You know, how can they make sure, you know, they're not in the hands on building APIs? They're teams of engineers, architects across, you know, large organization, multiple teams building APIs. How can organizations make sure that there is a process that is consistent, that is delivering APIs that are good quality? Right. In terms of design like you talked about, you talked about that, the technology with uh, um, that API of handling bulk requests, you know, being able to send bulk requests. How can we make sure that there is a good process that is discovering those capabilities, discovering that teams are using a uh, good process to uh, both discover those business capabilities and implement APIs that support them from, from that kind of higher uh, perspective where if you're an engineering manager, you're overseeing people doing this, or you're a director of engineering, you're seeing multiple teams doing this, but you're not doing this yourself. How do you ensure that's there?

Speaker A: I think the first thing if you're in such a position is you need to understand it's not going to be you. So when you are um, member of an API, of a good API platform team, you will provide infrastructure which is necessary but which should be completely business agnostic. But you can try to build a framework where people have certain checklists and certain questions, review list, whatever, so that these questions are answered. And this also means one thing which people like to do is to reuse everything, also to reuse APIs. And I've seen many platform people or architects say hey, there's already an API, just use this and let canva. Many times it works. But again if your business context is different and your quality requirements are different, then you should also consider just building another API with a different interface contract. So again it's not you, you can lead people because they, so the teams um, under you or beside you, depending on your organizational structure, they have the business knowledge and they have the requirements. And in the end your job is to bring these teams to talk together. So the ones using the API, the ones providing the API and make sure that they're not talking about technologies first but talking about actually what they need and require and what they can deliver as well. So if you look at so one typical mistake is you just expose an API and there are lots of internal things in there which no one understands except the one the people building this. So that's something you definitely want to avoid. You want to have a clean contract with business identifiers and business language as well. It's interesting there was some years back an XML schema made by mainframe people and um, you could tell because everything was uppercase only and was shortened to well being completely not understandable. If you have a business term of 20 characters still with four characters in the schema and that's nothing where JSON or XML will help you naming is important or having the right structure, that's certainly something which you need to facilitate that people will discuss these things before they will go to all the technical things. And um, then obviously you will on that small platform uh topic you will need to plan evolution of APIs. So makes sense to decide organizational wide on um, some versioning structure, on some guarantees or typical guarantee classes which you might offer and to provide traceability as well. So think with APIs and even more important also in event driven architectures you must not lose track of who's calling who and who's dependent on who. And all these things. Hey, we can discover this at runtime is more painful than any tool vendor will make you think. And especially if you have certain things running just at year's end, you won't discover them at runtime in the summer. Yeah, so you should have the governance and send your managing and you have the overview. So if someone asks you hey, if we decommission the system or we change this API because we have some breaking change, um then you should gain a chance of this from a platform perspective or governance perspective and you should help people to do the correct discussions.

Speaker B: Yeah, yeah, absolutely. Yeah. That's quite interesting knowing who your consumers are, you know, who your interacting parties are and just those governance, those principles, standards, all those things in place to help that process make it, make it efficient. Which is a lot of where I like to focus on.

Speaker A: I think if you make it short you can say try to abstract as many technology away from the teams. So that's what you can deliver generically and Then let the teams focus on the business capabilities. Yes, but you don't know what they should know.

Speaker B: Yeah, yeah, absolutely. Yeah. And I really like frameworks that help people think hard about those, you know, those, or be explicit in defining those, those business capabilities are, uh, and then kind of all those, uh, related requirements and making that clear. Dan, there's something. You've mentioned it on this talk, you said the phrase accidental APIs, right. And that's something I've heard. You'd like to use that phrase. Tell us a bit more about accidental APIs, you know, what you mean by that, and stories of where you've seen teams build accidental APIs. I think.

Speaker A: Well, uh, I mean, I mentioned this as a conference talk and from there many discussions evolved and I tried to sharpen my definition a little better. And let's see whether this works. So, first of all, an accidental API is an API which was just built without knowing enough. And now you might say, um, for which API or which API did we build where we knew everything? So obviously that's not enough for definition. The definition thus extends to. We never changed and improved that because of many reasons. And usually the reason is that too many people already depended on this old version and we were not able to, or we haven't foreseen API evolution. So an existential API is something which was built by accident because there were some requirements or some imagined requirements. We just put something out there and no one cared to improve it over time. And, um, I think that's, that's a very good definition. So you have something like column which is not straight and on top. You're building and building and somehow everything works. So the house doesn't trash, the temple doesn't trash, whatever has this column in there. But it's painful because you need to make sure you're working around this. It takes extra time to do things with this API and people are too, either too neglected or too lazy to actually make these improvements.

Speaker B: Yeah, yeah, that thing about kind of, you know, really investing in improving the API, and, you know, one thing I find is that when people do UX, you know, user experience stuff, or when people do UIs they need, or it's clear to see where people need to do ux, people need to do user experience, you know, get all that kind of user feedback and interaction, um, to make sure that the principles underlying the UI design fits the consumer and what they are trying to do, what they are trying to achieve. With APIs, probably not so much focus on the, on the experience in some cases, of the consumer. Which comes to your point about having to evolve APIs to make sure they are really addressing the outcome, the goal, the job to be done of whoever is consuming the API. So yeah, really important point there. And then I guess that's one thing where I guess patterns come in because again talking about standards and making sure that teams um, uh, are having a consistent process that is uh, that is good at discovering business capabilities and modeling them as APIs, patterns are a really good way to standardize right what people do. And ah, if people um, have a library of patterns that they can use, they can reference, it just gives them a language and a way to kind of reuse, obviously reuse those designs. Where do you see in terms of just overall API governance, where do you see API design patterns coming in and how do you see helping teams adopt patterns where they need to do it, you know, consistently adopt patterns? Uh, again we're under the age of AI so maybe, maybe the models do all that. You know, we don't need to do anything, we just ask the model and it does all that. What's your, what's your view on this?

Speaker A: Well, interestingly I think the, the AI part is interesting because you also mentioned language. So you talk to an AI also then patterns are beneficial to a large degree I think and let me tell you why. So first of all, what's a design pattern? And I think there's already confusion. So you see on YouTube, design patterns are dead videos coming all along. What these people are doing is hey, they're showing the Gang of Four book and say hey, don't need to talk about factories anymore. Which is wrong. I think that's the probably the most successful book because you don't need to buy it anymore. Every framework you use has listeners, factories, whatever it is. So we adopted these design patterns everywhere. So that's why I think this is a very important, important book. The other misconception is that's not the only design pattern collection book is called Design Patterns for Object Oriented Design. And there are so many pattern design patterns collections for many different topics. And for API design, our book, it's the enterprise, uh, integration patterns for example, which are also very relevant, although they are also quite old compared to IT standards. So and that's I think important. Design patterns convey experience. So it's not, we are the book authors. We have invented all this stuff now we try to find what people do and look for either good names or what it's called already. And one thing is definitely the experience which is very handy. Obviously the other thing is the language. So if we go with APIs and I say, hey, we should have a paginated operation, then certain things are already clear. So without discussing much of the design and the requirements, you know what pagination is, I know it. And hopefully all API designers know what pagination is. Um, so having this vocabulary of things is very important, like factory and listeners and so on. Um, and with AI, obviously if the AI is good enough, we could say, hey, build a paginated API. It should work without specifying what parameters you have and what database queries you need to have. Perhaps, uh, you need to specify some variants. But in the end it's a very powerful language. And having multiple design pattern collections means also you have different design patterns for different audiences. And um, obviously if you're talking about APIs, you have also different roles like platform teams, you have developers, you have testers and so on. But if we just focus on these two, so we have platform teams and for example, they should be concerned with governance and with security. So there are some patterns in our book, governance quite a lot. So tune production, versioning, schemas and so on. So that's something which they can use and build up their vocabulary and also specifying guidelines and saying, hey, these patterns we use for evolution, or you can choose between these two, but not these other ones. And for developers we have API designers, let's call them that. There are more patterns on structure which we can offer. So this book is completely technology agnostic. So if you say, hey, I want to know how to do this in rest, then they are REST patterns. That's another book, but it's there in the market. But if you want to know, hey, I have multiple operations and I need to enhance performance, how do I do that? Then can look in the book and see, hey, uh, there's a pattern for this. And this means that design patterns can serve as a kind of checklist. So what I like to do in workshops, for example, is I have some printouts, say we're talking about this operation here and this API. And then we check or just cross out things which apply or don't apply. And that's also very important. Design patterns are um, not necessarily good and they're not necessarily evil. They're context specific. Like every design decision is. So there are decisions which in certain contexts are good and other decision other uh, contexts are bad. So good design pattern collections will state the context and the consequences you have. So you gain certain things and you do certain things. And these are the trade Offs you must make as a designer. And patterns can help you judge these benefits and disadvantages better. So if you ask concretely for what can people gain? I think platform teams can provide checklists based on these patterns also coming back to your process. So you can say for every operation which you expose, you walk through a certain set of decisions you will make. For example, for uh, every read operation you say, hey, does it need to be paginated or not? And then some mistakes hopefully don't happen. Like you try to serialize a million records in production into some JSON and everything fails. Um, so I think that's the advantages of pattern. So you learn from other people's experience. You have a defined vocabulary set and because you know which patterns are there, they can serve as very good checklists when you're designing APIs.

Speaker B: Yeah, yeah, absolutely. You, you touched a bit about API training and workshops. You know, you've, you've wrote, you've run a, lots of API training workshops, um, in the past. Um, where do you see that falling in, in the organization now? The reason I mentioned this is, I mean this podcast is about API governance for scale. And typically when people talk about API governance, they start talking about, oh, we need, we need, we need design standards, we need a, uh, you know, style guide somewhere. API style guide, we need, we need Spectral, we need to plug in, use spectral in the LinkedIn, or we uh, need a gateway. And very rarely do people talk about the actual training that people need in terms of API design. Well, like I said, again, coming back to what you said about AI models, now, you know, they're doing a lot of, at least the generation of the API definition file or API spec, um, however we want to call it these days. Where does training come in? You know, I think my view is that training is one thing to help people scale, um, how they deliver APIs, to help people operationalize that into their, not just operationalize it, but really bake it into how they build APIs in the organization. Define, how do we want to build APIs, uh, or design APIs? Where do you see training coming in? Is API design training still important for organizations who are building APIs? Kind of API first, if you like, or, or have a lot of APIs. Or do we not need to bother with those kind of trainings now?

Speaker A: I think they are more important than ever. And if you look at the AI space, everyone talks about agents, and an agent only makes sense if it has access to something. The Something is an API, so it's software. So software can talk only via APIs to something else. And now you have MCP in between. But most MCP services are just proxies to APIs or trades. So I think it's more important than ever and I think it shows and a uh, trend or something which I see every time technology changes. So let's say going back to the service oriented days, um, there were many companies spending lots of money building their service oriented architecture and essentially what they tried to do is to fix the problems they had. And then came rest and then you had huge budgets migrating to rest and still people just try to fix the underlying problems. And the same is for BPM business process management and execution. So then people try to fix their services and with AI it's the same. If you don't have your Data and your APIs ready and managed, then you can do as much AI as you like. You will fail because your foundations aren't there. And that's very important. And also if you don't know your processes, then you will automate probably the wrong things. So having your data, your APIs and your business processes ready or in a good shape will help you with any technology. And this includes AI. So if we look at API training and workshops and I think there's a distinction. So training would be to convey something, let's say I uh, do an API patterns training and we will talk three days about API patterns M and it will how they are and workshops is something where you build something with your client. So we come in or I come in and then we can talk about hey, what strategy is best for you, what evolution strategy fits you best? Um, does it make sense to have an API gateway for you or do you need multiple ones? Or uh, where certain responsibilities located in the platform team, the project teams, is there some other infrastructure DevOps team? So organizing these things is important in assigning responsibility and roles to things. You might not say, hey, that's obvious. Yes, it might be for you. But my experience is that many things which I thought are obvious are uh, not obvious. If you come in and talk to people, you have a room full of 10 people and you get 20 different opinions with essentially very easy questions. So I was once having a workshop and we were discussing the API and my question was we start simple, let's look at the patents catalog. We went through the checklist. First part is what's the visibility of the API? Is it public, is it internal, is it community, is it in your solution? And you would say that's a very simple question called API, which is Already there. It took two hours of discussion to actually settle this. I mean obviously that's an outline, but you see that you have many questions which seem obvious, but in your organization you haven't settled this. Also, especially if you look at API platform teams and DevOps teams, there are many responsibilities where people will push it to the other team and the other team doesn't know. And I uh, had this uh, with the development team and their platform teams and it was interesting to see what the platform team thought the responsibility is, which was very, very narrow. So they essentially said hey, we have this API gateway and the rest is your job. And the developer said, hey, well we don't need you for this. I can provision this in Azure myself. I need your knowledge on certain things and these are the important discussions. Um, and these aren't going away with AI. In contrast, you need to have these settled to build your AI solutions on top of stable foundation.

Speaker B: Yeah, absolutely. That's an excellent point. Absolutely. It's interesting to have those discussions in workshops to create that alignment and uncover those kind of gaps or those gaps. And that's the thing with APIs, right? APIs is where you bring the business with the technology, you know, with the different operation, you know, platform teams, operation teams to discuss uh, uh, to really, to discuss how to make the API successful. It's not just, it's not just one, not just a technology or something. So that's. Yeah, go on.

Speaker A: Well, I think. Sorry to interrupt you but I think that's very important. It's not a technology thing or not only a technology thing. Um, so if you have an interface, um, I think that's very interesting. Language wise interface, at least for me as a German, the English and word interface means more like I connect something so something's matching. In German we have another word which actually means it's a place of cutting.

Speaker B: Right.

Speaker A: So if you translate it so you have these two sides, so you actually have a whole huge system like an organization and you cut it with interfaces, with APIs and still they need to work together so you have this integration aspect later on. And this is not only for technology, it's also for the organization. Systems are owned by departments, by teams, by business teams. And once you cut a system, you cut a business process and you assign responsibilities on the left side to one team and on the right side to another team. And that's what people sometimes forget. It's not only technological discussion, it's very often also a business design discussion. And then you have all these discussions which we technicians don't want to have like SLAs and contracts and support and data privacy and whatever it is. So uh, you have a point where you really have a contract. It's uh, technical contract. So what can I call with which protocol which data comes in, comes out. But uh, you also have business capabilities actually which you call thus you have a business side and you have people on the other side needing to do things and agreeing to do things or to fulfill certain guarantees. And that's interesting and that's um, perhaps just an example. I need to be a bit careful what I say and you will understand why. So let's say you have a huge system and you have another system which provides data for this and obviously you have a contract. So this huge system will call into the other system to fetch data. This data is owned by the other system and it has some value, otherwise you wouldn't try to fetch it. So you have the question of what does it cost to actually access the data? And then you have the question of ownership. So this other system now tells you, the business side of these other system now tells you, I want to make sure that the people you show this data to actually get correct data. And this is a reasonable request. I'd say, oh, ah, sorry, I think data which is valuable and which needs to be correct. And they say, hey, we are the master of this data. We now share this data with you and we have some reputation so we want to make sure that you show this data correctly to your clients or to your users. This now violates and that's the interesting part. Every technical encapsulation discussions, usually you say, hey, we have this technical interface really to have two black boxes. We have one team working on this side and we have another team working on this side and that's how we scale. But with this simple business requirement, hey, we want to make sure that's actually correct. You come into the question what specifications, what architecture documents, what changes does from your black box which you want to keep isolated is visible to your upstream partner and that's no technical discussion at all. Figuresight is easy. You make a get request, get some data show, but then arguing about hey, we are rendering some CSV export or PDF export or whatever it is that it's correct. That's another discussion. It's completely non technical discussion and thus also developers should be aware that it's not only technical interface, but there are three different sides of the organization or different organizations on either side of this interface.

Speaker B: Really? Yeah, yeah, that's very interesting. That's very interesting. The business, the business. It's a business interface. You know, it's a, it's a technology interface, but it's a business interface as well. You know, in many scenarios, if you

Speaker A: go back to the service oriented architecture days, essentially service was called a service because it meant some business value.

Speaker B: Yeah.

Speaker A: As API again changed this to API. It's a very technical name but service was meant to convey this. Hey, you, you're providing service or you're consuming service from someone else and the someone else is responsible for this and not only for the technology but also all the business things around this capability.

Speaker B: Yeah, that's, yeah, that's interesting because we're still losing some of that maybe. Should I say history or reason why. Yeah, why that name is there? I guess. Yeah, good point. Just as we maybe round up Daniel M. If I was to ask you what is one, if there's one question that, you know, head of API platforms, director of engineering, someone like that needs to uh, ask about how his organization or how organization is building APIs and governing APIs, you know what, one or two questions should be kind of top of their mind.

Speaker A: I think it should be one technical question and one business question because they will need to somehow get to both sides. So they should probably have a look at how their development teams build APIs in a technical way. So what uh, technologies do they use? What standards do they follow? Are there standards at all or is there some work required to unify things? And the other way is understanding well uh, the business and the business processes or checking at least that the teams understand this so that they are not building these existential APIs but building meaningful M APIs driven by business capabilities. I think that's their job to make sure that all the people involved in APIs know these two things. Yeah, yeah, I agree.

Speaker B: Yeah, absolutely. It's uh, understanding making sure they understand not just the technical but the business processes.

Speaker A: Uh, these are interesting experience. I once had a workshop and I had the developers in there and the CEO of this company and the CEO in the first five minutes told what the company's goal is. And it was the first time the developers here listen to that. And it was very, it's very interesting. So whether you are uh, cx, whatever or it's a management position, make sure that you tell people what the goals are. Ah, because these two days workshop which followed were completely different because people were first they were really darnish what the sales proposition was of this product. But then you could argue your decisions much better because if your decision supported these goals, then they are good and if they not support them or even contradicted them than were bad. And so having people really tell also software developers what the business goals are is, I think it's very important and it's very, has very interesting effects as well.

Speaker B: Really interesting. Really interesting that. Really interesting. Yeah, yeah. And you know, lots of software development methodologies, you know, we start from API requirements and that's good. But this is one case where sometimes we even need to go further back, you know, understand what's the goal, what's the business model. You know, and I've worked in places where people don't really understand the business model. You know, sometimes it's, it's always like, yeah, people don't understand that kind of big business model, what the goal of the company is, uh, how it operates, at least at some level to then make sure to get the context of where those APIs, where those business interfaces fit in.

Speaker A: Yeah, well, it makes things so much easier because if you try to specify things only in what should be done and not why it should be done, then you're specifying hundreds and thousands of pages and still no one understands why this is happening and what's the correct answer for all the gaps you will inevitably have. But if you just tell them in these like five minutes, was only five minutes, and tell them, hey, that's what we want to achieve and then you can extrapolate many requirements out of that visual without having just explicit specifications for them.

Speaker B: Exactly, exactly. Start with why, you know, start with why. Like the, like the book, the popular book, uh, is titled Just as We're um, almost out of time, Daniel. But I just want to ask if people want to find out more about you, what you do, where they can get the book or the um, find out about the patterns library. Where, where can they, where can they find out more?

Speaker A: If you want to reach me personally, so it's at uh, digital-survolution-architecture.com so that's the company homepage and there's a contact form you can reach us. If you want to learn about patterns, there's API-patterns.org where you have the, well the open source version of the book and you have a pattern a day. Also dashes.com where you can subscribe to daily pattern description of the API patterns just to learn for like 3 minutes a day to go through all these patterns. I think that's the easiest way. Um, you can connect on LinkedIn as well. So. Daniel, LinkedIn M. Well, at least remember how to spell my name and just connect and, um, we can have a chat.

Speaker B: Good. Look, Daniel, it's been fantastic having this talk with you. And, you know, there's been tons of insights here, so thank you so very much. And, um, yeah, we'll keep. We'll keep talking. Thank you very much.

Speaker A: Yeah, thanks for having me.