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.
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.
I’m your host Jason as always.
And today
we have a guest from over at Axway, Mr.
Brian Otten. Brian, thanks for joining.
Thanks for inviting me, Jason.
It's good to be with you. Absolutely.
We're pretty familiar, certainly
at Stoplight with the team over at Axway.
They're a sort of catalyst team,
you know, “DevRel-y” kind of stuff.
But I guess tell us a little bit more
about kind of what you do there
and kind of how that works with Axway.
Sure. Yeah.
We formed this team called the Catalyst
Team is really Axway’s dedication
to being able to help customers
with their API management
journey, their API delivery journey,
and really making sure that that aligns
with their business goals.
A lot of what happened before that, like,
like a lot of tech companies,
you kind of focus on what the platform can
do, what the technology can do.
And because, you know, we had people
who like myself, are really from more
like a practitioner architecture
background,
enterprise architecture background,
but also people who had sometimes
worked in roles that were one foot
on the business side of things.
It allows us to really have different
conversations with customers.
I think a lot of customers,
when they look at their API strategy,
they start from a technology group,
maybe like an integration group,
an application development group, or
it might be the people who have the remit
to get the tech in-house or hosted
if it's a cloud,
if they're moving to the cloud
and having it on a managed cloud option.
Those are the people who are really
focused on technical objectives.
So what we realized
is that in order to make sure that API
strategy is a success,
it has to really link to the business.
It has to be business driven as well.
So that's where my team came in. I was
I've been at it for four years now
and we have the opportunity to see
lots of different customers across lots
of different industries and really use
that expertise and try to kind of
almost challenge customers to say, Hey,
these are some of the other considerations
you need to think about in terms
of organizational alignment.
Operationalizing your API strategy,
How can you make it easier for teams
to get on board with the strategy
and then being able to track and measure
the success?
Those are all things that that, you know,
the catalysts are there to help
our customers do in order to sustain
and protect the investment, really.
Now my assumption
is that actually predominantly works
with sort of larger enterprise customers.
Is that true?
Yeah, that is the case. Yep, that's right.
Yeah.
It's it's interesting, though, how
I mean, we certainly have heard that
a lot on the show here.
And certainly we've seen that with stuff
like customers is how often like you
I can think of,
you know, platform and APIs
as some sort of technical challenge
and it's just not even close
to the top of the list as it
like that whole business alignment
piece is crazy to me how fast
and it's like, you know,
how does your business work?
How are the API is going to help?
Yeah, it's like,
I don't know, API is good, right?
Yeah.
Yeah.
Well, we have we were told
we have to do APIs and make everything
an API, say, oh, hold on a second.
Yeah. Yeah, exactly.
So then I guess in some sense
you're providing some sort
of strategic
consulting with some of your customers?
Yeah, that's that's true.
We have a set of offerings where we can do
these kind of light engagements.
You know, the other thing to say
is we're not like a big consultancy,
so we're not looking to get in there
and flood the place with with people.
What we really want to do is get
get our customers self-sufficient
so their teams can do the API delivery.
They can manage it, but they're doing it
in a collaborative way where, you know,
you avoid some of the big problems,
like duplication of APIs,
being able to get people
to have self-service for API.
So a lot of our customers
talk about the citizen integrator,
you know, being able to package up APIs
and what you just said,
they're JSON is key to that
because if people are looking
and searching, discovering the APIs
in, let's say an API marketplace,
if it's just a bunch of tech stuff
with a bunch of endpoints
and some cryptic stuff
in the documentation sucks and
nobody knows what it is,
they're not going to get what they want.
And then again, you know,
they will be able to say, Well,
we're going to build it ourselves, right?
Or you get the risk having inconsistency
of of the way the teams are doing API.
So you have a real variation of quality.
I was talking to a company yesterday
and a big energy company
and and that's what they said.
You know, our problem is we've got
lots of teams doing APIs, but they're
doing them in so many different ways.
And when we start to look
cross-functionally across the organization
on the enterprise, it's
hard to really start
to combine these APIs together and build
something useful because everybody's
done it in a different way.
And then that adds up to time
spent, right, which is cost.
So how can we get people to find
the right stuff, be able to compose
the right application
capabilities using APIs?
That's really where where
we want to focus.
Who is it that you're like?
Typically meeting
with in these sorts of things?
I mean, you know, there's sort of the,
you know, management sponsor types
who quite often, you know,
it's like they read in a business journal,
they should do APIs
and they said go or something, right?
Then you've got like,
you know, your run of the mill sort of,
you know, principal architect types
who are trying to build out domains,
like how often is there
sort of dedicated product or technologists
for that sort of platform,
wider view, like, you know,
who is it that you're working with
on this big picture?
Yeah, the exciting thing is
that it's starting to happen.
So we're starting to have organizations
moving to this product organization.
One pharmaceutical company
that we're working with,
we just happened to start helping them
with their API strategy and program
at a time when they were already starting
to think about reorganizing
their technology teams along product lines
rather than systems.
So previously you might have like,
Oh, we're the SAP guys, you know, So we,
we just manage this, this kind of back end
and all the master data and
but now they're starting to think, Well,
hang on a second.
We, we own the capabilities for maybe,
you know, business partner data
or vendor data or customer data orders.
You know, invoices, things like that.
And I think it gives them a chance
to really see their place
and start to start to get
some accountability and ownership there.
But it is tough because, you know,
when I first started this role,
a lot of people we engaged with were,
like I said before, kind of more
with the technical objectives.
So you start talking to them
about business capabilities and composable
business architecture
and using APIs as products.
And, you know, it's kind of
would kind of go over their heads
because say, Hey,
I just need to get this thing up
and running.
Don't talk to me about that
stuff. We'll do the strategy later.
It's like, I need to get everyone
using the same framework.
Yeah, right.
Okay. Yeah, that's.
That's right.
It's like a tick in the box, you know?
But, you know,
the reason I said it's exciting now
is because we are engaging
with a lot of people
on the digital strategy side, whether it's
banking or transportation or, you know,
the really big digital initiatives.
And those are the people
that we love to engage with.
And we're starting to see it more and more
because they can own the roadmaps,
they can start to say, Hey,
we got bits of our business
that we really think
we could unlock some value here with APIs.
And of course you're starting
to see enterprises
looking at the monetization
or commercialization of APIs.
So that's another way to engage
with digital strategy.
People who really see this
as a business opportunity
to open new revenue channels or build
a bigger ecosystem with their partners
and actually charge for it
and make some money
for the business off of APIs.
So it's yeah, it's exciting. I think
if I,
if you were to ask me that four years ago,
it's like, yeah, it's
kind of tough to have those conversations.
But certainly we talk to CIOs, CTO level
and they get it,
but they're not the ones who, you know,
they're the ones who then give
the marching orders. Right.
You need, you know, a bunch of people
under that who are saying, oh, what the
what the hell
are you telling me to do now?
You know, I just I don't get it, you know?
So people are getting it now
and the role, the roles evolve
and the product management combined
with delivery management for the API
technology side, the implementation side.
Yeah, Yeah.
We've definitely seen the trend of sort
of API product manager titles popping up
now in a way that even two years ago
you didn't see that same way.
And we've seen examples too of like the,
the practice of sort of designing
an API from scratch
is actually in some places
being conducted by product managers,
even though they don't have any
technical background.
But like kind of
the guardrails are put up in such a way
that they're able to sort of design
something, pass the tests,
and it should be close enough
that the team can massage from there.
Yeah.
To me,
that's been like just, wow, finally.
Right? Right.
The Holy Grail being the way for a decade
and maybe it's finally starting to.
Yeah, definitely.
And a couple of things on that.
I mean, one thing is converging
on a common definition of value,
and that's where I think
a lot of the technology people struggle.
I certainly remember throughout my career,
you know, trying to the technology team
and think about
what is the value of what I'm doing here.
Like what?
What is going to move the needle
for the business or not?
How are we going to track it?
Are we going to just have a bunch
of operational metrics in our API platform
that we have to
then piece together and make sense of it?
You know, it's really hard,
which is effectively to do that
if you haven't thought about that upfront.
So a lot of what we talk about
in the lifecycle
that really talks about API lifecycle
because it is,
but there are lots of different
there are three real lifecycles going on.
There's the business operations people
coming up with the ideas, the innovation,
the applications, the functionality
and features needed to
make their customers happy.
But then there's also the DevOps,
which is another operational thing where
people want to go faster and automate
and deliver consistently and continuously.
And that missing piece
is that product operations piece.
And that's really opportunity
where the business product
people and the technology product
people come together.
So we do things like, Hey, why don't
you guys before you even start, well,
before you
even decide it is going to be an API
because it's the other thing that happens,
build me an API to get X data
from this back end system.
You know, it's like, Well,
hold on, let's just talk about the value
proposition of this.
First.
People like Amancio Busa
have been talking about this for for ages.
There are lots of people
who have some kind of mature
practices around this,
and that's what we try to do, is to say,
let's let's work it out, get together,
collaborate, maybe whiteboard it
out on a canvas for the value prop
and think about what you're solving for.
Think about the pains, the gains,
think about what
the tasks that people have to do.
And then from there
you can decide actually
an API would be perfect for this, right?
And that gets you away from the
we're just a call center where someone's
ordering me to make a little Lego brick
and connect
A to B, where you can as a technology
team, you can actually start to grow
and developers can feel an API
designer is going to feel like
they're more part of the business effort.
You know?
So that's cool.
And that actually informs the API design.
So having something
like a value proposition, which then leads
to maybe like user stories and things
like that, but start even further back
where people are converging on that common
definition of, yeah, this is,
this is great, this is what we need,
this is what the API is going to solve.
So yeah, I think that's I think
it's a great way to inform your design
and make sure you don't have to redo it
or you've missed a whole bunch of stuff
or you've missed
a whole bunch of consumers
that you could have thought of upfront
as well.
And again, you know that that way
you don't build it just for one API
consumer where the next one comes along
and you've got to completely rework it.
You spend a whole bunch of time
and money doing that and you got real
true reusable API components and products.
Yeah, to stretch your Lego metaphor,
it's like building standard shaped Legos
rather than those those licensed
branded ones that only work on that one.
Right? Yeah. It's
annoying.
When did this piece even come from?
But yeah, I, I think I guess setting it up
a bit like that initial engagement
which more and more should be led
by product is to some extent about
what is the reusability, how does this fit
into the bigger portfolio,
which is, is like even before
perhaps you're even dealing with
like what are our conventions or like
how do we do our best stuff?
Isn't even that relevant
at that phase, Right?
Yeah, absolutely.
I think it's more about your roadmap.
Yeah, we did engagement last year
with a regional bank in the US and it,
it is a kind of a beautiful
and I feel like I'm being corny now,
but it's a beautiful thing to behold
when the business product manager gets it.
And again, this is where design
tooling comes in as well
because you can't do that
if you're all looking at a YAML file
or a Jason expression of an open
API specification
and the tooling unlocks a lot of that
and I think it really brings it to light,
it makes it real for business people
because then you're talking about
what are the what,
what's the licensing around this.
Oh I can put that in the spec.
What about the documentation,
Can we list out
some of the use cases and document
that so that the developer, when they do
go to the marketplace,
they can go, Oh, I see.
In the catalog, I've got this,
I know exactly what it's going to give me.
And I grab and I go.
So it really helps.
And it also helps a lot of organizations,
as I said before, who are struggling
with the commercialization
strategy around API.
So if they can see
how the APIs can be designed in a way
that makes it easy for the consumer
to build that into their own workbench
or their own flow,
then they can really see the value
of what they're delivering for customers.
Yeah, it's
definitely, I think for those of us
in the kind of tooling space, I feel like
2022 was like the turning point at which
like API product became real.
You know, it's like rather than the
oh well you actually do API product,
you know,
now it's like far more commonplace.
But yeah,
I guess if we go back to that lifecycle
thinking, right,
that we do all this homework
on the product side to make sure
we're doing things reusable,
it makes sense in the big picture.
But then presumably next,
you know, now we're going to say,
all right, let's have a draft design.
And does this beyond fitting
in sort of logically,
is this consistent
with the way we do things?
And I guess what do you see in sort of
consulting engagements as far as how folks
set that up and make it work?
Yeah, I think there's a lot of immaturity
in that area, but there's always,
you know, in the conversations
I have, there's always this are,
yeah,
we really would like to have a common way
for API
teams to do to, to design the APIs.
And I think you mentioned actually, Jason,
the the governance or the rules
or the style guides or you know,
and so I've seen a lot of attempts,
some really good ones too, like good
attempts to come up with the style guide.
But then
what's the differences between, okay, I'm
going to go find the style guide.
It's on a SharePoint, it's 50 pages like,
you know, how do you how do you make that
so that it's part
of like governance by design?
I think that's that's really
what a lot of people I'm talking
to are interested in is,
yeah, you know, the
the guidelines and the conventions
and all of that stuff are great.
But if, if developers aren't going to be,
if it's not easy for them,
they're not going to do it.
You know,
we all come from the development.
I do anyway.
You know, you are always saying, well,
that's extra, that's extra stuff.
I don't care or make it easy for me.
And I think that's another way
that the design tooling platform
can really help is to say, yeah, we'll,
we'll actually give you the guardrails,
as you say. We will.
And you can see
as you're designing, right?
So it's not an extra governance
check that we have to do afterwards
and I think that's just awesome.
You know, that that that kind of thing
really makes it easy for development teams
to to make sure they're doing the quality,
not leaving things out,
because the onus shouldn't be on them for
a lot of that stuff they want to get on.
And do they actually do the API design
for the, you know, what the behavior is
and what the API, the data,
the capability of the API is providing?
Yeah, I think back to, you know,
like nearly ten years ago
doing this kind of stuff
as a practitioner and PayPal and like,
yeah, you got to like write
all these crazy standards
and I'll tell you like how it played out
in reality was yeah,
you got a bunch of standards, bunch stuff
no one's going to read.
So what are you going to do?
You got to go set up training workshops,
you got to run Everybody through it.
Right, Right.
And sort of explain
all the here's what happens
if you don't do this stuff right.
Here's
the things that we're protecting you from
and why this
these sort of standards are important.
Yeah, but then it's like,
you know, if you say, well, let's use,
you know, open API
or whatever to specify it,
well now you got to do a multi day
training course on how to do that, right,
in a lot of cases.
So it's like I think, you know, obviously
supply work pretty convinced
of the things that you're saying,
but it's like
kind of what these things are
once you see it, you can't unsee.
It is like, cool, I'm designing something.
I see where there's errors,
I fix them as I go
and by the time I commit it, I know it
matches at least 80% of the standards.
There would be some intricacy
that we can automate.
But yeah, I mean, it's been wild.
It's not by watching Spectral
just be everywhere in the last few years
because it's it's
just that it's like once you've done it
you go, Why would I do that the other way?
Yeah, that's right. Yeah.
Scratching your head or worse. Yeah.
Just go build something one off and then
before you're ready to launch, go.
Okay.
How does this match up with standards?
Like, Oh, my God,
this is the way to do it.
Now, that is expensive and it's risky.
You know,
it's operational risk because, you know,
if you're leaving out default security or,
you know,
you could get quite sophisticated
at it in well, if you're building an API,
for example, that has personally
identifiable information in it,
you know, using things like tags
and classification, you could even
and I've worked on a project
like this too, where you could
say, well, actually,
if if we see that type of metadata,
you have to have such and such
security policy for your API, right?
And started again, it's it's automation,
but it's actually governance as well.
You know, and that's the thing like no see
CIO or CTO wants to pay for governance,
you tell them that and they'll just like,
yeah, point to the door.
So you're like, That's something
you should just be doing and having
those tools and having the specifications
and the standards
make it, make it a lot easier to do it,
I guess these days.
How are you seeing?
I don't know.
It's like I feel like I have to
I have to stay up to speed on these things
because I haven't been a practitioner
in a couple of years now
and we talk to them a lot.
But, you know,
I always ask
is like developing these standards
and sort of getting it, you know, spread
out through the organization
and that sort of thing.
Like, what are you seeing
sort of organizationally?
And I mean, we've touched on
some of the tooling side, but like how
how should people think about organizing
in a way that makes
that sort of work
and not be, to your point, a big expense?
Yeah, that's a that's an interesting one.
I quite like the idea and this comes back
to organizational factors
now, because the example I gave before
where the company I talked
to yesterday where they're like, Oh,
everyone's doing it in a different way.
We have no way to understand
where they are in the lifecycle.
You know,
we can't impose or, you know, we don't
we don't know whether they're
following the guidelines and the standards
you need people who can can help teams
to understand, like you said,
why they need to do it in the first place,
the types of improvements we're going
to get and benefits we're going to get.
And then
but also how to onboard those teams
in a way that's easy for them,
for them to do it.
So I like to talk about like an API guild
or an API lead team, for example,
and those people
can be really instrumental in getting
delivery teams within, let's say,
a line of business or capability area.
But what they can also do
is then join up across the enterprise
and share their experiences
and be the ones who are making sure
that teams are onboarded in the right way
so that, you know,
you go from one end of the enterprise
to the other and people say,
Yeah, no, I'm familiar with the enterprise
development lifecycle
and I know how APIs work
within that lifecycle and I've got ways
to make that easier for me.
So so I think that having that team
that sits across
but they're not,
they're not like an offshoot.
I've also worked
in kind of like Centers of Excellence or
enterprise data architecture teams,
where that was our responsibility.
But once again, the danger is
everyone tells you to go away.
You know, don't don't it sounds good, but,
you know, I got to deliver.
So Lenny alone, you know, with that
with the guild approach to be
these people are actually embedded
in those parts of the organization
and so they can make the change happen.
And as I say, also work
across the organization to
to make it better and see improvements
and make sure the teams can get
on board quickly.
Yeah, I feel like sometimes
organizational leaders sort of look back
at that past approach of like center
of excellence, where you might need
some central team of 50 people to manage,
you know, what's going on.
But it's like what you're describing
we usually call like a
federated enablement type approach
so that if you're sort of
sharing that responsibility,
but that somebody is sort of curating
the bigger picture of standards and stuff.
And it's stunning sometimes to me
how often like, you know, 20, 30,000
people, companies can have like one
or two full time people that manage that.
Yeah, because it's fanned out.
But I'm curious like,
you know, that sort of central team
that you're talking about,
I mean, have you seen
that be sort of a large thing
and work well,
or are they usually pretty small?
They're pretty.
They're pretty small, yeah.
Like you said,
you don't want too many people
being pulled off
their their day job doing it.
But what I like what you said there about
Federated, because you can have within
each part of the organization, you would
have a few key people who can help guide.
And really what you're driving for
is self-sufficiency.
So you don't need that team.
You don't need a bottleneck
where everything has to go through them.
The the API practices
are actually starting to scale out
and kind of like you said about the API
as a product, which is exciting.
I'm starting to see that now too,
because a center of excellence is great,
but it's more about evangelizing,
it's more about,
you know, kind of making people aware.
Yeah, and I think people get confused
about that.
Like, what's the difference
between a CEO and a center of excellence?
And for me,
having worked in large enterprises
all my career, you just
you just don't want bottlenecks.
You just don't.
And you need and you don't want this
disassociated team who's trying to get
everybody together and do the right thing
without having any skin in the game.
You know, it's not to work.
Yeah, Yeah.
I mean, but it's I guess for sort
of unpacking this whole like design
first thing a bit here that a lot of what
we're describing of like
a fan of the responsibility and, you know,
kind of have this federated approach,
like if you don't have
that sort of design time
enforcement of governance and standards
kind of stuff, it's pretty hard to do.
Yeah, because then you sort of overwhelm
everybody with too many things to learn.
Yeah, right, Right.
Yeah, I like it.
I like the notion of API enablement
as a service,
especially if your platform is API
first or API enabled, you know,
because we do that in a way we think about
how can we make sure that the APIs
within our own platform can make it
play nicely
with lots of other platform components
within the lifecycle, you know, so taking
that API approach the whole way through
and then being able
to drive the lifecycle from that with
and I, I can't emphasize enough
like the design at the, at the core of it,
you know, it's really where the business
and the and the technical delivery meets.
All right.
So there's it's
I don't know if you've watched a bit,
you may already expect that
I'm going to ask it but we generally do
is like for someone listening
that might go wow that's a lot of stuff
you know,
is there like an easier place
or like a sensible place
out of all these things that you described
or that we should focus on first?
That's the most important
out of all these things.
Yeah, I think I think focus on the teams
that are currently doing APIs pretty well
and then start to add in this kind
of guild approach or this lead team.
So take those people because that's,
that's really the way it works.
Usually when I see it is like
you've got teams who are really doing this
in a good way or an efficient way,
but those are the people who can then
drive the different changes
that can lead to this
API first
approach and set and scale it out.
So I would always start as organization
first, you know, instead of
getting the tooling in place
first
and then think about how you can have
those people work together
to kind of program around it,
have an API program
where people can be managing a roadmap
and getting teams onboarded the right way.
Cool. Well,
I guess, you know, beyond kind of the
where to get started thing,
I guess any other, you know, stuff
that you want to highlight for listeners
here, any other sort of closing thoughts.
Yeah, I just say, you know, you know,
think about you consumers
think about who's consuming the APIs
and then focus on design.
And that program governance,
I would say, is like
get people aligned and get the business
people involved.
Know that those those things all together
will ensure that your API strategy
is going to be a success.
I think that's, that's, that's
what I've seen.
Yeah. Yeah.
I couldn't agree more of it.
Brian
thank you so much for sharing with us.
Thanks, Jason.
Yeah, thanks for having me on.
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.