Subscribe
Share
Share
Embed
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.
None of the organizations I've worked with
have that really in place to start with.
And they they sort of poo poo
the idea completely when I do raise it.
So I just let it go.
And then we work on the other stuff
and at some point they are now saying,
Oh, do you know what we need?
I'm like a product manager?
They're like, Yeah, product manager!
I came up with that idea,
you know, is what they...
So you got to,
you know, and they get there once
the rest of the pieces are in place.
And I'm sort of like a little bit
more relaxed about that.
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, auth, versioning and more.
Welcome back to API Intersection.
I'm Jason Harmon, the CTO at Stoplight.
As always, your host.
And today it's yet another old friend and
virtual neighbor
from when I lived in Barcelona.
Mark Boyd. Mark, thanks for joining us.
It's great to be here.
Good to see you, Jason.
So, you know, for me,
Mark was always one of the early folks
that was writing about APIs
in just all different avenues,
all different places.
But kind of this whole notion
of the API economy
and that sort of thing,
I feel like you were one of the early
sort of most prolific bloggers
on this subject,
which seemed to keep getting upgraded. So.
But now you're doing big crazy things.
So tell us a little bit
about your journey with APIs
and what took you to
what you're doing now.
Yup, sure.
So before the world of APIs,
I was actually working urban planning
and public health and designing
data systems
for local governments to be able
to measure population health outcomes.
And I had
when I moved from Australia to Barcelona,
I had a job lined up
where I was going to continue doing that
and it fell through.
So I was staying in Barcelona.
I was like, How am I going to make money?
So I opened my laptop and was like,
How do I write for the Internet?
And so I started writing to the Internet,
but very quickly
fell on to API and was thinking,
This is what we needed.
We're more designing
those data models for local government
because if we could pull in all of this
data from different areas via API,
we could build the dashboards
that allows the city government to know
when to invest in preventative measures,
when it's where they
when they're over flooded
with fast food outlets
and need to change up the environment
or when to do the walkable streets,
all of that sort of stuff.
You know,
APIs would have been the solution because
not only could you bring in the data,
you could map it as well to all of these
really crazy, interesting stuff.
So from that angle,
I sort of instinctively
knew the power of APIs and just started
writing for sites like Programable Web
and the new stack to talk about APIs
and was somehow able to find this balance
between some of those technical
aspects, the business value,
and then also and also describe
some potential use cases.
So I had that sort of, you know, magic mix
that meant
that I could write really well about it
sort of instantly.
And I love doing it.
So I sort of grew from there.
And because of that knowledge,
then that led me to opportunities like
Program Chair for the Austin
API Strategy Conference
and then going on to do doing things
like being invited to
do some consultancy work around APIs
and so on.
And so that's how I sort of like
built out my work that way to now doing
more sort of API specific projects
for a range of different bodies.
Yeah.
So your company now is called Platform
mobile, right?
Yeah.
And so tell us a little. Bit
about what you do with that.
Sure.
We're a team of nine, so one of the issues
when I moved from there
writing about APIs and then started doing
consultancy work was
I was getting a lot of different projects
being offered to me.
And so it was sort of it was difficult
to know which ones to prioritize.
So I actually went to a business mentor
and talked about
what sort of values did
I want to have for my business.
And I really came across the understanding
that for me I was interested in systems
that allow everyone to participate
and co-create their own value.
And so open
ecosystems is a model of using APIs
where if you've got those API components,
whether that's access to data, access
to web services, you can actually open it
up so that everyone can be able
to build what they want to buy,
what they want to,
you know, customize products
and services to their own needs and so on.
So and that allows new market entrants in
rather than the established players
always getting the market share and so on.
So I wanted to do something that was
taking APIs to that next level.
And so for me it was about
how do we support the development
of open ecosystems?
And so then we wanted to work in key ones
like banking and finance, where
there was just the emergence of the open
banking and API world health.
Because of my background in health,
I did want to do sustainability.
I tried to do sustainability too early
and we were not ready to grow that fast.
But that will be the next one.
And then governments, because of my
background in government, work as well.
So. So yeah.
So now we focus on
banking and finance, health and open
ecosystems generally.
Yeah.
And how do you build those?
How do you support that growth?
Yeah, for sure.
So looking into this a bit before
doing our homework and chatting with you
before we started recording here,
it really
sounds like you kind of developed a method
for these sort of segments of the market
in how to build their API programs.
Yeah, it's really
what's what I find crazy with banking.
Let's talk about banking and finance
as an example.
So what I found really interesting
with banking and finance was like,
say you've got Europe and UK
led on this whole idea of banks.
It's too much of an oligopoly.
So we're going to force them to have APIs
and then APIs will allow
new market entrants.
So you've then got all the fintech
coming in to be able to build
more than just,
you know, banks haven't really
modernized or innovated
very much over the past 100 years.
You've got a savings accounts, you know,
and you've got a lending product
or whatever.
So by having APIs that was enabled lending
and all these fintech
to be able to either provide me services
or other sort of products, you know,
for particular target markets know.
And so that that was the reason for you
sort of thing.
And then you see these
particular regulations like Indonesia
says this is about financial inclusion.
For example, Brazil as well.
So there's all of that.
But when you so regulate this,
we introduced all of that,
but then there's no way to actually
they're not
they don't have a system
to actually measure.
How is it actually creating
that level of consumer choice?
Is it actually increasing
financial inclusion?
So we tried to take a step back and say,
okay, how does value get
generated
and distributed in an open ecosystem?
So we looked at,
you know, like, say, regulators come in,
then you've got you know, they're saying,
okay, banks and fintech
have to open APIs and from APIs.
Then the level of developer experience,
the level of security,
the level of digital readiness will mean,
you know, if you've got strong
developer experience, for example,
you're going to have more API consumers
building products quickly.
If you've got less developer experience,
you're not going to get that
flywheel effect and that sort of thing.
And then you need
other things like API governance
and standards to be playing the part
and so on.
And so we mapped all of that out.
And then so going back
to my local government data model days,
we sort of made them thought,
okay, what's the indicators or what
would you measure so that a regulator,
for example, would be able to say,
yes, this is open banking, is generating
the things that we want.
And as we did that, we realized, oh, okay,
if you're a player in that market,
if you're an API, if you're a fintech
that wants to use bank and other
fintech APIs to build your product,
you could use this mapping to see where
the opportunities in that market are,
what gaps there are, who's being serviced
and who's not being serviced,
and be able to sort of jump
in on those opportunities as well.
So, you know, all of this
sort of ecosystem mapping was sort of
a new endeavor that I don't see that
not done very much anyway.
And like it really is inside
the mix of ecosystem
mapping you see is sort of the CB insight,
sort of
this is how much is being invested
in a particular subsector of the market,
whereas this is much more about
how does how do APIs flow
or generate this flow of value
and who's missing out
and where are the opportunities and
where could we invest more in and so on.
It sounds like you're looking
sounds like you're looking more at sort
of the network effects
and how to measure how that converts
into sort of economic opportunity versus
the alternative.
Absolutely. Yeah.
And it's crazy that I haven't We haven't.
So, you know, we've found some models
which we draw on because we sort of
look through the evidence base
and we were always updating those.
And there's some really interesting
researches out there, but there's not.
But we don't see enough
of it just yet, you know.
And so I harp on and on.
I'm sure listeners are tired of hear
me say it, but like I always try to
quickly disambiguate
between which platform
are we talking about, the Harvard
or the MIT version of the world.
So there's sort of
like the MIT for engineer types
is like you're building a component sized
distributed system, right?
We all get that. It's easy to understand.
But then, like the Harvard's
other world team
and you see this more with the MBA
crowd is like we're building marketplaces
that have these sort of,
you know, at least two sided
participant sets.
And that's where you tend
to see more of that network effect
and all that kind of stuff
get calibrated a bit,
I guess.
Where
where do you feel like
you're falling when you're looking at this
sort of ecosystem development mapping?
I think more on that marketplace
side of the equation.
So there's that we go a little bit further
even because we sort of
then think, you know, my background
also with the health stuff
means that I'm focused on equity.
So we're very much looking as well as who
potentially misses out because the problem
with APIs that I don't think
is being taken
seriously enough is they are
that velocity impact of APIs is huge.
So if you go off down the wrong direction
or if you go off
in a particular direction
that favors some players
with APIs, the speed at which you can go
down that path and the mass
market appeal that you go down
that path means that you could actually
seriously lock some sectors out
and some participants out very quickly.
You know, so so there is
this need to constantly keep that in mind
in some of these marketplace models
and so on.
Don't I don't think they've got
that equity lens and I've seen it also.
I don't think that seen things
through the indirect beneficiaries
as far as society, the environment
and the local economies as well.
So I would like things like that.
APIs that we use the transport
have an impact on where they can be used
for route planning,
which in turn reduces carbon emissions
because you're able to better
map carbon emissions, you know, better,
better use of resources
to reduce your carbon footprint
because you are able to get there
and you're not like circling in blocks,
you know, in the car or whatever,
you know, and you see that a little bit
with that
how some private jet APIs as well.
You know, it's great
that we've got access to that data.
I think we need to discuss
that a lot more.
As far as the fact that there is the like,
that's where the carbon
footprint of the plan is coming from,
you know, things like that.
But IP so APIs do have this real value
to be able to draw attention on.
You know, where can society improve access
and opportunity for everyone?
How are they being used?
FinTechs being huge, it
being enabling local economies to develop
because they've been able to build
employment hubs for people in areas
like where you're living,
you know, And so on.
And so and you know, this environmental
footprint and some of those models
don't factor that those sorts of impacts
know, I don't think enough
you know because they give as a
late stage capitalist model.
Yeah I mean we're I think
most of us have been somewhat subject
to the social experiment that is platforms
like Airbnb and Uber, where it's like,
you know, you see entire
the entire city compositions
change as a result of these things.
And to your point, like it's
a digital access to or that many don't,
just don't have an entry point to drive.
Yeah, absolutely.
So it sounds like you've kind of got your
got your base going in fintech,
which makes a lot of sense.
I mean, I know
from a stoplight perspective and just,
you know, my view as a whole,
like the last few years has been quite
a huge investment from banking and fintech
and certainly open
banking and all that.
But what I find
particularly interesting is this notion
that you've kind of come up with some
approach to
governance
that is generally somewhat portable,
or at least by the sounds of it,
between these different industries
to include government,
finance, banking, health, so on.
Yeah, Yeah.
So what's what are kind of the,
let's say,
pillars of the kind of your approach?
Okay, cool.
So then we did some work
with European Commission where we looked
at 343 to be exact
articles in reports and
published journal pieces on APIs
in the best practices and so on.
And then we whittled that down,
I think to just under 200
where we that we were able to draw
on, to be able to then say, okay,
this is the evidence base we've got
as far as what's worked with APIs
and so on, both in governments
and in industry.
And then out of that we,
we developed a framework,
the European Commission, which is the API
framework for digital governments.
But I think it applies
just as much to business
or any sort of nonprofit organizations
and so on as well.
And that's really talking
about sort of pillars at the core
of the policy tactical
and implementation levels.
And so at the policy level, you do need
you know, I know we talk a lot about that.
You know, you need the sea level
sponsorship
and you need to have that high level
to be on board that there is
let's move to an API approach.
So you do sort of need that.
I think, but you definitely need that.
But like Wade,
then I think what falls down
is when we get to that technical level
with those line of business managers
who just have too much other priorities on
and like they lost out on that,
they may be sold on that in the sense
that,
yes, they know
it's an organizational priority.
And yes,
we do believe in that IP.
I want to get that.
They want to get their bonus, too,
and follow the rules.
Yeah, right. Yeah.
You know, but the fact the fact is they've
also got all of these other priorities
that they don't immediately see.
APIs could be the ones that help
solve them, solve those problems as well.
And when they do, they're like, Oh,
but it's so much work to just re-orient.
I did some work with the bank
is it years ago?
And they were looking at they had their leasing project, they had sort of a leasing
line of business and they thought
that would be a good one to start with.
IPOs know
said they sort of wanted to create an API
and we gave them a ton of use cases,
you know, like you could help
move people onto electrical vehicle
slates, you know, sort of thing.
For some of your corporate customers,
you can be better cycling through cars
that haven't been used once or twice
a year or so, all of this sort of stuff.
So they had all of that
and they were like, Yeah, let's do it.
Okay. First of all,
you've got to have your data set.
And that had a traditional data set
that they were going to plug into the API
and then they realized I had to clean up
that data set to be able to feed it.
And I were like, Oh,
so that
pretty much just killed
the whole very game because when they sold
the work that they had to do around
cleaning up their data sets in order
to have something of value
to pass through the API,
it was it's like when you get at home,
people
don't want to join a business
where they're going to be
dealing with legacy code,
where there's not good documentation
that will refuse a job, will leave a job,
you know,
if they've got to disentangle someone's
legacy code and it's sort of like that.
So those middle managers are constantly
making
that decision of like,
do I have to invest in that now?
Can I?
Because that's going to be six months
to just clean that out before
we start to get any business value
out of the API.
And so up until recently, I think
it was very easy to decide
that's too long a time frame.
So they will do ideas on the next project,
but not on this one, you know.
So there was so that
there was that tactical level.
And then there's the implementation level,
which I feel like is almost the easiest.
We know pretty clearly what
that API design
based practices are and all of that.
So even security issues, we we
know that there's
a need for particular tools in that.
But it's a, it's a known problem
know you know
there are nine solutions for.
Engineers have been building APIs
for ten years in this the
the amount of tools available
for engineers now to build the API.
So like I was like don't think
we need tutorials for that anymore.
There's so much out there I agree with you
on implementations the easy bit.
So then that so then that means so
when we then work with businesses around
and multinational
multilateral organizations,
which is a lot of our business as well,
then we're trying to figure out
how do you create API governance systems
that aren't too bureaucratic And the done
also require you to refactor
everything you've got already as well.
So often it means that we've got to take
a two track approach
where the APIs that they've got, you know,
which might be like 30 to 50 external
facing APIs, for example, something,
you know, that's not unusual number
that were each built individually
and differently and some use three digit,
three letter country codes
and now these two used the two letter.
It's all of that sort of stuff.
We've just got to leave those
because the the business system
that we're integrating with them,
they don't have the investment to upgrade
their IP, you know, to re integrate
a new version of the API or something.
So they've got to sort of like
just accept that
that's it and then sort of go, okay,
but we live in a new world
now and going forward,
this is how we're going to build APIs.
You know, it's.
You know, I feel like that
that particular little bit there of like
except that what you have is
maybe not that great, but it does
the job and people are using it,
move on and build something new to like
that's the first hump
to get over everywhere I've ever been.
And the idea that you're going to go back
and fix everything you did
before is just like it's
probably not going to happen. So,
I mean, that's like
the thing that people just need to get get
okay with fast, right?
Like you're going to define
a new archeological layer
in the history and, you know, go for it.
It's funny
because we use terms like technical debt
and someone say,
I heard someone say once legacy
or in other words, things that are working
well, you know, like so we see that like
the thing is that they are
if they working you know sort of thing.
So we've got to sort of
like not have that.
Tim taken off like let's rebuild
everything all over again, you know,
sort of thing.
Now that we, you know, this new way,
you know, and,
and I think giving to me
when we've given businesses
that permission to keep what they have,
then that's been easier
for them to be inspired
about getting on to this new vision
for the new stuff coming up.
You know, and that's where we've seen
a little bit of that shift
on things like data governance.
So, you know, you've got API governance,
you know, trying to get
API said that
they were all build
to a consistent standard
and that they might be use the same
data models and that you know
they've got the same nomenclature
and that they use in the sense of design
principles and all of that sort of stuff.
But also
then you've got this data governance work
which we when we've looked at businesses
and organizations, they often say
that is completely separate.
So we've I've worked with companies
where we're doing API governance
and they're like,
Oh yeah, data governance that's being done
in a completely separate project.
And yep,
you've got data models in your iPods
and they're like, Yeah, well let's just
keep what we're doing sort of thing.
So we're trying to bridge those two
worlds as well a little bit.
And so yes, so then you've
got to work with them
around the data governance side of things.
And they are
I mean, I love some of the stuff
that's come out of government
from UK around civil services
has been really inspiring enough
to on that quite a lot.
So things like, you know,
like what basically used to happen
or still happens
in a lot of places in governments is H
Everyone wants to work with schools,
you know,
so you've got the Education Department.
Sure, they working with schools.
But then, you know, the Environment
Department wants to describe
a new recycling program and someone says,
let's let's deliver it through schools.
You know what then is the nursing program?
It's like, let's deliver that
through schools or whatever.
So then all of these other departments
create their own schools list,
you know, and their own database
for schools rather than using the MH Kasam
database of the schools, you know,
because they want different
fields and, you know,
they don't need the principals
knowing they need this other teachers
name or whatever, you know, sort of thing.
So you've suddenly they've got like 20
schools, databases
across various departments,
some of which only one of which
is probably maintained well.
And that's one in the Education
and the Education Department's public
of multiple out of out of sync databases
as well.
So, you know, like the first thing
and this is from that UK digital services
is you find who should be the digital
who should be the data registrar
and they're the ones who
then are responsible for maintaining that.
And then all of the other departments
and everyone else then uses that data
set via API
so that it's, it's not like you.
We've made a good bulk
download of that data set.
It's more than that. It's
no, it's real time.
You're just using that one, you know,
so that we moving to,
moving them
towards that around the actual data sets.
But often it's the data models as well.
And just having like a set of might be 20.
And this goes back to the
idea of golden paths and the
and that sort of page road
sort of idea is like, okay,
what are the ten or 15 most common
data models that most APIs use?
Like if it's a country card,
are we going to do to
to let the country go or straight.
You know, and so you decide on that
and then you've sort of build up
gradually to have those sorts
of data models as well, you know?
Yeah, establishing
sources of truth, right.
And like it's I feel like that's
a pervasive issue is like,
you know, that nobody's really clear
on who owns the data
and so everybody's got their little horde.
So yeah, just establishing
sources of truth absolutely makes sense.
Yeah.
I don't know how much it works
in business.
Maybe a little bit,
but definitely in government.
The issue is also that you don't
if you've been spending money
on developing that data set
and now all of a sudden
you're going to use a common data set,
You don't want to give back that money.
So that's
where it sort of stops at the moment.
I always think everyone's like,
No, we want to keep our data set because
you can't use that then as a way to say
we don't need all of our budget.
So there needs to be a gain
with that legacy and a new world order.
We need to sort of accept that, okay,
you can't maybe you get maybe
there's incentives where you get to keep
your budget advantage.
If you show you're reusing components,
you know, but then you see APIs
completely impacting
on financial modeling for an organization.
So the
Yeah, and I think you hit the nail
on the head with the phrasing there
that like, how do we build incentives
for shared leverage?
I do think it's very
portable concept in business,
especially if you have a history
of a very siloed organization
where it's like,
we do this thing and we have to fight
and claw for every bit of budget,
you know, for giving stuff away.
That kind of mentality,
it causes problems.
I've been harping a lot lately that
as companies transform their platform
and thinking right the way they think
about their business, that stuff one is
except that your your development,
your engineering should be treated
like a giant open source project.
You can't put walls between technology
and that certainly pervades
into a lot of different layers.
But that's all just to confirm that.
Yes, I think that totally is a problem
in private industry.
Probably a little different.
But nonetheless, that sort of siloed
thinking and protecting from different
divisions and stuff can really hamper
something that, to your point,
could fundamentally change
the way business is done.
And in order to make that transition,
everyone's
going to have to kind of pull together
and look at things different.
So that side of things,
we try to introduce the inner
source concept and that sort of mindset
into an organization.
And as far as I'm getting at the moment,
so it my successes are huge on this.
Like,
I don't think I've solved that just yet,
but what we're doing is just simple wikis.
So for example,
anyone who's building an API
in a line of business
can share that on a common calendar.
Or you know, I said that there is across
the organization, you can see in one place
all of their APIs
that are going to be built this year.
And so that if you're building an API
that's got a form
element to it, you might want to
look at what other APIs are being built
by other lines of business
who are also doing having forms
in, you know, going to
the interface is going to be a form
at the end, you know, sort of thing.
And so work with some of those.
So, you know, we're just trying yet
to try to get that mindset
that you're just talking about,
sort of fostered by having that.
Another one is a taxonomy.
So showing the APIs
and some of the functionalities like what
in one organization, there's multiple
lines of business, but a lot of their APIs
have checking the status of an application
as part of the API.
But all of them
have been built differently.
But they've all got that
same functionality.
So again, having a taxonomy is like,
okay, if you're building an API
that's going to have checking the status
of an application, who else has done that?
Which one is do you think is the best?
And again, that might be that we move
to a data model or best practices for.
So eventually they've got a data
model of here's how you do
a status application check, data model,
you know, sort of thing.
But they might not have that at first.
You might just have a look at the font
that they've already got and decide which
ones you like, you know,
And that's what we
mean by the low
bureaucratic approach as well.
You know, you can't come in straight away
and say like because otherwise it's like,
let's have six months of meetings to
design the data for a status application.
You know, I.
I left because I've been subject to that,
some of which.
Yeah.
And it's funny
because I think I tend to have,
you know, my sort of engineering
background betrays me.
And, you know,
I always talk about this like
even if you have some kind of management
mandate
to your point,
it's really a kind of mid management.
And in larger places that's typically
you're like the senior VP,
VP ranks that they're the ones
they really dealing with.
And I don't know, may them call me like
cynical,
but at this point I'm like,
build a band of rebels, of people
who get it in product development,
ghost ship something
and make them look bad
and they'll come around like that.
You know, it's way too adversarial.
This is why I'm not in consulting right?
But I always appreciate and respect folks
who work
with kind of the more business side
to figure out how to turn their heads away
from pipeline business
thinking into platform thinking because
it's a different way of doing business.
So I love it. And yeah,
yeah, you're right.
And like I said,
I mean, I'm a very passionate person
and I get in, you know, I love this stuff.
I do, you know, sort of things
now, but I've had to learn not to
fight every fight
as soon as it comes up, like in my big one
is where I'm product managers for APIs.
Like I come in always when we're talking
about API governance and say, you know,
you've got to have a product manager.
And they're like, No, you know, they
you know, none of the organizations
I've worked with
have that really in place to start with.
And they, they sort of poo poo
the idea completely whenever I raise it.
So I just let it go.
And then we work on the other stuff
and at some point they are now saying,
Oh, do you know what we need?
I'm like a product manager.
They're like, Yeah, yeah.
I came up with that idea, you know,
I like his website.
So you've got to,
you know, and they get there once
the rest of the pieces are in place.
So I'm sort of like a little bit
more relaxed about that.
I think one of the biggest principles
that working on big platform projects like
this taught me is like walk in the room
knowing what you're willing to lose.
Like you can't you can't win every battle.
You just need one thing to ship
that's really, really good.
Yeah, if you can get to that point,
the rest will turn for you.
And then I A side note too, on the API
product manager thing.
Yeah, we follow that this topic
pretty closely, especially on titles,
just because titles have always been
meaningless in platform work. But
API Product Manager on the Rise
the last couple of years for sure.
Like well, we're seeing more of it
and I almost never saw anyone
with that title before.
And now we see it all the time.
We even have stories of,
of product managers who design
the APIs without engineering involvement
for the first draft.
So I think in the private sector,
we're really starting to turn a corner.
But good to hear that there's at least
glimmers of hope in the public sector.
Yeah, yeah, yeah, absolutely.
So let's see, we touched on
a couple of different things,
I think around kind of business value
and marketplace equity
and all these sorts of things
as well.
Some of the cultural change on inner
source and some of this stuff, I guess.
So there are other, you know,
and you sort of referred
to the fact that like the implementation,
it's easy, but I guess
are there any other sort of facets of this
that you think are essential?
Um, so the
so I mean, with going back to that page
Roads idea, we're trying to do the whole
internal developer portal, We help build
those as part of that API governance.
They're somewhat, I would say somewhat
shitty thing about that is that gotten us
really seems to be really gung
ho on back stage
as a internal developer portal and add
you know, it's very good at convincing
everyone that they should be using back
stage and it's really horrible to use,
you know, where, where we often build,
you know, we're building these dice
internal developer portals
for using backstage because that's what
organizations want, you know, But
it's sort of we're sort of stuck with it.
But, but it's sort of like,
I guess
so I mean, there is that need
for like an internal catalog
or internal inventory of like
what do we have?
And also when we start a project,
how do I just get my project set up
and ready to be able to start doing stuff
rather than, you know,
getting the environment right
and all of those so getting, you know,
getting even just little things like,
you know, for us with one client
that's about
if they're going to be working on
the new Approach project,
then making it easy for them
to be able to alert that they should be
one of the user seats in the stoplight,
you know, subscription,
those sorts of things that can
if you don't have it all in one place,
it might take a couple of weeks
to figure out that
you made all of those things, you know,
So we're trying to sort of bundle
those together,
which is something we've learned
from team Topologies
and they are approaches to sort of,
you know, making,
you know, and the like the Pipedrive stuff
from like Netflix and
and so on around that sort of golden type
roads sort of ideas.
So yeah, so that will be another one,
the internal developer portal
that's working on the standards,
whether that's the API standards
or the data models.
So trying to bring that together.
And then what we say,
and this is what I love about Spectral
is that you can then put those,
those standards into spectral
so that you're taking out.
So we don't in a lot of places,
you know, the governance committees
I'm big on, you know,
I think they should be structured
the way you've got a governance committee
or something like that.
But that's just normally
that's like the architectural decision
task force or whatever
they can approve.
You know, they should be improving
the API standards if you like,
but then they don't need to approve a API
that gets built
because if you've automated
those standards, then they're influencing
that decision without it, without them
being a bottleneck for them having to
then go through.
When you wait for the three
waits for them to meet and all of that
sort of stuff to get it past all of that.
So yeah, so, you know, like we're trying
to look at automated systems like that,
The inner source
to be able to said that everyone's
sort of more willing to share information
about what they doing,
writing little notes about why
they've made decisions,
particular data model decisions and so on.
When there is an a clear data governance
decision made
to get higher up the chain,
those sorts of things.
Yeah.
And then and allowing that sort of legacy
versus new newbuild approach
to sit side by side, you know,
I think that two together they have
the sorts of approaches
and working from that tactical level
is really important.
They're cool.
Well,
I don't know how much you're still writing
or publishing things
or other places people can go to kind of
follow what you're working on.
Sure.
There is platform on vogue.com,
so we've got a blog there
where we talk about a lot of our models.
So we've got stuff around our open
banking model.
We've done some work with World Health
Organization with mapped out and open
health model as well.
That was now worked on.
I'm releasing some stuff on data,
outdated data governance systems,
and I've got a blog coming out shortly
about how
the API governance model as well,
so that a lot of that.
So we do sort of that
sort of thinking work
and try to share
that we're back to rate you
so anyone can come along
and say at any time our website
we're going to do a complete refresh
where it's
moving more towards a resource hub
for open ecosystems as well.
So you can be checking that out
by the time this is going to air.
Probably 13.
Well, I guess I'm going to come back
and this is always,
I feel like a quiz as to whether or not
you've actually listen to podcasts before
because you either see it coming
and you have a good answer.
I'm going gonna catch you out
and I love to catch people out. So
we talked about all this stuff.
I mean, it's a whole lot of bases
to cover to really get a platform
scaled out and governed
and designing at scale and all that.
But for listeners who are going,
you know, we're just getting started,
we want to kind of
how do we get the ball rolling?
Like if you had to start
if you go into a client from scratch,
what's your go to Starting Point
if you don't know anything else?
Sure.
Then I think it's about finding
where who's got ownership
and who's got the interest
and working with them first.
So there will be
and so what might be so generally
this has been in one of two places.
It's either the
the the person who's hiring us
or has got the remit for being able
to spend a budget and they want to be able
to get the wins on the board.
So them but then quite often
they're lost with them way
too way to get it up and that there's,
there'll be someone in a line of business
that or a team in that line of business
that's building a new IP or doing
something that can be our pilot project
so we can demonstrate
how when all of this works together,
it works really well.
So we try to find that project
within an organization
and then work with them
because they're often quite excited.
They are often quite new and they are
willing to admit that they don't know.
So in some stuff.
And so they're eager for the extra help
and that and they're wanting
to also leapfrog and use
some of the best practices
or the newest tools or whatever as well.
So they're super arcane.
So we try to
sort of find that team, and that's the way
we've sort of had success in both.
So we're then working in two levels.
We're working with that product.
Oh, you know, the ANA, the client, Ana,
who's sort of hard to see and
and then with that individual project.
So we're doing the organizational stuff
with them, which is a lot more slow moving
and then showing how that works
with that team in place as well.
So you don't think that you should go
design all the future potential APIs
and define all the standards for a year
or two before you launch something?
I've worked with getting some myself
with consultants.
Who's
actually suggested doing all of that?
Yeah, but now, I mean, I'm very much
a work in progress kind of person.
So like, you know,
when I mention that taxonomy,
you know, we sort of just did that.
It's not quite back of a napkin, but,
you know, it's sort of
it's really rough deck work,
you know, sort of thing.
And then, you know,
we can do the that's the MVP, you know,
and then we can build from there.
But that's they didn't
have that before, you know.
So it's sort of that kind of yeah.
Yeah.
I think you have to have
a loose, big vision of where you're going
and how it's all going to fit together,
you know, I like things like business
capability modeling.
Some people use TDD,
but we did a little religious for me,
but I like what you're describing is like
this. We see this a lot.
Like you have the management mandates
easy to get these days,
but they don't really know
what they're asking for.
In a lot of cases, they're like,
I read that we should do APIs
and we're going to be faster,
make more money, so let's do that.
But show me how.
Right and to your point is like,
go find the launch partner.
Where can you piggyback the roadmap
with something that already has good
momentum, really make it super sexy
so that when it goes out, it's
a commercial success and technical success
from developer experience standpoint.
And you know, in my view, community
building is it's a cool game, right?
Like everyone wants to be cool,
especially in the engineering world.
We're not cool, so we just want to emulate
people doing cool stuff.
So if somebody did something cool,
I want to do it too, right?
So want something cool and
then everybody's going to want to copy it.
And that's the best way to sort of
build the movement.
So I love it.
Well, Mark,
thanks again for taking the time
to join us and share all your wisdom
and we'll definitely written you on and
and watching your blog and all that stuff.
So thank you. It's
great to be here with you.
Yeah, great conversation.
Thanks.
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.
API Intersection Podcast listeners
are invited to sign up for Stoplight
and save up to $650.
Is the code intersection
tend to get 10% off a new subscription
to stoplight platform starter or pro.
Take a look at this episode's
description for more details.