Platform thinking: API products, tooling and metrics feat. Daniel Kocot of codecentric AG

Show Notes

This week on the API Intersection podcast, we interviewed Daniel Kocot, Head of API Experience and Operations at Codecentric AG. Codecentric AG is a leader in agile software development and innovative technologies in Germany. 

Daniel's job is to get his customers to answer the question, "why are we thinking in APIs?" He aims to get them to shift their mindset to specialized tools, treating your APIs as products and understanding the end goal that one's trying to achieve with the desire to design a bunch of APIs. 

_____
To subscribe to the podcast, visit https://stoplight.io/podcast

--- API Intersection Podcast listeners are invited to sign up for Stoplight and save up to $650! Use code INTERSECTION10 to get 10% off a new subscription to Stoplight Platform Starter or Pro.

Offer good for annual or monthly payment option for first-time subscribers. 10% off an annual plan ($650 savings for Pro and $94.80 for Starter) or 10% off your first month ($9.99 for Starter and $39 for Pro).

What is API Intersection?

Building a successful API requires more than just coding.

It starts with collaborative design, focuses on creating a great developer experience, and ends with getting your company on board, maintaining consistency, and maximizing your API’s profitability.

In the API Intersection, you’ll learn from experienced API practitioners who transformed their organizations, and get tangible advice to build quality APIs with collaborative API-first design.

Jason Harmon brings over a decade of industry-recognized REST API experience to discuss topics around API design, governance, identity/auth versioning, and more.

They’ll answer listener questions, and discuss best practices on API design (definition, modeling, grammar), Governance (multi-team design, reviewing new API’s), Platform Transformation (culture, internal education, versioning) and more.

They’ll also chat with experienced API practitioners from a wide array of industries to draw out practical takeaways and insights you can use.

Have a question for the podcast? DM us or tag us on Twitter at @stoplightio.

API Intersection
Podcast listeners are invited to sign up

for Stoplight and save up to $650.

Use the code INTERSECTION10 to get 10% off
a new subscription to Stoplight Platform

Starter or Pro.

Take a look at this episode's description
for more details.

I'm Jason Harmon
and this is API Intersection,

where you'll get insights from experienced
API practitioners to learn best

practices on things
like API design, governance,

identity, versioning and more.

Welcome back to API Intersection.

We’ve got a...

I don’t know, I always say this.
I got to stop saying

I've got an interesting new angle today,
but I don't know.

I guess, you know,
we have an interesting set of guests.

There's always something different
in the API world. So

today's guest, Daniel Kocot- Daniel
did I say your name, right?

Yeah, it fits, actually.

So it's the English pronunciation,
so it's right.

Well how do I say it right?

“Code-Zot”, Kocot, Okay.

The “c” becomes a “z” actually,
so it's it's quite complicated.

Got it.

All right.

Well, full disclosure, it's been a while
since we've recorded I'm out of sorts.

This is usually what I ask before.

At any rate, Daniel's
a Head of API Experience and Operations

at codecentric AG.

They do sort of consulting work and

his gig within
this is kind of around the API practice.

So really interesting to kind of,

you know, we usually talk to folks who are
sort of building their own platform

and here it's sort of someone who's going
in and looking at different companies.

I think give us kind of a different look
at this thing that's really interesting.

So, Daniel,
thanks for being with us today.

Thanks for the invitation.

Jason Yeah, absolutely.

So I tried to give a lousy introduction
in there with your name

mispronounced and everything.

Wants to give us a better one.

What do you do it? I could do it.

I can do it.

So my name is Daniel Kocot, I’m
working for codecentric AG in Germany,

we are a service provider company
building a lot of software stuff

actually, and

I'm working in the in the API scene
since nearly 2018.

Also did a lot of integration
work ahead actually.

So starting with Atlassian at codecentric

and and then moved on to more
the integration stuff.

So there's the green field somewhere.

So just moving on
and now I'm here talking about

all the API stuff we were doing
with customers in Germany actually,

and that even in
sometimes in Europe actually.

So we have some customers,
both of Europe, around.

So I sort of assume,
but I suppose I should ask like

kind of how big are the customers
you're typically working with?

Actually,

they have any size from start up
to to really big enterprise.

So that there's there's actually
no no niche.

We are not covering actually talking
about API stuff actually in this case.

So I work with everyone
from small companies of to two companies

where nearly 10,000 people
were working actually

very cool.

So I think a theme on API
intersection here has been,

you know, kind of trying to find
what are the things that work

regardless of scale
and regardless of industry,

like just in the practice
of doing APIs and certainly, you know,

I haven't been toward design,
but there's a lot of other aspects.

But I think what's more interesting
in chatting with you before a little bit

is like what's what tends to always be
the thing that's not working well.

Like what are the things that you see that

that always seem to be kind of a bad path
that people are going down?

Yeah, actually there is this

there, this misunderstanding
actually of, of API first code first.

So there there is a lot of discussions
actually starting because code

it comes from not normally
from from the bottom up approach.

So we we working with developers
all the time and doing things

and it's really hard for,
for a lot of folks out there to understand

what is the purpose of API.

First indifference to code for us
and all the stuff and what we see working

with program leads and all the stuff
around or people around is

that they are lacking a lot of strategy,
vision and, and all the stuff.

So they're there's always this
some kind of waterfall thing

still there
and how we we do this because it's needed

in the industry
we should do this or we are forced to.

This is what we also hear
a lot of times now in these days and it's

yeah there the actually that there's
a lot of misconceptions around

this API field so it's not really
seeing the the benefits out of it

it's just more forcing somebody into it

and really have to to do two things and

not, not

really have to exchange around
or anything like that.

So it's really everybody's
working on their own right now.

So there is not this API economy
or something like that.

And in my opinion, yeah,
I mean it's interesting that, you know,

as much as I'm kind of in the business
of APIs and it's, you know, business

is good in the sense that everybody
seems to be building something these days.

I think what I'm kind of hearing from your

description there is like sometimes

there's a kind of, why are you doing this
in the first place, Right?

Yeah, yeah.

This is
is this always actually the question?

I talk when I talk with people.

I ask them actually, what is the purpose?

Why you want to be in this API world?

What is you, what is your actually
your goal to, to move on

and how do you want to achieve that? And

sometimes
I always also ask the question is

there were further attempts to do so

and sometimes you get a reaction to this.

Now, we started some initiative
some time ago and it doesn't really

it didn't really work out.

So this is something
I see is actually a lot

here in the region so far.

I guess, you know,
we hear that a lot of stuff by, too.

And I'm curious from your perspective,
like when when people have gone

and tried something and they say it
didn't work, what what do you think it is

that that most commonly like doesn't work
or where their expectations weren't met?

I think sometimes they

they want you to have this fast track.

So I think about building APIs
and it has to be that fast

that that that you did too
that you get so much speed on it

but they don't really think about what
what's behind that

that you need governance
and all the stuff really real right

from the start of saying okay I have to to
think about how should my API look like.

So building things around spectral
and all the stuff, really

knowing, validation
and all the things behind that.

So also getting into the mode.

Yeah.

Of really cutting the API

definition from the rest of the of Yeah.

Of the service actually

because what, what what I see is a lot
having this bundled thing

so the services always bundled
with with the API definition

sometimes the API definition less direct
directly by the code and all the stuff.

So it's it's really something
to to, to get rid of.

And this is when it
not it's not getting faster.

They always say oh it's, it's
it makes us slower.

We have to think about in a different way
and what I think

what a lot of people are also lacking
is communication to the consumers.

Or sometimes they assume things that

the consumers
might need actually out there. Or

the really bad thing
is that sometimes they don't really know

the consumers of the API,
so they're just building things.

And when you ask them what is the purpose?

Who are you reaching out for?

That there is nothing really available.

So it's really this thing,
Oh, I'm thinking for the user, but I

but I shouldn't do this
because I'm not a user.

Actually, this is something I always
point out when I want to have slide

available
to really move back from this thinking,

to be the user of of the API actually,

so that you have to really to interact
with others around that.

Yeah, it's,

it's funny I feel like in some ways
this is first of all I wanted to clarify

you mentioned the API specification
or definition.

I assume you're talking about kind of open
APIs is what you typically expect

to see, right? Okay.

The that I think

one that you touched on a bunch of things,
there's like we can tear this apart.

So the first one is this preconceived

notion that do APIs go fast, right?

Like the simple equation that you're well,
so we just tell everyone to build

stuff and APIs will be faster,
more innovative like that, right?

And then the reality, as you point out, is
you could be

if you do a whole series of things
in terms of really thinking

about designing your whole platform,
not about what is the thing,

you know, designing parameters
and whatever, right?

So I mean, I think what you're
kind of getting at here

is to some extent, though, is that there's
kind of kind of got to be a strategy

as opposed to just going and doing stuff.

But I'm curious from your perspective,
like how you think about

breaking down strategy
because that's kind of a big thing.

There's a lot of moving parts
to sort of doing this stuff.

Well,

yeah, this is actually really complicated.

What I do with customers is really,
Yeah, I put this strategy on a mind map

actually all the time
to really to really see what what are the,

the things we, we have to cover
because there is no real blueprint

a print for, for, for the strategy
kind of thing

because it really depends on your needs,
on your business and all the stuff.

And this is what a lot of customers
actually are always asking for.

Are there any blueprints out there
for strategy

or for validation and all the stuff? No.

What we always can really tell is
there is no blueprint

because we really have to
look at use cases at

get the whole industry you're working in.

Maybe there are initiatives
already available by by others

so that you can really take part in
and it's really totally different.

So that's why I'm always using this
my map to, to really make sure

that I don't miss a thing, actually,
because talking about strategy is

there are so many points on that.

So talking about API integration
and interaction patterns

and all the stuff, it's one part you have
to to look at security and all the stuff.

So it's a lot of things around you.

You really have to not even to focus, but,
but you have to be aware of

actually when you when you,
when you build APIs in this case

and this is what what

we have to think about in this
in this case, actually.

Yeah.

Yeah that's that's interesting.

I mean, I always tell
folks like at stop by at our

you know, some of our biggest customers
make things like beer and electrical parts

like how on earth could I look
at their two different businesses

and say that there's much in common
strategically in terms of what

both their sort of customer needs
are, their integration needs,

you know, like just

all the moving parts of those businesses
are fundamentally different,

much less if you go to like
some SAS based Web product, right?

So the breadth of kind of

because APIs are basically everything now,

you can't say like what is the playbook
to build a great platform?

Well, what kind of platform
are you building, right?

Like that is to say what kind of business
are you in, Right?

And how does it work?
And they're all different.

So I hear you on that one.

I think one one piece that a lot of people
seem to get hung up on early

in this thinking through strategy is like,
okay,

what's the thing that I go by that solves
all this for me, right?

Can I just go buy a thing, push the button
and it works.

Like I'm curious
to hear from your perspective,

but does tooling
expectations tend to look like

that?

Actually, it's really in this space,
really thinking about I will find a tool

that will cover
all because the industry tells me so.

Everybody has this full lifecycle
type of thing

and for one presentation
I really blow it off and say, okay,

what really does full lifecycle
API management mean?

When we look at all the things we did
with customers

and actually there is no solution
because there there are so many issues

actually there
and there is not this big thing.

And I think it would also be good
to have one big kind of software monolith

or something like that that would cover
all the needs we have because again,

there is no real blueprint
also for software.

Maybe somebody needs an integration
platform

apart from all the API stuff,
there are others.

They don't need such a thing, so they do
things differently and all the stuff.

So they are looking more into this API
and gateways stuff and things around.

And there are a lot of people actually

that I talk with that
that have really discovery problems.

So more some kind of portal.

Maybe they need some kind of gateway
maybe to have something available

and it's possible
to move to things to, to another level.

So there are so many different aspects
around this tooling type of thing.

And even when when we look at things that
you provide from from the side of supply

actually with, with the supplied studio,
which which helps a lot of people

to really understand
how to, to build an API with move to form

editor type of thing, which we use a lot

with customers actually, because normally

the developers we work with at the moment

are not able to write open API directly

and you shouldn't in my opinion,
because it's, it's just some kind of

specification
written down in the YAML or JS and file.

So there is a need of having this editor
type of thing

just to put things there
and develop things over time.

And maybe

you have some kind of standard standards
available that you just can reference to

and say, okay,

we have some kind of understanding
for our own messages and all the stuff.

So to make it really, really available.

So but it's also not depending
on having Stoplight Studio

thinking about having specific models
has nothing to do with with tooling again.

So so there there's a lot of again
misconceptions again

so everybody is talking about this
and a lot of people see them

when we talk in in conversations

with with customers or prospects of us

that there are actually other needs
they have to cover.

So looking more into this developer
experience

type of thing,
which for me it's it's again,

sometimes it's just password
blowing things that are that are around.

So it's an API
first developer experience oriented.

Yeah it's it's something
that you can't really really grip

by by your hands and say okay this is this
is what what the what is meant by that.

So it's really always
depending on, on the situation we are in.

And so, so so we have to cover in
a consultancy so many needs actually and

yeah, to, to, to,

to choose to write the right thing
at the right time.

So what I normally do with projects
is that I totally drop

off the conversations about API gateways

so the customers start
really with building APIs

and then when they have a bunch of,

they can think about,
Oh, what we need in this

or do we have something right
available at, at the organization

or something like that?

And then thinking to the next steps,
I actually so this,

this is really approach we did with
customers which really worked out because

having this kind of software available,
there's always this thing

we have to do to do it with this
because we bought it

and we have a subscription running,
we need it.

And it's really

yeah, sometimes also annoying, Dan to
to see, Oh, this is not possible.

We did this with another project
that worked quite well,

but in this case we have to do things
because all the tools we have applicable

and are

possible to do to you to reuse things
you might

did earlier some somehow.

Yeah.

That reminds me of a place
I worked once before

where there was a lot of platform
strategy stuff going on and

I was kind of getting up to speed in there
and hey, there's this huge group

that's, you know, we're getting together
and talking about which API gateway

we should be using as a standard across
all the divisions.

Do you want to get involved and help sort
that one out? And

how long have they been meeting?

Like a year?

No, I'm not interested in that.

I'm going to go work upstream from that
and that'll sort itself out later when

we look at it differently. Right.

But I like to that you kind of touched on

that a lot of companies are learning

what to do from kind of the

Gartner
sort of slap on as as the acronym goes,

the full lifecycle
API management approach.

You know, I recently wrote a piece
kind of talking about this that

in what world would you set

the expectation that you should buy
One thing that does everything?

And by the way,
this is for everything in the world now,

everything has an API, so

you want to buy the one piece of software
that does all all parts of development

for all things in the world,
the all singing, all dancing like sure,

I'm sure it looks great to investors,
but it's a naive notion, right?

And it's top like too.

I mean, we get this kind of, well, how
do you do all the things we say we done?

You know, we help you design good stuff.

And to your point,
you don't have to have a three day

training class on open API
for hundreds of developers.

Like they'll just produce
a good stack and it's fine.

Caveat
by the way, here, I didn't put Daniel

up to mentioning stoplight or Spectral,
so I have to say that

that's not what the show is for. It

at any rate.

Yeah, I think that kind of looking at all
that there's so many other things

besides the gateway
controlling access to something

and for me at least,
and I think you're saying

the same thing, is that upstream
from that, all the things that you did

before you developed the API,
why should we do this thing?

What does it do for our business?

What is it called?

What if customers?

Do they understand what those words
mean, right?

Like if those things are done
well, the gateway, sort of whatever.

It's an implementation detail, right? Yep.

Yeah, definitely.

So again, what we have in Germany
is also discussions

about language actually of, of APIs.

So we we have companies
that would like to have a German

speaking API
where we would normally say, okay,

maybe you look for international market,
not for now,

but you will have international developers
through through the time actually

working with the company.

It will be quite hard for them
to understand what

this German word
really meant in their specific language.

And then

it's really, really interesting to
to have such discussions actually, because

you can you can help people to

to really move on directly
into the right direction.

Yeah, it's very interesting.

Just have this tooling.

This the tooling doesn't care about how
we name things and all the stuff.

So and then what I see a lot actually
is is this copy thing.

So when we talk about API guidelines,

we see a lot of copied things from Zalando

and all the stuff available and,
and we need to.

You have guidelines. Yeah, we have.

We have them here 15 and 15

pages
of, of guidelines and I'm always 15 pages.

Oh I'd be zalando
because normally when you know,

when you print them out earlier
you know how long they're actually.

Yeah.

And when you look at them
and you see that you see this, this,

this keywords and all the stuff,
you always it now they just copied things.

That's not good.

So we have to restart it actually.

But I guess I'm curious though
what's, what's not good about that

because earlier you said I'm
going to play devil's advocate here.

Earlier you said, you know, like there's
no standards for these things.

There's no standard way of doing it.

Well, like, if Zalando
or any other company

has gone and done a great job at the time
and churning all this stuff,

why shouldn't they just use that?

Why can't I just say
I use the Zalando standard?

Because
it's the standards of slander, actually.

So it's not appearing
to be your own, actually.

And to give you some insights on projects
that are actually quite a project

about this because somebody said,
Yeah, we're just doing the copying thing.

And I said, No, then
it's not the best thing to work together

because copying things and not really
having things fitting to your needs.

In this case, it doesn't feel good.

In this case, it's not the thing
I would like to do actually, to,

to approach things
and bring governance into it.

Just to be on the fast track and saying,
okay, you we have the guidelines

available, 1550 pages
or anything like that or 21.

So it's really, really something that that
has to come from from this initiative,

from this program saying this is what
what is our opinion about APIs?

Because normally when people

start with APIs,
they're just focusing on distressed stuff

and then you have people that that are

moved further on saying,
Oh, we don't needs API stuff

because we, we doing event based stuff
and you always think

that you should also think
about documentation and all the stuff

because there are other specifications
available.

And this is, this is really,
really interesting talking with people,

people about it and saying,

okay, it's not just about the interfaces,
whatever they mean.

It's really about, yeah, this discovery
of the whole services you have available.

And this is why I'm actually dropping APIs

out of my vocabulary.

When I talk with people
about the situation

they're in, I'm
just talking about services

and maybe that helps them to,
to attract to the things even more.

Myself and many others ever refer to this
as like

talk about the capabilities, like
what are the things that you want to do?

And don't worry about the API itself
first, right?

That you can put together
a shape of that based on the

the kind of words in their relationship.

It sounds primal
and kind of simplistic, but

yeah, that's sometimes you have to take
all the technical stuff

out of the mix
to actually build the right thing.

But I got to go back and ask again, like,
you know,

if if there's a good standard out there,
you know, you're saying,

I think in one sense that there needs
to be this almost social contract, right?

That people have come together and agreed
on something and that that's valuable.

And I think we can come back to that.

But like what?

Why did you quit that project?

Why did you

why were you so certain
that that would have failed

had they just sort of copy
pasted their their standards

or their style guide or whatever
you want to call it?

Yeah,
it was part of that, just copying things.

And from the beginning on
there was still this misconception.

So it was really build up on tools
from the beginning.

So we, we just didn't have
did the thing around says

so there were many many things around

actually was also talking about languages
about APIs in this case.

And that was really, really hard to,
to, to, to, to, to make the other points

out in this case and saying,
okay, this is we do this because of

and nobody was really on the same page

because there was this in the end,
I know it because they were really missing

this this product thinking type of things
that they were just thinking about.

Still an integration stuff
and just providing integration

APIs with with no server.

Yeah.

Idea of how to move on
and how to present things

in a different way in a different anger
angle.

Actually just, just focusing
on this intubation stuff in this way,

do you think what is it
do you think that it's primarily

kind of the reusable litty factor
that it's not considering, like

looking at, Hey,
I apply an integration pattern to this one

integration and now I have a single use
case thing that I can't reuse.

In other scenarios.

Is that problem is that maybe we had this
this is this is also 11111 part.

Actually that that is what what we see
at that project quite often.

So really focusing on specific use cases
and when when we when we start thinking

about to break it
down, it's really coupled to budgets

and all the stuff
so that people are not really focusing on

what are the core APIs or the core values
maybe of a of an organizational company

just focusing on specific things
where you can really see, okay,

this is one specific use case, but

when I want to have more insights on this,

on on this relevant
data, there's nothing actually available.

I have to
to do things on my own and do that.

So it's it's it's also in that way,
it's it's really focus Yeah yeah.

The missing focus on what what is really
relevant for for the company as a whole

not for this specific project
We are talking about because in the end

creating APIs is still now

dealing with projects on, on a, on another
level actually in this case.

Yeah.

So it's funny that's, it's a

I find it interesting that like

you almost struggle to say
like why exactly and you know

and I understand like it's this
hey there's a you got to think through

what is your platform going to be not
what is this API you're about to build?

And I feel like in some ways
we should be calling this like

platform design
is the thing that needs to be explained

and that whether it's a rest API
or an async thing or

you think GraphQL is going to solve
all the world's problems or whatever else

it is, right?

Whatever the the hashtag of the day
in architecture is,

you know, you think, okay,
we that doesn't matter.

We know what we do

and we know how to describe it.

Right.

And whatever means we need to package that
for in that case, that's great.

But I think

across the course of our conversation,
what I feel like I have to call out here

that we didn't really say is
and I think we did so early on.

You're saying, you know,
you got to be able to

to know
the consumer who's going to use it.

You actually have to talk to them.

You have to understand their needs.

You have to be able

to describe things in a way
that's going to be global in its purpose.

That's, you know,
that's clear and understood.

You got to design the thing
before you build it right. And

and you kind of got to know what's
what's core and important, what's not.

For what it's worth, I could

apply all those things
that you said to any product.

And then this is just to say that

treat your platform as a big product
and the individual APIs

are sort of sub products that should fit
into a bigger picture, right?

And all of this is to say that earlier
we said that the big misconception is

build APIs, go fast and in some ways,
but I think we got to

there at the end
was that if you can reuse,

if you can do those projects back to back
and each time

you build something,
it's useful for other scenarios.

That's how you speed up, right?

But it takes intention and discipline
to do so, so on.

And I'm trying to sum up

and pull all this together for you,
but tell me if I got it wrong.

No, that's. That's it.

That's totally, totally right, actually.

So this is this is what,
what what we are focusing in to to

to bring people to to that place saying,
okay, this is this is what you need.

Find find the right purpose, actually.

And and this initiative, program,

whatever you call it, can be a success

because this is this is this is the fast
way here in Germany.

Just cutting down things
when they're not that fast,

because normally the easiest KPI, an API

API projects
is to look at the number of APIs actually.

And when you when you say, okay,
after one year we provided only five

and you don't look at the value of them,
then it's really hard to say, okay,

that's five, that's really,
that's really slow.

So just drop the initiative
and do something because we missed it.

And this is,

this is really something that's, that's,
that's what is bothering me all the time.

So. Well, that's an interesting question.

What do you tell folks when they say
what should our sort of first

KPI be versus how many APIs we developed

in the end?

The first KPI I'm always talking about
is this first steps to how a world,

how long does it take to
to really get into, into an API

that that, that we provide at first side.

So how long does it really take to. Yeah.

To get a result back from this API.

Yeah.

It's a good like the developer experience
new business manager.

Yeah.

And then really thinking
about all the other stuff because

all the measurements, all the metrics
and thinking about monetization,

it's something you shouldn't do
from the beginning because

it's not worth in the end.

Now you figure those things out
per product, right?

And focus on the API itself,
but rather the product that it's

delivering or that the capability
that it's delivering.

There's usually a measure of that
that's far more useful.

Cool.

Well, man, we covered a lot of ground.

I feel like I'm going to have to go.

You know, it's morning
recording for the summit.

I feel like I have to go
have a drink of this week.

Yeah, we went all over
the place was great.

Thank you so much for being so open
and really sharing

a lot of kind of what you've seen
and learned in this.

I appreciate it.

Thank you for having me.

Well, I wish you the best on your future
consulting engagements,

and I'd love to hear from you
in the future on on where this kind of

dipping into API product and capabilities
and all this stuff goes for you.

Take care then.

Thank you. Bye.

Thanks for listening.

If you have a question you want to ask,
look in the description of whichever

platform you're viewing or listening on
and there should be a link there.

So you can go submit a question

and we'll do our best
to find out the right answer for you.