April 20, 2023 • 26 mins
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).
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
I’m your host Jason as always.
And todaywe 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, certainlyat Stoplight with the team over at Axway.
They're a sort of catalyst team,you know, “DevRel-y” kind of stuff.
(00:45):
But I guess tell us a little bit more
about kind of what you do thereand kind of how that works with Axway.
Sure. Yeah.
We formed this team called the CatalystTeam is really Axway’s dedication
to being able to help customerswith their API management
journey, their API delivery journey,
and really making sure that that alignswith their business goals.
(01:06):
A lot of what happened before that, like,like a lot of tech companies,
you kind of focus on what the platform cando, what the technology can do.
And because, you know, we had peoplewho like myself, are really from more
like a practitioner architecturebackground,
enterprise architecture background,but also people who had sometimes
worked in roles that were one footon the business side of things.
(01:27):
It allows us to really have differentconversations 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, orit might be the people who have the remit
to get the tech in-house or hostedif it's a cloud,
if they're moving to the cloudand having it on a managed cloud option.
(01:50):
Those are the people who are reallyfocused on technical objectives.
So what we realizedis 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 seelots of different customers across lots
(02:11):
of different industries and really usethat 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 termsof organizational alignment.
Operationalizing your API strategy,How can you make it easier for teams
to get on board with the strategyand then being able to track and measure
(02:31):
the success?
Those are all things that that, you know,the catalysts are there to help
our customers do in order to sustainand protect the investment, really.
Now my assumption
is that actually predominantly workswith 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
(02:52):
I mean, we certainly have heard thata lot on the show here.
And certainly we've seen that with stufflike customers is how often like you
I can think of,
you know, platform and APIsas some sort of technical challenge
and it's just not even closeto the top of the list as it
like that whole business alignmentpiece is crazy to me how fast
and it's like, you know,how does your business work?
(03:13):
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 everythingan API, say, oh, hold on a second.
Yeah. Yeah, exactly.
So then I guess in some senseyou're providing some sort
of strategicconsulting with some of your customers?
Yeah, that's that's true.
(03:33):
We have a set of offerings where we can dothese kind of light engagements.
You know, the other thing to sayis we're not like a big consultancy,
so we're not looking to get in thereand flood the place with with people.
What we really want to do is getget our customers self-sufficient
so their teams can do the API delivery.
They can manage it, but they're doing itin a collaborative way where, you know,
(03:56):
you avoid some of the big problems,like duplication of APIs,
being able to get peopleto have self-service for API.
So a lot of our customerstalk about the citizen integrator,
you know, being able to package up APIsand what you just said,
they're JSON is key to thatbecause if people are looking
and searching, discovering the APIsin, let's say an API marketplace,
(04:20):
if it's just a bunch of tech stuffwith a bunch of endpoints
and some cryptic stuffin 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 inconsistencyof of the way the teams are doing API.
(04:41):
So you have a real variation of quality.
I was talking to a company yesterdayand 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'redoing them in so many different ways.
And when we start to look
cross-functionally across the organizationon the enterprise, it's
hard to really startto combine these APIs together and build
something useful because everybody'sdone it in a different way.
(05:04):
And then that adds up to timespent, right, which is cost.
So how can we get people to findthe right stuff, be able to compose
the right applicationcapabilities using APIs?
That's really where wherewe want to focus.
Who is it that you're like?
Typically meetingwith in these sorts of things?
I mean, you know, there's sort of the,you know, management sponsor types
(05:25):
who quite often, you know,it's like they read in a business journal,
they should do APIsand they said go or something, right?
Then you've got like,you know, your run of the mill sort of,
you know, principal architect typeswho are trying to build out domains,
like how often is theresort of dedicated product or technologists
for that sort of platform,wider view, like, you know,
who is it that you're working withon this big picture?
(05:45):
Yeah, the exciting thing isthat it's starting to happen.
So we're starting to have organizationsmoving to this product organization.
One pharmaceutical companythat we're working with,
we just happened to start helping themwith their API strategy and program
at a time when they were already startingto think about reorganizing
their technology teams along product linesrather than systems.
(06:09):
So previously you might have like,Oh, we're the SAP guys, you know, So we,
we just manage this, this kind of back endand 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.
(06:30):
And I think it gives them a chanceto really see their place
and start to start to getsome 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 morewith the technical objectives.
So you start talking to themabout business capabilities and composable
business architectureand using APIs as products.
(06:53):
And, you know, it's kind of
would kind of go over their headsbecause say, Hey,
I just need to get this thing upand running.
Don't talk to me about thatstuff. We'll do the strategy later.
It's like, I need to get everyoneusing 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 nowis because we are engaging
(07:15):
with a lot of peopleon the digital strategy side, whether it's
banking or transportation or, you know,the really big digital initiatives.
And those are the peoplethat we love to engage with.
And we're starting to see it more and morebecause they can own the roadmaps,
they can start to say, Hey,we got bits of our business
that we really thinkwe could unlock some value here with APIs.
(07:38):
And of course you're startingto see enterprises
looking at the monetizationor commercialization of APIs.
So that's another way to engagewith digital strategy.
People who really see this
as a business opportunityto open new revenue channels or build
a bigger ecosystem with their partnersand actually charge for it
and make some moneyfor the business off of APIs.
(08:02):
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'skind 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 givethe marching orders. Right.
You need, you know, a bunch of peopleunder that who are saying, oh, what the
(08:22):
what the hellare 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 evolveand the product management combined
with delivery management for the APItechnology side, the implementation side.
Yeah, Yeah.
We've definitely seen the trend of sortof API product manager titles popping up
now in a way that even two years agoyou didn't see that same way.
(08:45):
And we've seen examples too of like the,the practice of sort of designing
an API from scratchis actually in some places
being conducted by product managers,even though they don't have any
technical background.
But like kind ofthe guardrails are put up in such a way
that they're able to sort of designsomething, pass the tests,
and it should be close enoughthat the team can massage from there.
(09:06):
Yeah.
To me,that's been like just, wow, finally.
Right? Right.
The Holy Grail being the way for a decadeand maybe it's finally starting to.
Yeah, definitely.And a couple of things on that.
I mean, one thing is convergingon a common definition of value,
and that's where I thinka lot of the technology people struggle.
I certainly remember throughout my career,you know, trying to the technology team
(09:29):
and think aboutwhat is the value of what I'm doing here.
Like what?
What is going to move the needlefor the business or not?
How are we going to track it?
Are we going to just have a bunchof operational metrics in our API platform
that we have tothen piece together and make sense of it?
You know, it's really hard,
which is effectively to do thatif you haven't thought about that upfront.
So a lot of what we talk aboutin the lifecycle
(09:50):
that really talks about API lifecyclebecause it is,
but there are lots of differentthere are three real lifecycles going on.
There's the business operations peoplecoming up with the ideas, the innovation,
the applications, the functionalityand 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 automateand deliver consistently and continuously.
(10:16):
And that missing pieceis that product operations piece.
And that's really opportunitywhere the business product
people and the technology productpeople come together.
So we do things like, Hey, why don'tyou guys before you even start, well,
before you
even decide it is going to be an APIbecause it's the other thing that happens,
build me an API to get X datafrom this back end system.
(10:39):
You know, it's like, Well,
hold on, let's just talk about the valueproposition of this.
First.
People like Amancio Busahave been talking about this for for ages.
There are lots of peoplewho 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
(10:59):
out on a canvas for the value propand think about what you're solving for.
Think about the pains, the gains,
think about whatthe tasks that people have to do.
And then from there
you can decide actuallyan API would be perfect for this, right?
And that gets you away from the
we're just a call center where someone'sordering me to make a little Lego brick
(11:20):
and connectA to B, where you can as a technology
team, you can actually start to growand developers can feel an API
designer is going to feel likethey're more part of the business effort.
You know?
So that's cool.
And that actually informs the API design.
So having somethinglike a value proposition, which then leads
(11:41):
to maybe like user stories and thingslike that, but start even further back
where people are converging on that commondefinition 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 thinkit's a great way to inform your design
and make sure you don't have to redo itor you've missed a whole bunch of stuff
(12:01):
or you've misseda whole bunch of consumers
that you could have thought of upfrontas well.
And again, you know that that wayyou don't build it just for one API
consumer where the next one comes alongand you've got to completely rework it.
You spend a whole bunch of timeand money doing that and you got real
true reusable API components and products.
(12:22):
Yeah, to stretch your Lego metaphor,it's like building standard shaped Legos
rather than those those licensedbranded 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 upa bit like that initial engagement
(12:42):
which more and more should be ledby product is to some extent about
what is the reusability, how does this fitinto the bigger portfolio,
which is, is like even beforeperhaps you're even dealing with
like what are our conventions or likehow do we do our best stuff?
Isn't even that relevantat that phase, Right?
Yeah, absolutely.
I think it's more about your roadmap.
(13:03):
Yeah, we did engagement last yearwith a regional bank in the US and it,
it is a kind of a beautifuland I feel like I'm being corny now,
but it's a beautiful thing to beholdwhen the business product manager gets it.
And again, this is where designtooling comes in as well
because you can't do thatif you're all looking at a YAML file
or a Jason expression of an openAPI specification
(13:27):
and the tooling unlocks a lot of thatand I think it really brings it to light,
it makes it real for business peoplebecause 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 documentthat so that the developer, when they do
go to the marketplace,they can go, Oh, I see.
(13:49):
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 commercializationstrategy around API.
So if they can see
how the APIs can be designed in a waythat makes it easy for the consumer
to build that into their own workbenchor their own flow,
(14:12):
then they can really see the valueof what they're delivering for customers.
Yeah, it's
definitely, I think for those of usin 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 theoh well you actually do API product,
you know,now it's like far more commonplace.
(14:33):
But yeah,
I guess if we go back to that lifecyclethinking, right,
that we do all this homeworkon 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 fittingin sort of logically,
(14:53):
is this consistentwith the way we do things?
And I guess what do you see in sort of
consulting engagements as far as how folksset that up and make it work?
Yeah, I think there's a lot of immaturityin that area, but there's always,
you know, in the conversationsI have, there's always this are,
yeah,we really would like to have a common way
for APIteams to do to, to design the APIs.
(15:16):
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 goodattempts to come up with the style guide.
But then
what's the differences between, okay, I'mgoing 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
(15:38):
so that it's partof like governance by design?
I think that's that's reallywhat a lot of people I'm talking
to are interested in is,yeah, you know, the
the guidelines and the conventionsand 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.
(15:59):
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 waythat 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 seeas you're designing, right?
(16:20):
So it's not an extra governancecheck that we have to do afterwards
and I think that's just awesome.
You know, that that that kind of thingreally 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 fora lot of that stuff they want to get on.
And do they actually do the API designfor the, you know, what the behavior is
(16:40):
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 stuffas a practitioner and PayPal and like,
yeah, you got to like writeall these crazy standards
and I'll tell you like how it played outin reality was yeah,
you got a bunch of standards, bunch stuffno one's going to read.
So what are you going to do?
(17:00):
You got to go set up training workshops,you got to run Everybody through it.
Right, Right.
And sort of explainall the here's what happens
if you don't do this stuff right.
Here'sthe things that we're protecting you from
and why thisthese sort of standards are important.
Yeah, but then it's like,you know, if you say, well, let's use,
you know, open APIor whatever to specify it,
well now you got to do a multi daytraining course on how to do that, right,
in a lot of cases.
(17:21):
So it's like I think, you know, obviouslysupply work pretty convinced
of the things that you're saying,but it's like
kind of what these things areonce 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 itmatches at least 80% of the standards.
There would be some intricacythat we can automate.
But yeah, I mean, it's been wild.
(17:43):
It's not by watching Spectraljust be everywhere in the last few years
because it's it's
just that it's like once you've done ityou 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 thenbefore 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.
(18:05):
You know,
it's operational risk because, you know,if you're leaving out default security or,
you know,
you could get quite sophisticatedat it in well, if you're building an API,
for example, that has personallyidentifiable information in it,
you know, using things like tagsand classification, you could even
and I've worked on a projectlike this too, where you could
(18:26):
say, well, actually,if if we see that type of metadata,
you have to have such and suchsecurity 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 seeCIO or CTO wants to pay for governance,
you tell them that and they'll just like,yeah, point to the door.
(18:48):
So you're like, That's somethingyou should just be doing and having
those tools and having the specificationsand 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 thingsbecause I haven't been a practitioner
in a couple of years nowand we talk to them a lot.
But, you know,
I always ask
is like developing these standardsand sort of getting it, you know, spread
(19:12):
out through the organizationand that sort of thing.
Like, what are you seeingsort of organizationally?
And I mean, we've touched onsome of the tooling side, but like how
how should people think about organizingin a way that makes
that sort of workand 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 backto organizational factors
(19:34):
now, because the example I gave beforewhere the company I talked
to yesterday where they're like, Oh,everyone's doing it in a different way.
We have no way to understandwhere they are in the lifecycle.
You know,we can't impose or, you know, we don't
we don't know whether they'refollowing the guidelines and the standards
(19:54):
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 goingto get and benefits we're going to get.
And thenbut 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 guildor an API lead team, for example,
(20:16):
and those peoplecan be really instrumental in getting
delivery teams within, let's say,a line of business or capability area.
But what they can also dois then join up across the enterprise
and share their experiencesand be the ones who are making sure
that teams are onboarded in the right way
so that, you know,
(20:36):
you go from one end of the enterpriseto the other and people say,
Yeah, no, I'm familiar with the enterprisedevelopment lifecycle
and I know how APIs workwithin that lifecycle and I've got ways
to make that easier for me.
So so I think that having that teamthat sits across
but they're not,they're not like an offshoot.
I've also workedin kind of like Centers of Excellence or
(20:58):
enterprise data architecture teams,where that was our responsibility.
But once again, the danger iseveryone 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 thatwith the guild approach to be
these people are actually embedded
in those parts of the organizationand so they can make the change happen.
(21:20):
And as I say, also workacross the organization to
to make it better and see improvementsand make sure the teams can get
on board quickly.
Yeah, I feel like sometimesorganizational leaders sort of look back
at that past approach of like centerof 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 describingwe usually call like a
(21:44):
federated enablement type approachso that if you're sort of
sharing that responsibility,
but that somebody is sort of curatingthe bigger picture of standards and stuff.
And it's stunning sometimes to mehow often like, you know, 20, 30,000
people, companies can have like oneor two full time people that manage that.
Yeah, because it's fanned out.
(22:05):
But I'm curious like,
you know, that sort of central teamthat you're talking about,
I mean, have you seenthat 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 offtheir their day job doing it.
But what I like what you said there aboutFederated, because you can have within
(22:26):
each part of the organization, you wouldhave a few key people who can help guide.
And really what you're driving foris self-sufficiency.
So you don't need that team.
You don't need a bottleneckwhere everything has to go through them.
The the API practicesare actually starting to scale out
and kind of like you said about the APIas a product, which is exciting.
(22:49):
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 confusedabout that.
Like, what's the differencebetween a CEO and a center of excellence?
And for me,having worked in large enterprises
all my career, you justyou just don't want bottlenecks.
You just don't.
(23:09):
And you need and you don't want thisdisassociated team who's trying to get
everybody together and do the right thingwithout having any skin in the game.
You know, it's not to work.
Yeah, Yeah.
I mean, but it's I guess for sortof unpacking this whole like design
first thing a bit here that a lot of whatwe're describing of like
a fan of the responsibility and, you know,kind of have this federated approach,
(23:31):
like if you don't havethat sort of design time
enforcement of governance and standardskind of stuff, it's pretty hard to do.
Yeah, because then you sort of overwhelmeverybody with too many things to learn.
Yeah, right, Right.
Yeah, I like it.
I like the notion of API enablementas a service,
especially if your platform is APIfirst or API enabled, you know,
(23:55):
because we do that in a way we think about
how can we make sure that the APIswithin our own platform can make it
play nicelywith lots of other platform components
within the lifecycle, you know, so takingthat API approach the whole way through
and then being ableto drive the lifecycle from that with
(24:17):
and I, I can't emphasize enoughlike the design at the, at the core of it,
you know, it's really where the businessand the and the technical delivery meets.
All right.
So there's it'sI don't know if you've watched a bit,
you may already expect thatI'm going to ask it but we generally do
is like for someone listeningthat might go wow that's a lot of stuff
(24:38):
you know,
is there like an easier placeor like a sensible place
out of all these things that you describedor that we should focus on first?
That's the most importantout of all these things.
Yeah, I think I think focus on the teamsthat are currently doing APIs pretty well
and then start to add in this kindof guild approach or this lead team.
(25:00):
So take those people because that's,that's really the way it works.
Usually when I see it is likeyou'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 changesthat can lead to this
API firstapproach and set and scale it out.
So I would always start as organizationfirst, you know, instead of
(25:21):
getting the tooling in place
first
and then think about how you can havethose people work together
to kind of program around it,have an API program
where people can be managing a roadmapand getting teams onboarded the right way.
Cool. Well,
I guess, you know, beyond kind of thewhere to get started thing,
(25:41):
I guess any other, you know, stuff
that you want to highlight for listenershere, any other sort of closing thoughts.
Yeah, I just say, you know, you know,think about you consumers
think about who's consuming the APIsand then focus on design.
And that program governance,I would say, is like
get people aligned and get the businesspeople involved.
Know that those those things all together
(26:03):
will ensure that your API strategyis going to be a success.
I think that's, that's, that'swhat I've seen.
Yeah. Yeah.
I couldn't agree more of it.
Brianthank 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
(26:25):
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
API Intersection Podcast listenersare invited to sign up for Stoplight
(26:46):
and save up to $650is the code intersection tend
to get 10% off a new subscriptionto stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
I'm JasonHarmon and this is API intersection
where you'll get insights from experiencedAPI practitioners to learn best
practices on thingslike API design, governance, identity,
versioning and more.
(00:22):
Welcome back to API Intersection.
I’m your host Jason as always.
And todaywe 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, certainlyat Stoplight with the team over at Axway.
They're a sort of catalyst team,you know, “DevRel-y” kind of stuff.
(00:45):
But I guess tell us a little bit more
about kind of what you do thereand kind of how that works with Axway.
Sure. Yeah.
We formed this team called the CatalystTeam is really Axway’s dedication
to being able to help customerswith their API management
journey, their API delivery journey,
and really making sure that that alignswith their business goals.
(01:06):
A lot of what happened before that, like,like a lot of tech companies,
you kind of focus on what the platform cando, what the technology can do.
And because, you know, we had peoplewho like myself, are really from more
like a practitioner architecturebackground,
enterprise architecture background,but also people who had sometimes
worked in roles that were one footon the business side of things.
(01:27):
It allows us to really have differentconversations 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, orit might be the people who have the remit
to get the tech in-house or hostedif it's a cloud,
if they're moving to the cloudand having it on a managed cloud option.
(01:50):
Those are the people who are reallyfocused on technical objectives.
So what we realizedis 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 seelots of different customers across lots
(02:11):
of different industries and really usethat 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 termsof organizational alignment.
Operationalizing your API strategy,How can you make it easier for teams
to get on board with the strategyand then being able to track and measure
(02:31):
the success?
Those are all things that that, you know,the catalysts are there to help
our customers do in order to sustainand protect the investment, really.
Now my assumption
is that actually predominantly workswith 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
(02:52):
I mean, we certainly have heard thata lot on the show here.
And certainly we've seen that with stufflike customers is how often like you
I can think of,
you know, platform and APIsas some sort of technical challenge
and it's just not even closeto the top of the list as it
like that whole business alignmentpiece is crazy to me how fast
and it's like, you know,how does your business work?
(03:13):
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 everythingan API, say, oh, hold on a second.
Yeah. Yeah, exactly.
So then I guess in some senseyou're providing some sort
of strategicconsulting with some of your customers?
Yeah, that's that's true.
(03:33):
We have a set of offerings where we can dothese kind of light engagements.
You know, the other thing to sayis we're not like a big consultancy,
so we're not looking to get in thereand flood the place with with people.
What we really want to do is getget our customers self-sufficient
so their teams can do the API delivery.
They can manage it, but they're doing itin a collaborative way where, you know,
(03:56):
you avoid some of the big problems,like duplication of APIs,
being able to get peopleto have self-service for API.
So a lot of our customerstalk about the citizen integrator,
you know, being able to package up APIsand what you just said,
they're JSON is key to thatbecause if people are looking
and searching, discovering the APIsin, let's say an API marketplace,
(04:20):
if it's just a bunch of tech stuffwith a bunch of endpoints
and some cryptic stuffin 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 inconsistencyof of the way the teams are doing API.
(04:41):
So you have a real variation of quality.
I was talking to a company yesterdayand 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'redoing them in so many different ways.
And when we start to look
cross-functionally across the organizationon the enterprise, it's
hard to really startto combine these APIs together and build
something useful because everybody'sdone it in a different way.
(05:04):
And then that adds up to timespent, right, which is cost.
So how can we get people to findthe right stuff, be able to compose
the right applicationcapabilities using APIs?
That's really where wherewe want to focus.
Who is it that you're like?
Typically meetingwith in these sorts of things?
I mean, you know, there's sort of the,you know, management sponsor types
(05:25):
who quite often, you know,it's like they read in a business journal,
they should do APIsand they said go or something, right?
Then you've got like,you know, your run of the mill sort of,
you know, principal architect typeswho are trying to build out domains,
like how often is theresort of dedicated product or technologists
for that sort of platform,wider view, like, you know,
who is it that you're working withon this big picture?
(05:45):
Yeah, the exciting thing isthat it's starting to happen.
So we're starting to have organizationsmoving to this product organization.
One pharmaceutical companythat we're working with,
we just happened to start helping themwith their API strategy and program
at a time when they were already startingto think about reorganizing
their technology teams along product linesrather than systems.
(06:09):
So previously you might have like,Oh, we're the SAP guys, you know, So we,
we just manage this, this kind of back endand 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.
(06:30):
And I think it gives them a chanceto really see their place
and start to start to getsome 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 morewith the technical objectives.
So you start talking to themabout business capabilities and composable
business architectureand using APIs as products.
(06:53):
And, you know, it's kind of
would kind of go over their headsbecause say, Hey,
I just need to get this thing upand running.
Don't talk to me about thatstuff. We'll do the strategy later.
It's like, I need to get everyoneusing 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 nowis because we are engaging
(07:15):
with a lot of peopleon the digital strategy side, whether it's
banking or transportation or, you know,the really big digital initiatives.
And those are the peoplethat we love to engage with.
And we're starting to see it more and morebecause they can own the roadmaps,
they can start to say, Hey,we got bits of our business
that we really thinkwe could unlock some value here with APIs.
(07:38):
And of course you're startingto see enterprises
looking at the monetizationor commercialization of APIs.
So that's another way to engagewith digital strategy.
People who really see this
as a business opportunityto open new revenue channels or build
a bigger ecosystem with their partnersand actually charge for it
and make some moneyfor the business off of APIs.
(08:02):
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'skind 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 givethe marching orders. Right.
You need, you know, a bunch of peopleunder that who are saying, oh, what the
(08:22):
what the hellare 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 evolveand the product management combined
with delivery management for the APItechnology side, the implementation side.
Yeah, Yeah.
We've definitely seen the trend of sortof API product manager titles popping up
now in a way that even two years agoyou didn't see that same way.
(08:45):
And we've seen examples too of like the,the practice of sort of designing
an API from scratchis actually in some places
being conducted by product managers,even though they don't have any
technical background.
But like kind ofthe guardrails are put up in such a way
that they're able to sort of designsomething, pass the tests,
and it should be close enoughthat the team can massage from there.
(09:06):
Yeah.
To me,that's been like just, wow, finally.
Right? Right.
The Holy Grail being the way for a decadeand maybe it's finally starting to.
Yeah, definitely.And a couple of things on that.
I mean, one thing is convergingon a common definition of value,
and that's where I thinka lot of the technology people struggle.
I certainly remember throughout my career,you know, trying to the technology team
(09:29):
and think aboutwhat is the value of what I'm doing here.
Like what?
What is going to move the needlefor the business or not?
How are we going to track it?
Are we going to just have a bunchof operational metrics in our API platform
that we have tothen piece together and make sense of it?
You know, it's really hard,
which is effectively to do thatif you haven't thought about that upfront.
So a lot of what we talk aboutin the lifecycle
(09:50):
that really talks about API lifecyclebecause it is,
but there are lots of differentthere are three real lifecycles going on.
There's the business operations peoplecoming up with the ideas, the innovation,
the applications, the functionalityand 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 automateand deliver consistently and continuously.
(10:16):
And that missing pieceis that product operations piece.
And that's really opportunitywhere the business product
people and the technology productpeople come together.
So we do things like, Hey, why don'tyou guys before you even start, well,
before you
even decide it is going to be an APIbecause it's the other thing that happens,
build me an API to get X datafrom this back end system.
(10:39):
You know, it's like, Well,
hold on, let's just talk about the valueproposition of this.
First.
People like Amancio Busahave been talking about this for for ages.
There are lots of peoplewho 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
(10:59):
out on a canvas for the value propand think about what you're solving for.
Think about the pains, the gains,
think about whatthe tasks that people have to do.
And then from there
you can decide actuallyan API would be perfect for this, right?
And that gets you away from the
we're just a call center where someone'sordering me to make a little Lego brick
(11:20):
and connectA to B, where you can as a technology
team, you can actually start to growand developers can feel an API
designer is going to feel likethey're more part of the business effort.
You know?
So that's cool.
And that actually informs the API design.
So having somethinglike a value proposition, which then leads
(11:41):
to maybe like user stories and thingslike that, but start even further back
where people are converging on that commondefinition 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 thinkit's a great way to inform your design
and make sure you don't have to redo itor you've missed a whole bunch of stuff
(12:01):
or you've misseda whole bunch of consumers
that you could have thought of upfrontas well.
And again, you know that that wayyou don't build it just for one API
consumer where the next one comes alongand you've got to completely rework it.
You spend a whole bunch of timeand money doing that and you got real
true reusable API components and products.
(12:22):
Yeah, to stretch your Lego metaphor,it's like building standard shaped Legos
rather than those those licensedbranded 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 upa bit like that initial engagement
(12:42):
which more and more should be ledby product is to some extent about
what is the reusability, how does this fitinto the bigger portfolio,
which is, is like even beforeperhaps you're even dealing with
like what are our conventions or likehow do we do our best stuff?
Isn't even that relevantat that phase, Right?
Yeah, absolutely.
I think it's more about your roadmap.
(13:03):
Yeah, we did engagement last yearwith a regional bank in the US and it,
it is a kind of a beautifuland I feel like I'm being corny now,
but it's a beautiful thing to beholdwhen the business product manager gets it.
And again, this is where designtooling comes in as well
because you can't do thatif you're all looking at a YAML file
or a Jason expression of an openAPI specification
(13:27):
and the tooling unlocks a lot of thatand I think it really brings it to light,
it makes it real for business peoplebecause 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 documentthat so that the developer, when they do
go to the marketplace,they can go, Oh, I see.
(13:49):
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 commercializationstrategy around API.
So if they can see
how the APIs can be designed in a waythat makes it easy for the consumer
to build that into their own workbenchor their own flow,
(14:12):
then they can really see the valueof what they're delivering for customers.
Yeah, it's
definitely, I think for those of usin 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 theoh well you actually do API product,
you know,now it's like far more commonplace.
(14:33):
But yeah,
I guess if we go back to that lifecyclethinking, right,
that we do all this homeworkon 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 fittingin sort of logically,
(14:53):
is this consistentwith the way we do things?
And I guess what do you see in sort of
consulting engagements as far as how folksset that up and make it work?
Yeah, I think there's a lot of immaturityin that area, but there's always,
you know, in the conversationsI have, there's always this are,
yeah,we really would like to have a common way
for APIteams to do to, to design the APIs.
(15:16):
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 goodattempts to come up with the style guide.
But then
what's the differences between, okay, I'mgoing 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
(15:38):
so that it's partof like governance by design?
I think that's that's reallywhat a lot of people I'm talking
to are interested in is,yeah, you know, the
the guidelines and the conventionsand 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.
(15:59):
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 waythat 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 seeas you're designing, right?
(16:20):
So it's not an extra governancecheck that we have to do afterwards
and I think that's just awesome.
You know, that that that kind of thingreally 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 fora lot of that stuff they want to get on.
And do they actually do the API designfor the, you know, what the behavior is
(16:40):
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 stuffas a practitioner and PayPal and like,
yeah, you got to like writeall these crazy standards
and I'll tell you like how it played outin reality was yeah,
you got a bunch of standards, bunch stuffno one's going to read.
So what are you going to do?
(17:00):
You got to go set up training workshops,you got to run Everybody through it.
Right, Right.
And sort of explainall the here's what happens
if you don't do this stuff right.
Here'sthe things that we're protecting you from
and why thisthese sort of standards are important.
Yeah, but then it's like,you know, if you say, well, let's use,
you know, open APIor whatever to specify it,
well now you got to do a multi daytraining course on how to do that, right,
in a lot of cases.
(17:21):
So it's like I think, you know, obviouslysupply work pretty convinced
of the things that you're saying,but it's like
kind of what these things areonce 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 itmatches at least 80% of the standards.
There would be some intricacythat we can automate.
But yeah, I mean, it's been wild.
(17:43):
It's not by watching Spectraljust be everywhere in the last few years
because it's it's
just that it's like once you've done ityou 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 thenbefore 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.
(18:05):
You know,
it's operational risk because, you know,if you're leaving out default security or,
you know,
you could get quite sophisticatedat it in well, if you're building an API,
for example, that has personallyidentifiable information in it,
you know, using things like tagsand classification, you could even
and I've worked on a projectlike this too, where you could
(18:26):
say, well, actually,if if we see that type of metadata,
you have to have such and suchsecurity 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 seeCIO or CTO wants to pay for governance,
you tell them that and they'll just like,yeah, point to the door.
(18:48):
So you're like, That's somethingyou should just be doing and having
those tools and having the specificationsand 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 thingsbecause I haven't been a practitioner
in a couple of years nowand we talk to them a lot.
But, you know,
I always ask
is like developing these standardsand sort of getting it, you know, spread
(19:12):
out through the organizationand that sort of thing.
Like, what are you seeingsort of organizationally?
And I mean, we've touched onsome of the tooling side, but like how
how should people think about organizingin a way that makes
that sort of workand 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 backto organizational factors
(19:34):
now, because the example I gave beforewhere the company I talked
to yesterday where they're like, Oh,everyone's doing it in a different way.
We have no way to understandwhere they are in the lifecycle.
You know,we can't impose or, you know, we don't
we don't know whether they'refollowing the guidelines and the standards
(19:54):
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 goingto get and benefits we're going to get.
And thenbut 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 guildor an API lead team, for example,
(20:16):
and those peoplecan be really instrumental in getting
delivery teams within, let's say,a line of business or capability area.
But what they can also dois then join up across the enterprise
and share their experiencesand be the ones who are making sure
that teams are onboarded in the right way
so that, you know,
(20:36):
you go from one end of the enterpriseto the other and people say,
Yeah, no, I'm familiar with the enterprisedevelopment lifecycle
and I know how APIs workwithin that lifecycle and I've got ways
to make that easier for me.
So so I think that having that teamthat sits across
but they're not,they're not like an offshoot.
I've also workedin kind of like Centers of Excellence or
(20:58):
enterprise data architecture teams,where that was our responsibility.
But once again, the danger iseveryone 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 thatwith the guild approach to be
these people are actually embedded
in those parts of the organizationand so they can make the change happen.
(21:20):
And as I say, also workacross the organization to
to make it better and see improvementsand make sure the teams can get
on board quickly.
Yeah, I feel like sometimesorganizational leaders sort of look back
at that past approach of like centerof 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 describingwe usually call like a
(21:44):
federated enablement type approachso that if you're sort of
sharing that responsibility,
but that somebody is sort of curatingthe bigger picture of standards and stuff.
And it's stunning sometimes to mehow often like, you know, 20, 30,000
people, companies can have like oneor two full time people that manage that.
Yeah, because it's fanned out.
(22:05):
But I'm curious like,
you know, that sort of central teamthat you're talking about,
I mean, have you seenthat 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 offtheir their day job doing it.
But what I like what you said there aboutFederated, because you can have within
(22:26):
each part of the organization, you wouldhave a few key people who can help guide.
And really what you're driving foris self-sufficiency.
So you don't need that team.
You don't need a bottleneckwhere everything has to go through them.
The the API practicesare actually starting to scale out
and kind of like you said about the APIas a product, which is exciting.
(22:49):
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 confusedabout that.
Like, what's the differencebetween a CEO and a center of excellence?
And for me,having worked in large enterprises
all my career, you justyou just don't want bottlenecks.
You just don't.
(23:09):
And you need and you don't want thisdisassociated team who's trying to get
everybody together and do the right thingwithout having any skin in the game.
You know, it's not to work.
Yeah, Yeah.
I mean, but it's I guess for sortof unpacking this whole like design
first thing a bit here that a lot of whatwe're describing of like
a fan of the responsibility and, you know,kind of have this federated approach,
(23:31):
like if you don't havethat sort of design time
enforcement of governance and standardskind of stuff, it's pretty hard to do.
Yeah, because then you sort of overwhelmeverybody with too many things to learn.
Yeah, right, Right.
Yeah, I like it.
I like the notion of API enablementas a service,
especially if your platform is APIfirst or API enabled, you know,
(23:55):
because we do that in a way we think about
how can we make sure that the APIswithin our own platform can make it
play nicelywith lots of other platform components
within the lifecycle, you know, so takingthat API approach the whole way through
and then being ableto drive the lifecycle from that with
(24:17):
and I, I can't emphasize enoughlike the design at the, at the core of it,
you know, it's really where the businessand the and the technical delivery meets.
All right.
So there's it'sI don't know if you've watched a bit,
you may already expect thatI'm going to ask it but we generally do
is like for someone listeningthat might go wow that's a lot of stuff
(24:38):
you know,
is there like an easier placeor like a sensible place
out of all these things that you describedor that we should focus on first?
That's the most importantout of all these things.
Yeah, I think I think focus on the teamsthat are currently doing APIs pretty well
and then start to add in this kindof guild approach or this lead team.
(25:00):
So take those people because that's,that's really the way it works.
Usually when I see it is likeyou'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 changesthat can lead to this
API firstapproach and set and scale it out.
So I would always start as organizationfirst, you know, instead of
(25:21):
getting the tooling in place
first
and then think about how you can havethose people work together
to kind of program around it,have an API program
where people can be managing a roadmapand getting teams onboarded the right way.
Cool. Well,
I guess, you know, beyond kind of thewhere to get started thing,
(25:41):
I guess any other, you know, stuff
that you want to highlight for listenershere, any other sort of closing thoughts.
Yeah, I just say, you know, you know,think about you consumers
think about who's consuming the APIsand then focus on design.
And that program governance,I would say, is like
get people aligned and get the businesspeople involved.
Know that those those things all together
(26:03):
will ensure that your API strategyis going to be a success.
I think that's, that's, that'swhat I've seen.
Yeah. Yeah.
I couldn't agree more of it.
Brianthank 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
(26:25):
platform you're viewing or listening onand there should be a link there
so you can go submit a questionand we'll do our best to find out
the right answer for you.
API Intersection Podcast listenersare invited to sign up for Stoplight
(26:46):
and save up to $650is the code intersection tend
to get 10% off a new subscriptionto stoplight platform starter or pro.
Take a look at this episode'sdescription for more details.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.