Loosely Coupled - Navigating through API Design

Good morning, good afternoon and good evening, everybody I hope everybody has a nice beverage to enjoy this wonderful time.

It's 7pm Central European Standard Time and I welcome you again to another episode of loosely coupled by bridging the gap.

I'm your host, Karol Skrzymowski.

And today we're having a, whew, that's an interesting topic and quite so in line of my work because, well, professionally I do design APIs.

So we're gonna be navigating API design with two wonderful guests from CodeCentric from Germany, Dr. Miriam Greis and Daniel Kocot.

Yeah, I see Daniel already on the preview laughing that I made a small mistake in pronunciation.

Difficult last names for me always, right?

And today they will be talking with us here about designing APIs and also a lovely topic of data interface quadrants, which is something that they worked on together in CodeCentric.

So without further ado, hello, hello.

Welcome to the stream.

Hello, Miriam.

Hello, Daniel.

All right.

So before we jump into the design topic, the dramas of designing a good API, it's about yourselves a little bit.

Yeah, I just go ahead, maybe.

Yeah, sure.

So hi everyone.

Great to be here.

I'm Miriam.

I'm actually working with CodeCentric for more than seven years now, seven and a half years.

And when I started there, I mainly started as a front end and full stack developer pretty quickly.

But I always, from the beginning, I was in API related projects.

So my first project at CodeCentric was a project where we developed an API developer portal, right?

So very API specific.

And that's how I got into the API topic.

And when I looked for followup projects, I somehow landed in API consulting.

So the last three and a half years, I mainly did API consulting, which means I'm working with teams, helping them to get the journey done from the day they need an API until it's on production, mainly like with enabling.

So not really doing the work, but helping them like in a driving school to not take the wrong turn and land in a desert or wherever, but to always go to the right direction and to reach their goal at the end.

So I saw a lot of API designs, many bad ones, I have to admit, but I think we'll get to that later as well.

Probably, yes.

So just to put that into perspective, because some of the audience are my fellow integration specialists, you're not working specifically with integration platforms, right?

You're working more with the main systems exposing their functionality as APIs.

Yes, yes.

I mean, as well, of course, I mean, there's always some gateway or something, but it doesn't really matter for us what it is, let's say, or for me at least.

There is something, right, that we need to integrate with, but it's not a specific platform or a specific tool or a specific thing, right?

We also spend some time with customers designing and doing concepts for integration platforms recently and all these things.

So we're also doing stuff like that.

But my main focus really for me was enablement and also automation, like a lot of automation around APIs.

Okay.

Daniel, how about you?

What do you do in CodeCentric?

So I'm nine years at CodeCentric right now.

So October was the date for being nine years with CodeCentric, and I did several things there.

So I started as an Atlassian consultant.

As Atlassian is not always on the green field, you have to really integrate the stuff.

So there was a lot of prospectuses in going integration stuff.

And before CodeCentric, I also did a lot of in the integration space.

So building catalogues around data and so on and so on.

And over the time I got in contact with a MuleSoft project.

So everybody has some kind of dark sides in it.

And I saw not how to actually use this, but I understood, okay, there is more.

So I read the book from Yoko about API as a product and so on and so on.

And the economy stuff.

So really thinking about the things and I got deeper into it.

I did a lot of consultancy in regards of API management systems by just using a gateway.

So Kong was one of the first things we did at CodeCentric.

A lot of times.

And over the time I really understood, okay, it's not about the tooling.

It's really about designing stuff, understanding things.

And our CTO did a lot of stuff with me then in the background really to grow up a topic where we talked about experiences.

This is also what Miriam knows.

And we ended now in API consulting and talking about API thinking.

And now we are moving on because we see a lot of things when we design these kinds of integration platforms out there with the customers we have.

And we really see, okay, there's an impact on enterprise architecture.

There is another meaning now in how to interact actually with systems.

And that's why we are actually here.

So that's why the data interface correlates came up.

So, and this is really what we are looking at.

So not really just, as you mentioned, to focus on tools.

We need to focus on really what matters on how to integrate things and really think about the integration steps there.

Right.

So I'm gonna name some things.

You guys point me which is the area that you actually look at.

So from my perspective as an integration architect, well, I mostly work with integration platforms, but that's not all the work that I do.

There's a lot more to it, including API management, including event message brokers.

I usually, when I look at integration practises or APIs and API design, I look at it from a perspective.

Okay.

Is this internal communication or is it externalised?

Is that externalised communication productized or is it partner?

Because these are two different topics there.

Then internally, is it again productized service-based because sometimes it's data, sometimes it's services.

And depending how long ago somebody started in the world of application integration, some of us may still remember something called service-orientated architecture, which is basically defining APIs as a business services.

So verbs, always a post, never get or put or anything else in terms of the HTTP verbs, but always a verb-based name of a service, get customer, set customer, whatever that is.

Now the difference is nowadays we use rest or try to be restful.

And then we have access to resources and we're modifying those resources using the HTTP verbs, right?

As actions to what we want to do.

And then additionally, all of this is usually covered by some sort of an API management from my perspective, whether or not it's a singular system in Azure, AWS, on-premise, microservice swarm, because hard to name them otherwise than swarms at times, also often prompted by an API management.

And I'm usually, as a architect, I'm usually the consumer of all those APIs of different domain systems.

That's my perspective on API.

So I see the APIs, sometimes they're easy to use, sometimes horrendous to use.

And my job as an architect is to make them useful.

So probably something similar but in a completely different way.

Yeah, something, a little bit.

Would you like to start?

Yeah, I think, I mean, I mainly agree with most things you said.

I think I see it more from a provider perspective most of the time because I mostly work with people providing APIs right now, right?

Okay.

So I more or less support them to actually get to an API that others can understand.

And that's hopefully intuitive to use and not just something, right?

So, but I also realised that lots of times it's really good if you have both sides, you actually need both sides to really understand like what does the other person on the other side really need, right?

It's not enough to only know one side of the game, right?

You always need to take in both sides, the consumer and the provider and not just one of them and think that's it, right?

And I think that's also quite an interesting topic that most people underestimate actually.

Probably to a very big extent, they underestimate that.

All right, so that said, what is the problem with designing APIs?

Can we define that kind of a problem?

What is that?

You're missing actually the experience because this is really something where all the ideas started actually because a lot of people talk about UX actually, so really user experience and this is somehow lacking because we have this technical aspect still there because this is what Mira mentioned.

We don't really get into the conversation with people and really asking what is needed.

We do this when we create UIs.

We ask people, we do tests and all about.

This was really at the point where I started to learn from Uwe actually what he did in the past was something that was really missing, this experience aspect.

And so we started saying, okay, we call it API experience to make clear, okay, we don't talk about the technical behaviour behind all that because this is clear.

This should be clear.

We learned over the time that still is not clear what technical to be done.

That's the other aspect of it, but we have to stress this experience layer more and more because when you remember MuleSoft, what is the layer above?

The experience layer.

But normally when you look at integrations built by that, they are not really experiences they provide.

Would that tie into thinking in terms of data products then?

Yeah, that's the other point around because then it comes into the productisation type of thing really to stress this word.

For now, it's really buzz wording to say, hi, we do APIs as a product because nobody really has in mind that it's real product management.

It's real, the capabilities of providing a real product and not just to say, okay, this is a technical somehow thing.

I just throw it over the fence and it would work.

So it's really that I have to do the marketing aspects into that.

I have to build up a community inside an organisation to really make sure that everybody understands what I'm doing there.

So many, many perspectives there that we actually know from this classical product type marketing fluff.

Yeah, to also add something to the user experience thing.

I think, I mean, that's why I have on LinkedIn also my slogan, APIs are user interfaces too, because I think most people forget for them, they're a technical asset, right?

So pretty easy, you do something technical, you're done, but that's not the issue most of the time.

There are lots of other things that you need to know to design a really good API and it's not only technical stuff.

And I think most people forget, especially for an API, that there's also a user on the other side.

I mean, it's easy.

We've all been developers, right?

We think, oh, I know what a developer needs, right?

Right.

Do I really know?

I mean, I worked with teams that were SAP developers on the other side, you had a mobile developer.

They had nothing in common from how they work, right?

But they just think the other person will know what to do because hell, everyone knows this function module in SAP could possibly go wrong, right?

Everybody knows.

You touched a very painful memory here because I used to integrate SAP R3 back in the day.

And that used to be with very specialised adapters that were on JMS. The RFCs were horrendous to work with and the debugging of that was horrendous.

And understanding the interface, I mean, I get it.

Germans wrote it for use within Germany.

That was obvious.

Well, that's the story I get from SAP people, all right?

Just to be clear, I work with a colleague from SAP.

That's usually the kind of story that I said.

And then it sprawled all over the place, right?

So it sprawled, but then I'm sitting there in Poland trying to integrate R3 into the ecosystem.

And I'm looking at this interface and all I see is gibberish because these are abbreviations of German words that I have no idea what they mean.

Only people from SAP actually knew what the hell that means.

So I'm like- Believe me, it's not only a language issue.

It's not only a language issue.

Oh, no, absolutely.

Not only a language issue, just using abbreviations.

Who in their sane mind uses abbreviations in the data model of an API?

Yes.

If they were, at least if they were full words in German, I would take a Google translator or something like that or a dictionary and translate them.

That would be usable because I could actually decipher them.

What was there, I had to just literally grab an SME and explain to me, please either give me a data set that works with this data model or explain to me what I'm doing because I have no idea.

Yeah, that's what the team actually told me.

You know what they told me?

If someone wants to use our API, they have to call us.

And I was like, well, we're trying to do intuitive APIs.

Please think a minute.

I don't think you want anyone to call you to use your API.

That is basically the death of a product nowadays.

At least with smaller companies because SAP is too big to die off like that.

But I think that if a small digital product would do such a thing, they would not have any adoption.

You touched upon an interesting thing and I pondered upon user experience as well.

There is a lovely UX law that is, I think it's completely underestimated in software design as it is and not meaning front-end only.

And I'm gonna just shoot a slide from my training deck on the screen for a moment.

So there is this lovely law called Tesla's law.

And yeah, every application must have an inherent amount of irreducible complexity.

The only question is who will deal with that, right?

So what happens there is if I look at it from an interoperability perspective, we're moving around complexity or adding complexity by doing bad API design.

And if we talk about interoperability from my perspective as an integration architect, well, okay, if we talk APIs, yeah, sure.

If I put an integration platform, I move a lot of inherent complexity of communication to the integration platform, which makes life easier for the domain system, but this still doesn't fix the quality of an API.

So that moves the added complexity of a bad API towards the integration platform that has to consume that API and understand that API.

Yeah, yeah, I think if I talk to developers recently, it's always like, oh, we don't want to do that on the back end, that's so much work.

And I say, well, then who does it?

Then someone else on the front end needs to do it or on the other side.

I mean, if you don't do it, someone else has to do it.

You're just moving the work somewhere else.

That's exactly that.

You're moving inherent complexity.

Yeah, exactly.

And I like that you cited UX law because I think we didn't talk about it before, but my PhD is actually in human-computer interaction.

So that's very much why I like API design so much.

And I like trying to do it in a good way because it's like in my DNA, right?

It is user experience.

It doesn't translate to user experiences and clickable in the front end because that's called developer experience.

So the experience of a developer trying to connect their system to whatever array of APIs we have.

And this is still somewhat of a user experience just from a technical perspective, not from a actual productized usage perspective as the end user, the consumer clicking on the app, right?

That's the difference there, but it's still the same user experience in that sense.

And as I work with integration platforms in large environments where we have a variety of systems, SaaS solutions, legacy, on-premise, in-cloud, hybrid, well, it makes sense to put that complexity to the integration platform because there's too much to handle rather than solve it on the backend.

And of course the backend quality matters.

So if somebody is starting to expose to the integration platform a relational database table by table, well, that's not good API design, but it differs for a domain system or a productized system when we externalise our APIs.

Now, because I have no experience in externalising APIs to clients, that's not my scope of work, tell us perhaps how does that look like from that productized perspective?

Yeah, it's actually when we think about design because this is something we actually didn't spot on because what we do with API thinking is really look at the design perspectives.

And to really say, to go into this productisation type of thing, I think it's mostly important that we reference to Dieter Rams in regards of design.

So somebody who was really deep into designing good things actually like a calculator from Brown and other things, a shaver.

And also he has been acknowledged by Apple for the iPhone design and so on.

So it's really interesting that we actually had a look at it because you mentioned the UX and UI laws that are existing, there are even more.

So Nielsen and Muller are also there.

And this is what really matters in the end to build these experience to the outside world.

So even thinking in a productized way, because I worked or wanted to start to work with a payment company and they had a key value API and they thought it would be the best idea to productize that.

And this was really something that felt quite hard because it was in the beginning.

So it was around 2019 before Corona, I think also.

And it was quite hard because we were just starting with the thing.

So Mir was actually not onboarded into this topic.

And it was quite hard to make people understand that there are so many differences in there because there's no literature about it.

And people always reference into it.

So it's literature about API management systems, it's about RESTful APIs and so on and so on, but not all the things really in regards of good designing stuff.

Because thinking about technical stuff, so having RESTful web APIs or whatever, it's totally different than thinking about, okay, what really needs the person outside of our some kind bounded context to really understand what we provide with our data actually.

And this is something where I see there's still a lot of things around.

So you really have to go into the field and really ask the people.

And then bring the stuff up there.

So this is why we got really deep into this API thinking stuff there and really adopting things from that perspective.

Okay.

This is what I think because we strive design, but really to make it clear, because it was always the perspective on this integration platforms, you mentioned that.

And so we talked with a lot of people and when you go into real integrations, it's always this EDI topic.

Yeah, and it's quite hard to make it visible to people.

And then some people say, oh yeah, we have to do EDI because people actually in retail use it a lot.

And this is where it all goes there.

And in the end, there is also the principle really, and this is the principle, good design is as little design as possible.

So I don't have to reinvent the wheel to get things to work.

So I don't have to think in a new solution or build a bluster-full API when there is a need for real EDI exchange.

So there are still products in the space that do this and you don't have to do the things and say, okay, let's build an API up on this and have it a shiny REST interface or something like that.

So it's really about to really keep the focus on what the customer or the consumer on the other side really needs there.

Because in that sense, it's all about doing proper trade-offs, which basically means that if we want to design properly or architect properly for a business problem, we're not looking for the best solution because that's gonna be over-engineering things.

We're looking for the least worst solution.

So the one that will be sufficient to solve the problem and nothing more.

And if we need more, then we'll do more, but we don't know if we need more yet in that sense.

But I think my experience with that is, especially with REST, people are so focused on it, they don't think of anything else, right?

You will have people and talk to them and they say, we definitely need a REST API.

This is what everyone is doing.

We need to do it too.

And then if you're talking to them and you're saying, well, wait a second, what do you want to do?

Why do you want to do REST?

Most people don't even know how old it is, where it comes from, why you need it.

They just heard it somewhere, they picked it up.

They say, everyone's doing that, we need to do it too.

And I said, well, wait a minute, let's see what you want to do.

And then we can discuss whether you need REST or not, right?

I mean, the beginnings of REST. I remember the first occurrences because REST was designed for communication back and fronted, right?

So it wasn't designed per se for system to system interoperability.

And when people started using REST for a system to system interoperability, it wasn't mature enough yet to do so.

So no data validation, no support in libraries, no proper support for simple types.

Everything was a string.

And no support for a regular expressions, no support for enumeration, etc.

Now it's a lot better.

Now we can do all those things with a open API specification and RAML if somebody is using MuleSoft.

But a few years ago, that was a nightmare to do that over REST where I was looking at a XSD and a WSDL definition of a SOAP service.

It's like, I can do so much better in terms of the quality of an API that will be better defined, properly defined and giving me a proper service.

And here I'm like, how am I supposed to even validate that where I don't have even the tools to do so?

And still, okay, it's a lot better nowadays, but still in certain cases, XSD wins over anything REST related, well, JSON related per se because REST doesn't exactly mean JSON, it means verb use over HTTP with a specific data format, which also some people don't understand that REST doesn't mean JSON.

It may mean as well, XML or well, you could put any other format for that sake.

I mean, most APIs that claim they are REST are not really REST because if you don't do hypermedia, you know.

And that's a conversation I had on LinkedIn recently.

Yeah.

It's actually not a true statement because there's difference in doing a REST API and doing a RESTful API.

That's correct.

These are two different things.

Yes.

RESTful API is, and we touched upon this just before the stream, so I think I'm gonna just Google it, the Richardson maturity model, right?

Yeah.

So a RESTful API is the third level of the Richardson maturity model, but that doesn't mean that the second level or the first level are not REST. They are REST. They can be REST, but they're not RESTful.

RESTful is hypermedia.

And a lot of people claim or dilute this, that REST means RESTful.

No, it doesn't.

Yeah.

I think I like most what one participant of one of our training said once.

And I think that's one thing we also quote in our trainings all the time.

And I liked it very much.

She said, if you're honest, we're all just doing JSON via HTTP.

I mean, right?

We're not doing REST. We're doing JSON-based HTTP APIs.

And that's what we actually do, right?

Most of the time.

Well, again, that's REST. That's not RESTful.

So we're doing REST. We're not doing RESTful, definitely.

And that's the problem here.

And people forget about that.

I already know people that when they hear XML or SOAP, they get, why?

It's like, these are valid formats.

We still use XML everywhere.

Most of the low-code tools that I use or my colleagues use, they're XML-based.

They're defined with XMLs.

A lot of configuration for a lot of things is defined in XMLs because it gives that rigidity that you need for those kind of definitions.

And especially that, not sure, but I think that still there is a lacking space in using parts of a OpenAPI specification outside of an API because XSD is very much usable outside of an API.

You can use that for data validation.

You can use that within your code, somewhere in Java, C-sharp, whatever that is, and use it with XPaths, XSLT to transform data.

Whereas using the same with OpenAPI spec or RAML is not exactly yet available, at least to my knowledge.

Maybe I'm wrong because I haven't done research in that space for a longer time, but that's, again, the difference, right?

Yeah, this data thing, I think it's also on another part because for most people, it's not really clear what they actually share.

So even if they would do SOAP or whatever, it's not really clear what they're actually sharing there in regards of data.

That's another point.

That's why we put it in the methodology with API thinking, what we prefer and bring to customers we have in this perspective, because it's really relevant because most people are not really aware what is being shared actually, or don't know who is the owner of this data set actually, or if is this data set somewhere defined.

So when we talk about data catalogues and all the things there, so I'm not dropping this mesh thing because this opens another bottle there, but in the end it's really something that things we do are actually quite old, but it feels we are not mature enough to really use them, or we didn't understand them right.

So this is what we see when we go into the field.

There's always this tool clashing.

So even when we go into the perspective of REST versus events, it's always that you have a RESTful integration platform versus the event broker or something like that.

And this is really, really interesting in a bad way on the other side.

And I think with this, even when we show up this maturity model, it's always confusing for some people that there is something, and we make fun out of it because we point the date on the slide deck which we use.

So it's 2008.

And I think for most people it's not clear that this model has this mature age actually.

Yeah.

So Richardson maturity model, I don't know the date on that, but basically it was on Martin Fowler's blog in 2010.

That was the link, the QR code you saw on screen just a second ago.

The photo there, that was not Richardson, that was Martin Fowler nowadays, just to be clear.

So it's very old.

REST itself is very old.

When you got here, 25.

Yeah.

SOAP is quite older in that sense.

If we look at service-orientated architecture, the pinnacle of service-orientated architecture was 2000s, and SOAP is much older than that.

XML is extremely old already from our perspectives, right?

So people don't understand that these standards are there, but we just didn't grow into them yet in that sense.

Just as a small segue, I literally saw a YouTube short today, just before the stream, where a girl was saying, I told a teenager today that I'm older than Google.

And the teenager was like, that's not possible.

Yeah, if you were born before 1998, it is possible.

So all of us, I think are older than Google here.

Well, it is what it is.

So people don't know.

My favourite story regarding this is always then, when I went to school, I had a card for the telephone outside the school because I had no mobile phone.

So if the school would like, you know, I need to go home early because a teacher was ill or whatever happened, I would go to the phone box, put in my card and call my mom, you know?

And everyone's like, if you tell that to any young people today, they're like, what?

And I'm like, yeah, well, that's how it was, right?

There was no mobile phone that you could just call anyone.

You would like need to check if someone's home or if you need a key, you would need a phone card and you would go out to this one phone box in front of the school, right?

I'm still waiting.

I'm still waiting with my kids to show them a rotary phone, you know?

And properly connected somewhere.

I don't know if I even have cables to connect the phone in my house nowadays.

But to connect it and tell them to call somebody.

I'm curious what will happen in the few years that they will be able actually to understand how to use a phone like that.

It's like, that's gonna be interesting.

People have no idea.

If we look at specification of XML, I don't know if this is, I would have to look at that W3C, but basically 1996.

Yeah, that was also on my mind.

So there they are.

So it's extremely old.

And if you dig in ever, try to dig into the original specification for XML one, there's plenty of things that were solved out of the box in the first specification.

That if you look at the early stages of Jason and Swagger, not solved at all.

Nobody thought even about these problems at the beginning of those formats.

So it's difficult in that sense.

We're trying to reinvent the wheel and I get bandwidth costs.

So that's why we have Jason because it's lighter than XML.

But it's the question of what we use that for.

But going back to designing API.

So just put the perspective on things.

What would you consider a bad design of an API?

I know, Pandora box.

Let's open it.

Bad in what sense?

I mean.

Okay, let's categorise what sense we can have.

Okay, so one bad thing.

I don't know whether anyone of the ones who's listening in ever tried to use the Azure DevOps API.

That's my favourite API to use because all the examples are wrong.

You don't have any example of a valid request body.

So you're just doing trial and error until you guess the correct request body.

So that's something I consider really bad quality because guessing request bodies is nothing I like to do actually.

I mean, it depends on the endpoints.

There are some that are maybe used by lots of, but if you really want to automate stuff, you need to go to many endpoints and then it gets funny.

So that's one thing.

Another really bad thing I saw was from a, I think it was a pizza delivering API or something like that.

And it was a real example from someone who showed it to me.

So the API was used for ordering the pizza in a front end.

And the IDs were integer, which means you could just take the next integer and then get the credit card details plus address from the person who ordered the pizza, where I say like, well, this is like, I mean, this is bad design on another level.

It's a security related fail, but that was interesting too.

So integer SIDs is usually always like bad.

And what else?

All our three APIs, basically more or less, if people don't know how to convert a Boolean to a correct Boolean, and then you get an X or an empty string and you have to guess whether this is now a Boolean or not in SAP, for example.

Okay, okay, fair enough.

Microsoft date timestamps, also very nice with our three systems.

Timestamps that nobody can convert because nobody knows how they work, right?

Why are there standards for timestamps if we can invent our own, right?

But these are all minor things, like Daniel, you want to add something?

Quite interesting because it was all technical in terms of that.

Yeah.

Okay.

For me, this wording of good and bad really depends on the scope and actually on the type of organisation of the structure, the people involved actually.

So there can be a really bad design for somebody outside of the scope, but it can be the best and good design inside the scope.

And now we are actually touching indirectly the DIQs somehow.

Okay.

This is where it actually all came from somehow because we saw things about, okay, actually for this purpose, it's good, but it's not reusable.

So we really have to think about, okay, for the scope, for the bounded context, it's a good design.

So no discussions about that.

Because a lot of people are triggered by this good design.

They think, okay, there is some kind of guideline book, somewhere somebody wrote this, everybody adds something to that.

And that's why a lot of people also look at guidelines from other companies to really get a glimpse what good API design can be.

And this is the perspective I have on this because moving away from the technology, because it depends.

Yeah.

If I understood things good, then my design will be correct.

If not, my design will be not so good, but it could be right for the purpose I'm using it.

So this is really to think about.

So, and this is what we see in trainings.

This is what we see in discussions with people.

It's always that they think that we have some kind of magic book with us presenting good API designs.

And we're always asked for the, you know, the, how do you say in English?

The like solution for a task.

And we're saying, well, there is not the one right solution.

That's exactly the funny part about API design.

There is not the one solution is for everyone, right?

It depends on who are you designing for?

What use case?

What do the people want to do with it?

Like what's the, what are the systems involved?

What can they even do if they don't, if they can't do JSON and only XML, then well, you don't do J, right?

I mean, there's so many things that you need to take care of.

So people always expect that we have the one solution and we're always disappointing them saying, no, there is not the one best solution will never be, right?

And I concur here because it, from at least architecture perspective, when I deal with different architects of different levels and kinds, because there are so many abstraction levels of architecture.

It always is about context.

Context is king.

And if we just talk in an academic sense, the answer will always be, it depends.

If we put that in a specific context of a specific problem we're solving, then we can put it in specific terms, what would be the guidelines for this kind of problem?

But there are no universal guidelines for APIs.

Well, maybe a few hints, few.

Something like don't use the wrong data type, like the basics that I just mentioned.

I mean, I think we agree with the basics, right?

Or use human readable names for attributes.

Or free here.

Defined something like that.

So the easy parts, but what we see really is there must be one solution.

There must be this golden record.

Everybody ever thought about in data structures.

And this is what we then have to reflect, even in the trainings we do.

They always think there is this one solution.

The both will present at the end the solution, how it should be to solve this specific problem.

So we have some kind of example with us when we do this API thinking training.

And there is really, from the beginning, the expectation that we will present the final solution at the end.

That's why we have a slide at the beginning saying, we're never going to do that.

Don't expect that from us.

And the fun part is that people always like, if you give them a task to design an API, at first they think it's very easy.

We do a room booking API.

I mean, how difficult can it be, right?

Pretty easy example.

Everybody understands.

And when they start discussing, you know, and you're really going there, for example, it has some tasks like it should be a filter for the size, the amount of people that fit into the room.

And then people design a filter saying size.

And I come there and the first thing I say, oh, in square metres, great.

I need a very large room.

And then, no, no, no, that's a number of people.

And so, well, I didn't read the documentation.

It's the size.

It's clearly square metres, right?

Why should I read the documentation?

Pretty easy.

And they're like, well, and it starts number of seats, capacity, and they're discussing several things, right?

It's not only about the technical things.

It's also about the semantic.

What do you want to say with your words?

And it's very difficult to come up with something that you cannot trick, or you cannot come there and say, well, I agree.

Do you mean this?

And they're looking at you like, no.

When we were researching coupling in interoperability between integration platforms and trying to define that, because we define all integration patterns with coupling definitions.

And there are different levels of coupling.

So if somebody doesn't know about coupling, I recommend reading balancing coupling in a software designed by Vlad Kononov.

Absolutely amazing book.

I'll put the QR code in a moment.

And people treat coupling, first of all, as it is binary.

It's not.

Because if it were binary, we wouldn't be communicating.

And our applications will be in the vacuum of space, which is a non-existent scenario.

But there are different levels.

And people don't really realise that some types of coupling we actually want in our applications.

And this, what you mentioned here is semantic coupling.

The semantics of understanding of the data we're trying to convey through our APIs.

That's something that we actually need to discuss every single time, whether it's a productized API of a SaaS solution or an internal API used for a singular purpose.

And that's a very difficult conversation because people think that they can solve it with just a technical bubble without a conversation.

And it's not the case.

To give you a very short example, I dug up just a moment ago, a very old WSDL file that I recreated, but I really sent this kind of WSDL file to a colleague of mine back in the day.

Let me just find the right window.

There we go.

And that's obviously a joke.

I don't know if you can read it, but I can probably make it a little bit bigger.

So it's a very simple WSDL file.

It's a very short one.

It's only has 44 lines.

Basically not a lot there.

The story behind it is that a colleague of mine, when I was working in T-Mobile asked me for a WSDL file and I was substituting for a different colleague who was an other integration architect and she went for a vacation, but I was taking over several projects from her.

And that particular person asking for a WSDL file covered several other systems, small domain systems.

So he didn't tell me what kind of system he's representing in his ask.

He didn't tell me which project he's looking for.

So I was feeling very whimsical at that day and I gave him exactly what he asked for, a WSDL file.

The worst part of it, there was no conversation.

He didn't even open the WSDL file.

He just forwarded that to the development team and they came back two weeks later asking, is that the final form of the WSDL?

So while this is a, let's say sloppy recreation of that lovely WSDL file, it actually was something like this.

And then again, for the purpose of defining an interface, was that a bad API for the purpose of making a joke and making a statement?

But again, context is king because this definition was for a joke, not for you.

So perfect.

If you would use that for an actual API to convey something, uh-uh, well, dummy, dummy, dummy, and any type everywhere.

So that wouldn't work, right?

But maybe people are used to seeing such bad things so they think it's real, you know?

Yeah, I've seen a share of APIs, SOAP APIs that were defined some fields and then any type.

And you put CDATA in it, because why not?

And then you guess that CDATA.

I've seen APIs that were interfaces written in, like REST APIs written with JSON, and then CDATA XML embedded in them because something underneath understood XML and somebody just exposed an easy JSON-based API to just get that XML inside.

Yeah, I also like these REST APIs that just return objects.

And in the object, you have the key, the value, and the data type.

I mean, easy in the backend.

You just develop it once.

You can easily document it, but nobody understands what this API is supposed to do, right, because you get a random number of objects with random values, with random names, and random data types.

I mean, how, and then I asked the team, how do you want to document this API?

And they were like, yeah, well, I was like, right, exactly.

That's the problem.

You can easily document it, but nobody will understand what it's doing because you can return anything in your objects, right?

Another example of this kind of behaviour would be putting every field as optional.

You put a array of attributes in your API, even in a flat structure as a flat JSON with one level, and all of them are optional.

How the hell should I understand which fields do I need to actually put in or which fields should I expect for what scenario?

It's unrealistic to use that in a timely fashion to consume.

It's a cognitive load that the consumer just takes on.

We're moving that complexity to the consumer.

Yeah, again, that's what we said before.

We're just moving the complexity somewhere else.

I had a real example with an API that had actually 120 fields in the body with nothing being required.

And it was like- Wow.

Exactly.

The developer sat in front of it and said, how should I use it?

I have a mobile application.

So what do I do?

I don't even know which field is required.

I cannot show a form with 120 fields.

I don't even know what I need to actually make this work.

Yeah, so because you guess what?

You can guess why it had 120 fields?

No.

Someone took the database from my one, of course.

From our three, because you can.

Because nobody told the developer what the API was for, why it was needed, what was needed.

She was told, create an API for this database table.

Of course, I mean, you know?

Makes sense that the API is that way then.

Yes, exactly.

From a logical perspective, it makes sense.

It's a classical joke.

What was that?

Wife tells the programmer husband, go to the shop and buy milk.

If there are eggs, buy six.

And the husband comes back with six milks.

Logical.

That was a logical statement.

That was how, from a perspective of logic, you would understand it exactly that way, but.

It's dramatic at that sense.

Another example is that there are interdependencies between attributes, optional attributes, or some are required, some are optional, but optional attributes are required based on the existence or values of other attributes.

That's another common problem with a lot of SaaS solutions products that expose APIs, and they try to solve something because they couldn't solve it otherwise, for whatever reason, or they didn't have the time and product capacity to solve it.

It's a nightmare.

You either need to have this field, this field, or this field.

These are also things that you cannot really document very well with the current tools, right?

So if people come and say, well, there's a combination of fields, and one of them is required, that's also always kind of difficult, right, to bring across from a design perspective.

Like, why is it like this, right?

And then lastly, I think that a very common mistake that happens a lot of times, and I think this is a good segue to go to the AQs in a moment, is that people don't think about what they're exposing.

And I saw several times that instead of exposing a more complex of a structure of an XML or a JSON tree-like structure, I have an array of functions that expose flat structures as literally as the database table, relational database table shows.

So it's fun if it's a NoSQL database, because these are already complex structures, usually not flat JSONs.

But if it's a relational SQL database, and people start putting APIs on top of that, it's like, oh yeah, but you're gonna expose the tables directly.

And then the consumer needs to join the tables together by calling several APIs, and that brings another set of various problems, not only from the perspective of the cognitive load of understanding those, but if this is alive somewhere in the cloud, that's a realistic cost, because data at rest costs nothing, but movement of data in cloud costs quite a lot.

And we're now calling several APIs, so we're basically sprawling costs.

I think that's also something that's really underestimated by lots of people.

I had discussions with developers saying, well, but data transfer costs us nothing.

And I was like, wait a second, that's not true.

I think that's really underestimated by a lot of people.

They think it's better to always, I mean, there was a discussion where we had a table as well in R3 that they wanted to expose via a REST API.

And one of my favourite questions is, how often does the table change?

And they said twice or three times a year.

And they wanted to call it every time the user does an interaction.

And I was like, no way you're loading it every time the user does an interaction.

If it only changes at maximum three times a year, right?

But that's then data transfer doesn't cost us anything.

And I was like, well, not you personally, but.

Yeah, if they own a data centre and they host that on premise, yeah, sure, do it.

But this is the thing.

People are still there.

This is, these are the people we meet actually a lot when we do trainings.

Okay.

They still have this perspective and they didn't get the shift into the cloud.

And now they're shifted again to do things.

So we hear a lot of things then.

Oh yeah, we are using MQ.

We have to get rid of it because of costs, blah, blah, blah.

Now we will do REST as an alternative.

This is reality.

This is what we see at customer side.

Going from asynchronous messaging stuff to RESTful APIs.

Oh my, oh, that's painful.

Yeah, that's painful.

Yeah, that's absolutely.

This is what we see in the field.

And that's why we are actually in this space of the IQs because we hadn't, we did the training a lot of times and we were struggling in this context because we had to hit somehow the backend.

We had to hit somehow gateway structures, middleware, whatever.

And it was quite hard really to illustrate what to choose actually, what data set will be transferred somewhere, how to call it actually.

But we started with some kind of two-way thinking but this was not explicitly because we left out back at forefront and at that point and so on and so on.

And this is actually what happens there because people, and this is what we see in the field, are just replacing technology by technology but not doing the upskilling to really understand what's the real integration problem.

Another fun fact, I always ask this question in my talks when we do trainings and when we are on customer side doing negotiations and preset or whatever.

The question is always, did you have ever read the book from Gregor Hohpe, Enterprise Integration Patterns because we're talking about this and you can think about what the answer is.

Now, I do have a little bit of a beef with that particular book for one good reason.

It was written way before we had cloud computing and integration platforms that were microservice systems which gives a completely different perspective on interoperability.

But if we're talking system design and system interoperability, that is basically your guidebook on doing proper event-driven integrations within your system and why you need to do them.

So that's a very valid book from a system design perspective and system architecture perspective.

So that's something still very much applicable.

If you look at interoperability at scale of an ecosystem, it became less relevant over the years and this is still a huge gap to be filled and that's the problem there because that gap is not yet sufficiently filled.

And if we have materials on that, they're paywalled with specific vendors and that's a completely different problem.

But yes, this is a very good book.

This book is really the starting point.

So when I would like to go into the integration space, this is the one I should read.

This was the one somebody at CodeCentric forced me to read when I got more into the integration space to really understand, to get the wording, to understand how there's things to actually present and really make it visible there.

And then you are totally right because the next thing is we have the Richardson book in regards of microservice patterns and so on.

That's the next thing.

Nobody, it looks like nobody is really reading these pattern books to understand the basic things around architecture.

As you mentioned, we have different roles, levels of architecture and it's always even for us a mess to then talk with people and hear what they're actually talking about.

We have trainings and it's sometimes hard that we have to resist to really tell, okay, this is not true what you are telling here.

Yeah, and this is not what comes up.

And normally in these trainings, when you have these strong characters, I would call them, it's always, I didn't learn anything.

Right.

And it's like, okay, yeah, fine.

We make a check mark.

Yeah, because they came already full so they didn't have capacity to learn anything because they were convinced they are right.

So obviously they didn't learn because they didn't listen.

So that's a problem.

Boxes, okay, this is what I think.

Oh yeah, they said it also, they said it also.

But in the end, it's more about, and this is what we're telling always in trainings about adapting things.

So we know when we talk about API thinking that nobody will fully adapt this way of structuring what we developed there.

It's really some kind of, I can take parts of it and make it work for the situation or the organisation I'm in.

And this is really funny that people think they have to go the whole way.

It's always, it's also the same with the API obstacles which we are also using.

And it's always to really bring up the whole space.

And it's sometimes just enough to go at some point, at some level and bring it into this.

So Miriam's I think already pointing there to the obstacles.

So I'm at first, Marjukka Niinioja developed 2017 or something like that.

And it's really bring to bring more the business side into the game to really make it understandable what we are doing with, yeah, with building APIs even if there are synchronous or asynchronous.

This is one of the points there.

So it's really, I think it's something, what we also, I think Miriam can also agree on that is really the upscaling factor.

Because there's this discontinuous learning we have to learn.

So it's not set in stone that when somebody is at university and had some kind of development courses, they are ready to go into this integration game or can be sent to an training for doing this.

It's really also understand and learn over time.

So it's really about learning.

But I think that's also something we didn't tackle yet when we talked about the topic, but you now touched it, Daniel, the knowledge thing.

I think one thing that I'm always asked as well is, isn't this a problem that you tell people stuff about API design?

Won't they feel offended if you try to support them with enablement and say, well, no.

And the reason is none of the teams that I usually work with are API experts.

They have no clue.

They're happy that there's someone who can guide them.

And I think this is what many people underestimate.

They put a lot of, whether it's whatever it is, they put a lot of integration pressure on teams that already have a backend, they already have a system, they already have a database and their job is something completely else, maintaining the system, making sure it runs, making sure the backend runs, making sure the database runs.

And on top, someone's coming saying, hey, we need your data.

Give us something we can integrate against, right?

So- And that's also a architecture problem because a lot of those systems were designed without interoperability in the design.

The interoperability is slapped onto those systems.

So it's not thought through from the beginning.

What are we actually gonna do with that data?

Where it's gonna go?

And nowadays, all systems are distributed.

There are very few systems that are actually isolated and work in isolation, which basically means that most systems nowadays require interoperability to be a first-class citizen, really, right?

So it's difficult.

And then it goes even worse in large-scale environments,

corporate environments,

because some people get the lovely notions

of the centre of enablement and citizen development,

and then they force those domain system teams

to also do application integration

as an integration platforms

and cater to the modules of the integration platforms

and take responsibility for that

without even knowing what that is

and how to deal with that,

because they're database experts.

They're domain experts.

They're whatever else.

So it's the difficult part there.

All right, let's touch upon, because we know that Daniel has to go tend to his fatherly duties.

That's the downside of having kids at times.

It's fun, but there are responsibilities.

Mine are covered by my wife, luckily, this time around.

So let's dive into the AQs.

And I already took the liberty of taking the diagram earlier from the side.

So let me just bring that up.

Where do I have this?

This is this one.

So I have this for my convenience in Draw.io, because I do have some drawings on this in different tabs.

So the AQs, data interface quadrants.

Tell us, what are we looking at here?

Because this is probably quite foreign to a large number of people.

I mean, for me, the concept was very foreign when I read the article.

Now I'm quite a fan, because it's very useful.

So walk us through, what are we looking at right now at this particular diagram?

And just for those who want to read the article, this is the lovely QR for said article on the code-centric side.

Yeah, let me start.

So basically, this came out of a bit of all the discussions that we had before, right?

We have just discussions with people regarding what is good API design?

What is actually a good API design?

How do I know?

And we realised that most people don't know what they actually build their API for, right?

If you ask them, they don't really know, what are we actually building?

Like, so we tried to put it in a picture to make people clear, where you are is not where everyone is, right?

There are different people who are building different things.

And depending on what they're building, there might be different requirements for those things, right?

So basically, on the horizontal axis, we put raw data and aggregated or transformed data.

So raw data doesn't really mean unreadable names, right?

I think we agree to that.

There are standards, I mean, because some people said, yeah, then I just use the database names and say, well, this is not what raw data means, right?

Raw data means at least like, it has to be readable, right?

But aggregated and transformed data means the data is nicely packaged and put together right in a good way, right?

And then we have the vertical axis, which is product internal and use case specific and external and reusable on the top, right?

So the idea is not to say, left is bad and right is good or bottom is bad and top is good, because I think that's what most people think, but it's more about to say, where are we actually at a team, right?

What type of interface are we building and what are we aiming for, right?

And we mainly use this then in discussions with people like developers and architects, for example, to say, or also product owners to say, where are you and where do you need to be and why, right?

Because sometimes architects, product owners, business people have a very different understanding of what they want or what they're aiming for than the developers, for example.

And it's easiest to put it in a picture and say, please position yourself.

Where do you think you are?

What do you think where you should be?

What does it need to get there, right?

Okay, so if we could define the quadrants.

One thing maybe to think about is, Miri already mentioned, is this black and white thinking there.

So people are really, oh yeah, where I have to be directly in the middle of the composition service.

So it's really hard to, or I want to be on the highest top.

It's just put yourself somewhere.

Maybe you're on the cross.

It's totally fine, but it gives direction.

It makes clear where all the things are actually moving somehow and make it also clear for non-technical people what is actually happening.

So when we look at back and forefront and stuff and everything involved there.

Yeah, let's go to the quadrants quickly, Daniel.

So I think you started with the top, no, bottom right now.

Maybe go ahead.

And that we can move it to a composition service, which is more fruitful than just having this technical back end for front end type of thing.

So it's really something to move on.

And to be honest, we started with the two things above.

That was the starting point because we needed for a project because the idea of the project we did was to deliver core services.

So platform data products somehow.

The people were not at that time talking about data products.

So it was called core services.

What happened was over time, we built a lot of composition services and then somebody asked, did we actually reach the goal?

So we had to find something and this was actually the start.

And then Miri came and built this whole diagram or the quadrants out of it.

This is really where it all came from.

Okay, so what would be the definitions for the quadrants then?

Okay, so let's start bottom right, back end for front end.

I think most people know what it is, but basically we expect there's a team.

They have a front end and a back end.

Maybe it's in the same team.

Maybe it's the neighbour team that we know very well.

We build our interface exactly for the front end.

We don't do raw data.

We transform the data exactly in the way the front end needs it.

We design it very nicely so that the front end developers have it very easy.

Nobody else will ever use our API, right?

We use it internally, that's it.

So single purpose, very, very fine, strictly defined and not reusable at all.

Exactly.

And you can make, for example, you can make breaking changes anytime because the front end developer sits right next to it.

You say, hey, I'm making here a breaking change.

Please change.

You may be changing even the front end in the same much request, right?

No problem.

You can do that, right?

Yeah.

Then we have on top of that, the composition service.

So let's go that way.

The composition service is also with aggregated and transformed data.

So very well-defined data, very curated data, but it is designed in a way to be external and reusable, right?

So I need to pay more attention to who wants to use it.

Why do they want to use it?

What do I need to do to make it actually usable for them?

And also I cannot do as much changes, right?

I cannot change it tomorrow and say, well, all my lovely external users, now I have a version three of my API.

And if you don't migrate, version two will be not working anymore tomorrow, right?

I cannot do that, right?

So I have lots of implications I have to take care of if I'm in that space, right?

I cannot just say, well, I change it tomorrow.

I don't care, right?

And that's also something that many people don't get at the beginning, right?

And I have a very funny story of a team that I talked to who actually had a backend for frontend.

That's what they thought, right?

But the product owner decided to put their API in the internal API catalogue because it was there, right?

It was a nice API.

So what happened?

Other teams started using it and they didn't know.

And when they made a breaking change, suddenly three teams dropped them a message saying, hey, you broke your API, why?

We use it.

And they were like, wait, this is our API, you know?

That was actually- Why are you using it?

If you would have talked about it with the IQs, you would have known that someone thinks it's there and others think it's there, right?

So there was a different perception in the team.

And then the left side, maybe Daniel, you can go ahead.

Yeah, and then we have actually on the left side when we start on the low ground, this data link type of thing.

It could be a database API, but it shouldn't.

It's really bringing this raw data up to be used by composition services or even then by the platform data product.

And this platform data product is really meant in type of productisation to really think about in data products to really say, okay, this is what we deliver internally, somehow externally then also, and we make things reusable.

So we can build then composition service out of this platform data products because they provide the real value because this is what we actually want to share with people inside the organisation or even also external because this internal external thing is it's a quite complicated thing there.

Okay, so I do have my take on this for integration platform.

So we'll do that in a moment, but I'm looking at this also from a perspective of domain driven design.

And I'm just trying to find the right image in Vlad Kononov's book, Learning Domain Driven Design, and I think I got it.

So I'm just gonna paste it right here.

So if I look at these layers, this is an overall picture of different types of context mapping within domain driven design, right?

So in context mapping, we have different relationships.

So if I would look at data link, that would be probably either shared kernel or partnership.

So very tight connection between them.

Then if we look at back and forefront, then that would be probably also partnership because there are separate pieces of code connected and non-reusable, etc.

Then composition service would be then probably open host service in that sense.

I have to leave you now.

Have fun and see you all, bye.

Thank you, Daniel.

Thank you for joining us.

You're welcome, you're welcome, bye.

All right.

So correct me if I'm wrong, but I'm looking at this from this particular perspective, that this would be like composition services is our open host service with these published languages that we cater to that are specific use.

And then they are basically conveying a specific functionality, right?

Yeah.

Data products might also land in the part of being an open host service because we don't, in terms of ACLs, we don't really expose them, the ACLs as APIs.

The ACLs are within the software itself, whether we're consuming or providing an API.

So that's a different thing.

And then back and forefront, and it's also, it's a conformism pattern because the front end is conforming to the back end.

Yeah.

Right?

Yeah.

So does that aligns with the thinking for the- Okay.

Totally, yeah.

All right, so- It's a good perspective to look at as well, yeah.

Okay, fair.

All right, so if we can map these things to good, bad designs or example, real world, very real world examples of what we would use.

So let me see, let me have a go at it.

So if I would do a data link, that would be, literally could be a database link, DB link between two databases replicating data.

A data link could be also a batch or an ELT process running somewhere, right?

Because it just moves raw data.

Yes.

ETL, somewhere probably in the data link space as well, but probably closer to the middle of the whole thing because it's acting a little bit as a composed service, a little bit in that direction, but still in the data link part.

Back and forefront, I think that's self-descriptive here.

Composition service, any SaaS solution with an API array externalised, that would be pretty much it.

So any CLI of any tool would be in the composition service, I guess.

Any API of AWS, Azure as products.

Yeah, Salesforce API, Microsoft Dynamics API, these would be all composition services.

Then in that sense, what would be the data products?

Okay, so if we have Salesforce, for example, as in CRM, Salesforce as a platform gives us composition services, but if we implement it in a specific context of our own organisation and start exposing specific data in a productized way from Salesforce, from that organisation, that would be then in the direction of the data products.

Yeah, I see it more in a way like how close is the data still to the raw data, right?

A platform data product would be more, let's say, less data from different sources.

A composition service can also have very different data, right?

A composition service could also have data from Salesforce, but data also from a completely different source, theoretically, right?

So it's more like about where do you get your data from, like how close is the data to each other, right?

If it's a very, I would say, a very bounded context with very, like data is from the same place everywhere, like, right, it's more on the data product side for me, while if we have data that we aggregate, we transform, we take other data that we mix in, right, from somewhere else, that would be more on a composition side.

So it depends a bit on how, where do you get the data from, right?

How restricted are you in the data you present, right?

Okay, I'm gonna counter that because if I look at ecosystem architecture from perspective of domain-driven design, I mean, it's a holy grail of domain-driven design to have a bounded context and the functionalities of a specific subdomain containerised in a singular system.

That's like the holy grail.

The reality of things is that usually a singular domain system implements several bounded contexts, not one, but a few.

So if we look at, again, Salesforce, a CRM system as an example, okay, we have the customer domain, but the moment an opportunity is won, we're going into the order domain, right?

So we're already from that perspective, functional perspective of a business, we're already having at least two bounded contexts in a CRM, right?

So if I'm looking at the distribution of systems and bounded context in an ecosystem, also from a perspective of an integration platform, the data product can be on an API of an integration platform, but the data can originate from multiple systems, right?

Because if I have a order domain, okay, I have some sort of an ERP or order fulfilment system beneath, but part of that data originates from a CRM.

So I combine the two as a singular purpose of a data product, which is not exactly transformed because I don't transform the data on an integration platform, I just merge it as a, join that into a singular, not data model, but a singular instance of a model, right?

So that is then, that could also, from my perspective, be raw data without transformation.

Right, yes.

Depending on how much you do with the data, right?

It also depends a bit, what do you really do with it?

How difficult is it to put it together?

Do you just take the fields and throw them in one, right?

Or do you really do more with it?

I think it's really a fine, it's not so, it's not black and white as well here, right?

Most of the things will probably be somewhere in the middle, right?

Some will be clearly left or right, but most will be somewhere more to the middle, right?

That's also what people always ask.

Do I need to pick one of the quadrants and then I'm there?

And we said, no, you can say I'm more in the middle, I'm more to the edge.

I mean, if I have two consumers, where am I?

Am I already, am I external or am I internal?

I said, well, you can still say we're internal because the second consumer is our neighbour team or whatever, right?

You can still draw your thought there and say, well, we technically have more than one, but it's still like internal, right?

So it's not really about the maximum or I always have to be on one clear end, right?

I can be somewhere in the middle as well.

This is more to keep the conversation going.

And actually one of the reasons why we designed it as well was that we had the training with the customer where the architects were very keen on having the training with the developers because they said, well, they need to learn how to build reusable APIs, right?

And then we talked with the developers and they said, well, I have a back end for front end, I don't care about any reusable API, right?

Very true because it depends on the use case.

And then it's good to pick up this picture and say, well, your architect wants you to build a red or blue thing.

You're telling me you're only building green things.

So where are you really and why?

And what do you need to go there?

Or does it even make sense to go there, right?

It doesn't make sense for every interface to be a composition service or a platform data product, right?

Every quadrant has their strength and their place to be in our opinion, right?

So I really need to know where am I and where do I want to be and where do I have to be and why, right?

It's always the only plausible and correct answer in all cases it depends because we first need to understand the context of things rather than jump into universal truths because those universal truths are not really universal in that sense.

If we just look at the relationships of context mapping in domain-driven design, we can identify that these actually map to the data interface quadrants very nicely.

By the way, if somebody wants to find this lovely diagram that I posted in Draw.io, this is the book I'm referencing it from, that's by Vlad Kononov, Learning Domain-Driven Design.

It's a book a lot easier to digest than the books of Eric Evans, not that they are bad, they're just written in a different language that might be a little bit harder to grasp.

So if you don't have experience with domain-driven design and you're just starting with that, I recommend reading this one first and then going to Eric's books would be a better basis to get the grasp on what Eric Evans is saying in his.

So the relationships are there and if we look and map our relationships and understand those relationships between teams, between systems, we can then have that conversation over quadrants and then everybody will say, well, it depends, what are the use cases?

And that is very helpful in my opinion to have these kinds of conversations because it's all about building those relationships and those relationships, according to Conway's law, trickle from between teams to systems anyway.

So it's always worth having that discussion in that sense of classification, right?

And I think it helps just to get everyone on the same page because mostly people don't talk about the topic.

So everyone has their thing in mind, but nobody pins it down and then it goes to the opposite directions.

And I think the hope, if you talk to companies who want to be, call it API first, call it whatever, API is a product, they hope that people only build the red and blue things, but then teams don't understand why and teams don't understand when this is needed and teams don't, you can't only say, now we're API first, so, right?

We do API as a product now, but then you also need to tell teams why this is necessary and why this makes sense for their case that they're building, right?

If the team says, no, we're building a backend for frontend, then someone has to go there and explain to them why they should write about the composition service or something else than a backend for frontend and why this is the right way to go, right?

So these are the interesting discussions that happen then because people need to get into that and discuss really like, what are we building and why are we building it like that and what implications does it have if we suddenly build something else?

And it's also something we always say, if a team build a backend for frontend for years, they would not magically know how to build a composition service and what applies to that, right?

Absolutely.

Training and enablement and stuff, you cannot just expect them to jump there in every quadrant and know exactly what they're building, especially as we discussed, they're not expert for interfaces, APIs, integration, any of that, right?

They're just a team building a backend or maintaining their database or whatever, right?

So just putting that in a perspective of ecosystem interoperability, I literally was in a situation where a company composed their integration team based on former DBAs, former DBAs and database administrators, and they were expecting them to provide a decent integration platform.

Now, if you look at mindsets of these people, well, no, that's not gonna happen because the mindset of interoperability is persist nothing.

The mindset of a DBA is persist everything.

So what they did, they did basically an MDM solution covered around with Azure functions to feed the data into the MDM and then redistribute the data from the MDM.

That was their integration platform.

Was that anywhere near a composition service?

No, that was all data links, basically, right?

So it is a difficult topic to tackle in terms of skillset and mindset over the design and working on things.

So if, again, another topic that I discussed today

and scheduled for a later stream somewhere in November,

migrating, for example, from Mule platform

as a MuleSoft integration platform to just pure Java,

I mean, okay, the cost of licences are high,

but companies still don't think about the cost of retraining

or rehiring the whole teams, the cost of lost knowledge,

because if they start-

The migration cost.

Oh, the migration cost, yeah, that's another thing.

But there are other implied costs other than the OPEX of licences, and that's the difficult part as well, because if they suddenly drop a low-code integration platform, their developers will go away to a different company to continue doing a low-code platform.

So they will lose all knowledge.

They will have to rehire the whole team.

They'll get probably Java developers or something like that, and they'll have to retrain them in thinking about interoperability, because those Java developers will be set to back-and-forth front-end or data link.

That's just not feasible in that sense.

So, yeah, so that's the difficulty there.

Right, here we have Tom Donker referring other books about DDD.

Yes, we have also Vernon with a red and green book, also a nice read if you're learning DDD.

So, yeah, okay, you know what?

I do have also, somewhere here in the tab, I did some playing around thinking about the quadrants.

I think I showed you that when we chatted about the livestream earlier.

I actually tried to map even-driven architecture and different patterns from even-driven architecture into the quadrants.

I must say mapping async to this is quite a challenge.

At least that's my take of how I would use those certain patterns in terms of various options.

So this, again, depends on what you wanna achieve and why you wanna do it, and those patterns are various, and people understand them also differently.

But just looking at the data link, content-based routing went into the data link straight away, right?

Because in pure EDA, you shouldn't do content-based routing because that introduces additional complexity.

And I was like, hmm, yeah, we're pulling, even sourcing from legacy systems that cannot do events.

That feels like the data link.

I know that I asked Daniel about mapping EDA to the quadrants, and he said he never tried it.

What's your perspective on that?

I think in general, I mean, I think it's great to also bring it more to the architecture and ecosystem perspective, right?

We never did that because we didn't require it, let's be honest.

We develop tools if we need them right now, right?

Of course.

With people, mainly.

So this was really interesting what you brought up.

I never traded myself media, but I think this is a really interesting thing that you came up with, and I really like it because I think it gives it another layer, right, on top of it.

We also discussed other topics, like on an architectural ecosystem level that we never thought of when we designed it the first time, right?

Because we just needed something to discuss with developers and architects.

That was the need we had at the time where we came up with it, right?

So I think- The key difference is that I'm a researcher and I do research, so I ponder on things that I'm not pragmatic in them because I just start thinking about them and then see if they apply to anything practical.

So that's the difference there.

I did a lot of research too, especially during my PhD.

But I think, as I said, most of the times right now we develop things that we really need based on what we discuss with people, right?

We come up with solutions for problems we already see just because this is interesting.

But I think also, I mean, we work on different things, right?

That's also what you see here because I mainly work with teams, right?

I have lots of different- If I would come with that, they would be completely overwhelmed, right?

So just a whole different level of people to discuss, right?

Yeah, this is basically taking Gregor Horst's book, Enterprise Integration Patterns and just throwing it on the quadrants.

Some of those patterns are literally taken from that book.

Yeah.

Others are redefined.

And it just pops up patterns and there are different flavours to pops up.

And we have them, the pops up we have as a broadcast with a rich event, with broadcast with anaemic, multicasts, and waiter pattern, which is a completely different way of broadcasting, right?

And these are all certain types of data movement and application integration that is completely different than traditional synchronous APIs, right?

So that makes quite a difference in thinking.

And then I'll go back to the raw image here.

Then I was pondering on this from a perspective of an enterprise application integration from that ecosystem perspective that I do research on.

And basically, oh, well, maybe I'll shift here.

Basically we have in the research, we have four different architectural styles for interoperability on an ecosystem level.

Ignore the spaghetti architecture because it's just for reference.

That's not an architectural style.

That's a consequence of unmanaged point to point.

So if we're looking at DIQs from a perspective of a system, we're looking from a perspective of point to point in ecosystem styles.

That's basically just client server relationship, right?

But then I tried to map it as event driven.

Broker, yeah, you can do through broker, which is most parts is batch ETL, ELT, but you can do single record processing as well.

It depends how you build that integration flow.

The fun part is when you go into API led architecture, which is an offshoot of a service orientated architecture with three distinct layers.

And this is where the fun part began for me because I looked at the diagram and basically I'm looking like, oh, okay.

I would probably rename the quadrants a little bit for that perspective.

But in API led architecture, I do not see data links at all because I'm on an ecosystem level.

So they're not relevant.

So if I'm looking at this from API led, so this here backend for frontend, this is the exposure of data in certain way.

Okay, so that would be in MuleSoft nomenclature, my experience layer.

In my nomenclature, that's the channel.

So this is the layer that is consumed by the main systems.

Then the data product layer is the access to raw data, the raw services, unfiltered, generic.

So that's my adapter layer or the system layer in MuleSoft, right?

And then the composition service, quite funny enough, is the exact same naming that I use for the middle layer, which is the composition layer.

And we have composition services in there, which is the layer where we take the data products and the raw data from different systems from the adapter layer and create services from them.

So create some sort of generic products that we can offer as reusable services.

And then we offer those reusable services to the channel layer.

And that channel layer is specialised towards a specific consumer.

There is a single API per consumer.

They do not reuse API between one another.

So if I have a Salesforce instance, that Salesforce will be consuming Salesforce channel API.

If I have a SAP, SAP will be consuming SAP channel, etcétera, etcétera, right?

So this is a tailored, specific, non-reusable API.

And that made it very interesting because this is very applicable and a very nice way to explain the layers of API-led architecture and their purpose when designing APIs for people that are not integrators.

Because some people think that, oh, putting that iPaaS, that's an overkill.

That's too much.

I mean, yes, if you put an API-led architecture in a company that has five systems total, that's definitely an overkill.

They don't probably even need an iPaaS.

They could do well with even driven architecture and they'll be fine.

Yes.

But if you have a company, a corporate environment that has a hundred domain systems, good luck doing that point-to-point or EDA without any capacity for transformations and protocol mediation, etcétera, etcétera.

Not feasible at all.

I found it very interesting because I recently talked to some people that said, well, all these API-led, we decided we don't need it.

We go back to point-to-point.

That was something that I already heard, which was very interesting because I thought actually what was missing and that's what you touched before is the mindset shift, right?

That's what you're saying.

You need to shift the mindset.

Even if you want to do something like that, you need to completely understand that's a different mindset.

And I think that some companies that don't really manage to do this mindset shift are actually going back because it costs them a lot of money and they don't see the benefits.

So did you already hear about something like that or can you imagine that as well?

Because I heard that and I was really surprised that the mindset shift is so difficult for some people, right?

I'm not surprised because that's literally the consequence of Conway's law.

Yeah.

Literally.

Yeah, exactly.

I'm not surprised by this to the extent that this was literally the problem of, in a lot of cases, of the early adoptions of ESBs.

Yes.

Because companies think they can solve their interoperability problems by throwing technology at them.

Of course, always.

Yeah.

That's not the case.

Technology doesn't solve the problems.

If you just throw technology at it without the underlying organisational change with it, the technology will fail.

No matter how good that technology is.

And it's not the fault of the technology because the technology without proper implementation and governance will solve no problems.

That's just the case it is.

That's why we don't use the term ESB anymore in general conversation about interoperability because too many companies have burned on ESBs, burned a lot of money, a lot of effort with very little return on investment because they just did technology without changing the way they work, without changing the processes, without changing the governance.

And they expected magical miracles.

This is one of the problems we face as integration architects that we need to go in and have a conversation about the organisation rather than technology.

Yeah.

Daniel and me wrote actually an article on the code centric block, which is when your API platform lacks the desired impact, because that's exactly what we see, right?

When we talk to customers, they would say, well, we bought the tool, we're done.

And then they realise, oh no, we're not.

And it's not working as expected, but why, right?

And that's exactly what you're saying.

Most people think that technology is enough, but as you stated at the beginning, or we stated all at the beginning, the technical aspect is not the most important one.

I mean, you can solve that clearly, but the other aspects, right?

The aspects like how do we communicate?

How do we build up our teams?

How do we organise governance?

All these things.

How do we shift people's mindset from we're just building our back end for front end and we don't care about anything else, right?

I had in a training, a guy who said, well, I don't care if anyone likes my APIs.

I built them the way I want them.

And if nobody likes them, that's it.

They're like, yeah, well, you can think like that, but if your company wants to be like design APIs as a product and be API first, you need to change your mindset.

And it's very difficult to reach these people and change their mindset, right?

You need, it needs a lots of time.

It needs special effort.

You can't just put a tool there and assume people will love it and know what to do with it and how it works and why they need it, right?

It's about applying the value, showing the value of these tools and where they bring help and value to the conversation.

That's one of the biggest challenges there, because a lot of the times, if we look at companies that are not digital, right?

They see IT as just a syphon of cost.

It's just draining money, right?

Explaining this in these kinds of companies is already a nightmarish challenge.

And then while you can still justify the ownership and the alignment here on the business around the main systems that have front-ends and people use directly, this is easy.

But if you try to justify that for an integration platform where that integration platform does not have a direct impact on the business, well, doesn't, it does have a direct impact on the business.

But business does not see that because they don't see a front-end for an integration platform.

They don't use an integration platform.

They don't know they're using the integration platform.

So for them, an integration platform is just a cost.

It's just infrastructure.

And from that perspective, when we start treating interoperability as infrastructure, well, we don't design for it.

We don't think about it.

We don't care about it.

We don't design our domain systems for it.

And it gives, oh, so many problems.

The moment we start thinking of an integration platform and our interoperability capabilities as the heart pumping the blood of the business, the shift becomes something real.

And then the understanding is brought in.

But that's, to achieve that, that's very difficult.

That maturity happens in organisations that are very technically driven because they have that understanding.

So telco, that's one industry where this is just the golden standard.

Sometimes happens in banking, not always.

I recently saw a implementation of a MuleSoft platform in a bank.

And I was surprised because they even thought about proper domain partitioning over each layer.

I was like, I need to talk to the architect that figured this out because that's just the most mature implementation of an API-led architecture I have saw in my life.

And I saw many, I saw really plenty of implementations of API-led.

None of them were this mature.

I was literally like, give me the person that designed this, that figured this out because I wanna know how he achieved that in an organisation.

I don't care about the technical part because I know how to do this properly.

But to convince an organisation to follow that and go through with that, it's like, tell me how.

I wanna know.

It differs from company to company.

It's gonna be, yeah, we're gonna tell the same story over and over again and try to explain interoperability.

It will land or will not land.

It depends on the, oh, on so many aspects.

The first live stream on Loosely Coupled we talked, I talked with Fran Mendes about adoption of EDA in organisations.

Like I said in our conversation just before the stream, the conversation shifted to mental health because mental health of your employees in your IT of the organisation impacts the adoption of architecture.

If those people do not feel psychologically safe, they'll be resistant to change.

So I think that translates very well to the people that come to your trainings.

If they're not psychologically safe, they are not able to learn.

So they come out of the trainings being opinionated and saying that they didn't learn anything.

Yeah, I think you always have one or two of those.

Usually most people want to learn, that's my experience.

But also I think sometimes it's also the underestimated pressure on people.

What I also tell a lot of times, and that's also a real story, a developer that I work with who needed to do an API, she told me, if I don't finish this until tomorrow, I'm dead.

That's a quote, you know?

And if you're in an enterprise context where people are so much under pressure that they need to finish something in no time, what type of good solutions do you expect, right?

I mean- Oh yeah.

That's always the problem because people are so much under pressure to finish stuff in no time with no experience for it.

So they're trying to get it done fast.

And the faster people work, the less time they have to shift their mindset or to learn something new because they're just trying to get it finished as quickly as possible.

It's just lots of pressure on them.

So I think this is also an important aspect of that mindset.

People need time to change their mindset.

They won't do it overnight.

That's a horrendous situation to be in.

If I need to just finish things and output things, this will never be quality.

This will be just done just to be done.

That's like, I find that this is quite often in certain organisations, especially in certain consulting organisations, that's quite often it's, we need to output.

It doesn't matter if it's shitty, as long as the client signs off, we're good.

And that contradicts my standards.

And I literally had to refuse signing off on things and releasing them to the client because they were not up to par.

And I didn't care that we're gonna lose money on that.

Somebody screwed up along the way.

We cannot produce quality.

I'm not gonna sign it with my name because that says something about me.

I have the moral integrity to say no, but a lot of people will just sign it because they're scared about their job, their position.

They have mortgages.

They have families they need to feed.

Oh, so many things.

And these are all impacts on everything, right?

And it's a difficult puzzle to see, especially if you're in certain places in an organisation, you don't see that at all.

In the end, we are all human and we have our troubles and this will impact the business one way or another.

Of course.

In that way, it was good because I was as an external in a good position.

So I said, well, I can talk to your product owner.

I have nothing to do with him or your product manager.

I will never see this person again and I will tell them why you won't finish tomorrow.

No problem, right?

Yeah.

And if you have a certain knowledge, you can also argue, right?

But if you're a developer who never did that before, who doesn't know how long it takes, who doesn't know why it takes longer than expected, it's very difficult to explain yourself, right?

You just don't have the arguments.

And that's what I think what's really great about like the enablement aspect, right?

If I'm in an enabling team, like according to team topologies, if anyone knows that I can easily step in and say, well, dear manager of this person, nice that you want to see tomorrow, but you know, we have to do all these steps and they are complicated because, and that's why it will need time, right?

No matter how, when your deadline is tomorrow, I'm sorry, but we won't do that, right?

So I think if you have that layer, you can at least support people in finding the right arguments and give them the arguments that they need to convince someone that they can't be done tomorrow, but alone they are lost, right?

That's my experience because- Absolutely, yes.

Where do you get the arguments from if you don't know them or you never use them, right?

And you're not like an expert on these things, where do you get them from?

Exactly, and then if you think of it from even the perspective of cognitive load, which is something team topologies touches upon very strongly, think about how little germane cognitive load those people have when they, what's that, intrinsic load?

Yeah, extraneous and intrinsic, right?

They're the other two.

The intrinsic load is so high on them because their own emotions, their own psychological safety, the pressure that's put on them, the stress just completely blocks their capacity to think in that sense, right?

And if we put it in the way that often management sees that, management often sees this lovely triangle, right?

Which is a fake, this is not the actual thing.

It's time, cost, quality.

No, that's not how it is.

You can only pick two of them, right?

That's what they say, right?

Yeah, exactly, that's the story behind it if someone doesn't know, right?

But this is the actual thing.

It's cost, time and scope, which impact quality.

If we don't have time, we close this up.

We can do it also at low cost, but the scope will, well, be the same.

The quality will be squished, will be bad.

So if that's the case, it's gonna be always a problem.

We have to keep the quality the same.

We have to adjust, when we change one, we have to adjust some others, right?

To see if that keeps the quality.

The quality should be looking at maintaining the quality.

And if we squish the time to so little with remaining scope, and also try to compress the cost not to add to it, well, impossible to achieve the same quality.

Impossible to achieve something that is more than the exposition of a relational database.

That works today and maybe not tomorrow, right?

Exactly, it's not gonna be reusable.

It's not gonna be anything that will bring business, that will bring further development of the business, right?

It will just serve the purpose for now.

It's a workaround, it's a tactical choice.

And next time someone needs it, they will do the same again, build it again, and again, and again.

And then we go into the problem of API federation, API management federation, and repeated implementations of APIs that we have 10 APIs do exactly the same thing because they didn't even know that these things exist because they didn't have time to discover those.

They didn't have time to think about them.

They didn't have time to ask anybody.

They were just like, you need to deliver.

Okay, boom.

API, a 10th API that does exactly the same thing that already the nine other teams figured out and did the same because they were pressured into.

And two are maybe not used anymore, but nobody knows about them.

So they're still there, right?

But they're still burning air in the server room and they still cost.

Yeah.

And they might still be a security risk, right?

Because nobody remembers that they're there.

Oh yeah, yeah, definitely.

That's 100%, that's already.

So this way we build technical depth, we build security risks, we build low IT maturity, we contribute to, what's that?

Not employee retention, the other way around, churn?

No, that's client churn.

What's the word?

Just employees leaving the company, right?

So we lose valuable knowledge about our ecosystem.

There's so many downsides to this kind of behaviour, but it's a normal behaviour in a lot of companies.

Well, normal is a bad word.

Normalised behaviour in so many companies.

And that's horrendous in that sense.

That's a huge problem.

And then, I mean, there are other things related to that that I just had to think of when we discussed it.

For example, the fact that people integrate an API and then their developer's leaving and after half a year it stops working and then they're complaining.

And you're like, well, I mean, you need to maintain this.

And if you don't have the credentials anymore or they run out, what should the provider do, right?

I mean, you have to know how to use the API and how you integrated it.

If you don't have any developer anymore, and that's what I see also very often, all those things, APIs and also API consumption are handled as a project.

When they're done, all developers leave and it will work forever.

We never touch it, it will work forever.

And half a year later, a year later, the credentials run out or a certificate runs out or you don't know what.

And then there's a big disaster because nobody knows anymore, right?

That's very true.

Like Eric here says, it's like a shower.

We expect nice warm water, but don't know or want to understand how it gets there.

It's a problem.

I had a very clever thought on the APIs.

Oh yeah, that's one of the lowest software architecture in general.

Software architecture and trade-off analysis is not something we do once, it's a iterative effort.

And this goes to maintaining APIs, this goes to evaluating APIs.

Are they still bringing us value?

Are they still used?

Are they still secure?

Are they still providing what they should be providing or should they be replaced, changed, modified, whatever that may be.

It's an iterative effort because everything we do is an iterative effort.

And if we look at IT that was 20 years ago, that wasn't changing that fast.

Nowadays, everything is changing a lot faster.

20 years ago, we didn't live in a distributed world.

We had data centres for each company that had the tech, perfect, fantastic, everything is there, it's running.

Now, everything is everywhere.

Now, everything is moving faster than we can catch it.

If we look at the problems of architecture and applying architecture to specific topics, the moment I design something, it's already irrelevant.

It will serve a purpose, but it will be not as good as the actual need is because the need already drifted away.

It's called the model drift.

That's why concepts like residuality theory from Barry O'Reilly gained so much traction because they exactly address the problem of the model drift and exactly address the problem of this, that anything we model is already out of date.

And it's a huge problem in that sense.

I also listened to a very good keynote on actually complexity.

That was what it was about in a conference last year.

And the actual take was, or what I liked most that afterwards in a conference, everybody discussed the topic that how can we really reduce complexity?

Because the theory was that everyone believes that now that there is AI, it will reduce the complexity.

But in reality, if we look at all the last years, every new thing that came up to reduce complexity increased the speed, which again increased the complexity.

So that was the theory.

And I liked that a lot because if you talk to the people on a conference that was really resonating with a lot of people because they said, yeah, it got very complex and it even gets more complex.

And because it's getting faster, this means we're trying to reduce complexity by making things faster, which again introduces complexity.

It's horrendous.

And that's what was troubling me because it was a good discussion on the conference as well.

But this again touches Tesla's law, right?

If we look at the problem domain, there is an inherent irreducible complexity.

We cannot go around it.

We need to address it.

And then we go to UX, fully blown.

And I love this book.

So I'm just gonna throw in another lovely slide from my training deck.

Complexity is not bad.

It's confusion that's bad.

So long live well-managed complexity.

And this is Don Norman, the designer of Everyday Things.

This has nothing to do with IT per se.

It's about design principles.

Yes, I actually have that book.

I mean, I did my PhD in human computing.

Obviously.

Don Norman is a very important person you need to know, right?

Especially if you're doing front-end and you're doing UX, absolutely mandatory read.

But it trickles down to everything.

It's not only relevant for user experience.

It's relevant for architecture.

It's relevant for interoperability.

We're here not to reduce complexity because the complexity is already, we know it's irreducible.

We're about to manage complexity.

So if we're looking at interoperability, if we do point to point at a scale of 100 domain systems in the corporate environment, that's adding complexity to the mix because that's not readable.

That's spaghetti architecture.

If we add an integration platform to the mix and streamline everything through an integration platform with proper abstraction layers, we're managing that complexity because we add monitoring and auditability to it and observability.

We can actually understand what relates to what because we see those relationships through different elements that are in the platform.

And by adding the abstraction layers, we can actually manage the change and manage dependencies better.

So it's a very hard problem to explain because people still live in the notion that we can reduce complexity forever.

It's a fairy tale.

It doesn't exist.

We should, we just shifted around in the end, right?

That's what

Yeah. It's a matter of who's going to take that complexity and solve it.

I also like Eric's statement.

He just wrote that maybe the problem is that application is still in the age of API.

I think this is a whole another thing.

Like, discuss with people the definition of what an API is and have fun, really.

I don't know if you did that already.

But- Several times.

We did that with clients and even if you are there for a long time, believe me, not everybody is on the same page.

What an API is, even if you discussed it 100 times before, it's always a good discussion if you want to like, you know.

And companies that offer products around APIs, they don't help.

And I'm pointing towards MuleSoft right now and the bullshit that marketing from MuleSoft pressed onto us and it's stick with people.

They started naming whole integration applications APIs.

No, they're not APIs, they're applications.

They have APIs.

It was just a nightmare every single time.

It's like, no, it's not a system API.

It's a system application representing a specific system with a standardised API that is a REST API, blah, blah, blah.

And then people have the notion, oh, API is just a, it's REST. No.

No.

Exactly, that's one of the perceptions.

Yeah, SOAP is an API.

You can have an API implemented with JMS, no problem.

You can have, JDBC is a protocol for an API of a database.

My tongue is, my ears are an API, if you want to talk to me.

If you consider me a programme, right?

Or an application.

It's difficult for people to comprehend that just throwing around acronyms like API doesn't contribute to anything.

It's a very difficult aspect there.

Yeah, I have another good one, for example, SAP API management, the list where you can see the proxies, it says APIs.

What?

Yeah.

Some people believe the proxy is the API, and I'm like, well, no, it's a proxy.

Because it really, it says APIs as the name of the top.

So in the UI, so people see these are the APIs, I mean, clearly, right?

No.

So, you know, you have to be careful what you name API because it's misused a lot, I agree, mainly in Python, but also by other people, so.

If you put it this way, if we talk about API management, nothing on the API management layer, well, precisely API gateway layer, nearly nothing is an API.

All of these are proxies.

So, to be very, very rigid and specific, some of them may be APIs if there is actual logic involved and implementation over the API gateway.

So for example, if the API gateway offers protocol mediation, you can consider that being an API because it has a specific function.

But this is being very rigid.

It's still a proxy.

But this is where things get lost because we have so many different types of appliances, types of applications that do things technically, and everybody has their own marketing, nomenclature.

Every part of the industry has its own jargon.

Greatest example, a few streams back, we were talking about data mesh.

Here in the studio, there were two data architects, and we really got lost in the lingo from time to time, and that created hilarious misunderstandings.

We were talking about contracts, and I had a completely different notion of a contract than my guests in the live stream.

It's completely different.

If I look at a feedback from DDD Europe when I ran a workshop this year, we had a feedback that, oh, this was a missed opportunity because you didn't talk about data mesh when you were talking about interoperability.

It's like, sorry, what?

We were talking about ETL batch and ELT.

That's basically the key of a broker architecture.

That's the most common use case for a broker architecture.

Again, lingo.

It's not that we didn't talk about it.

We did, but somebody didn't know the terms and words that are used by integration architects.

They knew the words that were used by data architects, and if you say application integration to a data architect, they don't understand that this is data movement.

That's a different term.

And they knew that.

Application integration and data integration, there we have the next topic on how to define it and what that means.

I think it's already too late to discuss this today.

What I can do is drop an article because I literally wrote, one of my first articles is the differentiation between data integration and application integration.

But still, you need to explain it to a lot of people and still a lot of people don't get it, right?

The same with what is an API.

As I said, you can always start a discussion and see where it leads to, but you will see that if you usually start a discussion, people are not on the same page, no matter where you try it, right?

In any company, you can usually try.

And if you ask what is an API, people will disagree with each other.

If you're in a room with multiple people, it's pretty, you can be pretty sure.

And it's really interesting to watch and see.

Yes.

And from my perspective as an integration architect, this is the role of an architect, any architect, not only the integration architect, to sit down with those people and establish a common dictionary.

Yes.

This is the most important part of the role when you come into a client and start working with clients.

To just, first of all, learn their lingo and then check if everybody understands it the same way.

Because 99% of the times, they don't.

So it's a matter of going there, understanding, looking where the discrepancies are and start aligning people with one another, even using their own nomenclature, not using the actual proper terms.

I don't care about the proper terms when I'm in a client.

They can use their terms.

As long as everybody understands those terms the same way, I can make myself a translation table and I'll be fine.

Yeah, in our last project, the first thing we did was a glossary because everybody was talking about things and nobody was talking about the same thing.

So it was like, well, we need a glossary.

So, oh, depressing.

What's depressing?

Hopefully not our conversation.

Rather the problems we're discussing that people are facing or us as architects are facing.

I guess to sum it up, I think that's also a good point to sum it up.

I think my perception is most people think APIs are easy and in reality, they're not.

No, they're absolutely not.

There's a lot more to it.

There are various angles we can take.

The answer is always, it depends.

Yes, the consultant answer, the typical consultant answer, right?

It depends.

Yes, it depends, but it's about explaining, depends on what and what we want to achieve and having that honest conversation, cross layers from the business to implementation.

What do we want to achieve?

And then pick the- Why are we doing this?

Why?

Yes, to have the rationale, to have the why.

And then from that, we pick the tools that are suited for the job, not just implement an API.

We implement that with intent.

Why, what, and who is involved?

These are the most important things to figure out.

Pretty much.

All right, to end it off, a few announcements before we switch off completely.

So for those who still are with us, hopefully a few people, this time around, it's very interesting that we have another live stream so close by because it's literally in two days and it's going to be a very special edition.

You'll learn why when you join on Saturday.

I'm going to be having Mark Richards on the live stream and we're going to be talking about the human condition, the problems, exactly what we're just ended on a note here, the different problems that architects need to navigate from the human perspective, not from the technical perspective, not from architecture.

We're not going to jump into microservice sagas.

We're going to talk about the human condition.

So on Saturday, 8 p.m. Central European summertime, Mark Richards and I, we're going to have a nice conversation.

And if you're new to the stream, you can scan any of those QR codes, go to bridgingthegap.com, which is the open source site where I, with my colleagues from Bridging the Gap, write articles about enterprise application integration and integration architecture.

You can subscribe to Substack, although I neglected that one a little bit recently, so I need to get back to it.

And of course, subscribe to the YouTube channel to get notified about the upcoming streams.

All the streams are scheduled both on LinkedIn as events and on YouTube.

So if you want to be notified about these, just hit subscribe.

And I think that's the bell icon somewhere there to get the notifications or something like that.

Not really that well-versed in YouTube, to be honest.

So that's it for the record.

Thank you, Daniel, for joining.

Hope you're having fun with your kids.

And- I hope they're already sleeping.

Hopefully, right?

Yeah.

Let's hope for it.

Let's hope for it.

I guess sometimes it takes time.

I mean, I spent often more than two hours trying to put them to sleep and- That's why you say, let's hope.

Let's hope, let's hope.

Let's hope that Daniel has a peaceful end of the day with the kids sleeping.

And Mirjam, thank you so much for joining and having this discussion.

It was amazing to go through data interface quadrants.

It's an interesting way of explaining APIs.

And I think this would be very useful for every consultant to learn if they do any type of interoperability to be able to have that conversation with their clients just to align and put things into perspective so that we avoid those crazy wonky definitions of APIs that could be disastrous later on.

Thank you everybody for joining.