API Intersection

This week on the API Intersection podcast, we interviewed Brian Otten, Vice President of Digital Transformation Catalysts for North America at Axway. Axway is an organization devoted to helping customers with their API management and digital transformation journey. Brian’s team provides strategic consulting services to large enterprise customers and helps customers get active in their API journey. 

Brian’s team focuses on advising customers on how to avoid API duplication, self-service for APIs, and packaging API products for other integration purposes. Here are some of the most common challenges he helps advise teams through, and you might recognize some of these challenges on your own API team! 

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.

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

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.


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?



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.


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.


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


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,

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.

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.

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


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.

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.