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, auth, versioning and more.
Welcome back to API Intersection.
I'm Jason, your host as always.
And today we have a guest from Discover
Financial Services, George Mitry.
George and I have hung out a bit before
but still get to know each other here.
So George,
tell us a little bit about yourself
and what you do at Discover.
Hi Jason, Good morning. Good afternoon.
Yeah, I
have been
it was this cover for quite some time now.
I founded the API program at Discover
and Discover
has changed a lot over the years
and it's it's one of the best place
to work in technology in the U.S.
and in the UK as well.
We have recently joined
the Linux Foundation Open Source,
the FinOS Foundation again, open source
and it's a very exciting place
to work at it
and the API making it even more exciting.
And, and it's my passion at Discover here.
I do run the API Center for Enablement,
and with that we do have
external and internal APIs, right?
So for example,
when you go with Discover Financial,
when you're checking out an Amazon
and you find your cashback
bonus reward to pay with your cashback
bonus or your bonus balance
and all the
that goes through the external APIs
from Discover, for example,
and I have my Samsung phone here.
If I'm adding my card to my Samsung,
for example,
that goes through an API
for the Samsung pay, for example, right?
So that's the, the, the external API
as a financial service
free partner with a lot of merchants of
B2B partnerships through APIs, it's
very easy to partner with discover,
differentiate itself
as easy to partner with, differentiate it
from other competitors.
It's quite very large.
And then on the internal APIs,
we do have a very large program,
about 1500 APIs
and microservices
that mix up the internal capabilities
within Discover, and
we can talk
lot about that, how we came about
managing and having that catalog
and making sense out of that catalog.
So that's that's a quick, you know,
look for
what we do here at the Scott.
Very cool.
Well, I'll just say plainly,
I think you're on the right podcast.
This is yeah, talking shop on API.
Governance is probably the most common
thing we do here, having done
a bit of kind of time in FinTech, myself
at PayPal and Braintree.
It's, it's different, right?
It's a little a little uptight compared to
some other industries you could work in.
So I guess I'm curious, you know, in terms
of setting up the governance stuff,
how much sort of, you know,
how much of that effort goes into kind
of the financial specifics?
And I ask this in part because I know
like there's a sweeping movement
through fintech right now
to sort of APAC, everything.
And so I'm sure there's listeners who are
curious, you know, how that scales out.
Yeah, there's within the banking
and financial industry, there is
things are moving very fast
and there's no question about that.
And even though there's
a lot of regulations, a highly regulated
industry, but it's it's, it's the demand,
the increased demand for for speed
and that makes more pressure
on the API strategy and the API programs
and to be able to balance that Right.
And and within the API program security
for example, is top of mind.
Those are the internal
or external security
and I'm sure it's with many other data.
If you're dealing with customer data,
you have to do that.
But now with the extra scrutiny
with the financial regulators
and spend a lot of cycles with auditors
and the feds and all that,
that adds a lot more scrutiny to that
for those processes.
But there's yeah,
the demand is is very high
for being digital
and being transparent about what
we're doing within our controls
and the company.
Yeah, I feel like one of the things that
really opened
my eyes at my time and kind of fintech was
I felt like there was a lack of general
understanding
for folks getting into fintech
that sort of the,
the risk and compliance factors
of getting set up in every country
that is the mountain to climb,
that sort of new entrance go.
We almost got the US figured out.
It's like you're just getting started
and but I'd imagine, you know, working
in a sort of credit card company
like this, that that risk and compliance
factor must be a lot of the time spent.
Right.
And it's a core capability
for those global networks like when
when you're you're really globally ready
and have a footprint
and accepting payments
and all all those countries it makes it's
a no brainer for fintechs to partner
with that kind of scale.
And APIs are really the way to partner.
There's the expectation now as to
where is your API, how can access.
That's right.
And the best API I would want
and you know, if your API are easy to use,
are making sense
on exactly on what the partner wants
and easy to collaborate with.
It becomes a no brainer
to scale into it, to be able to
enter new markets
through those API partnerships.
And we see that a lot.
And some of those expansions and,
and the discussion with with the fintechs.
And the other part of this is also
you touched on Jason earlier about,
you know, how
all the regulation and the pressure,
the regulation is the we need to optimize
the core right in order
to be able to go fast on the outside,
to fast track the external.
We've got to have our act together right
within our internal capabilities
being unlocked because it's
layers of APIs, not just one API.
You want to call her API, going to call
another one to another one, right?
It's a chance kind of right
layers of of other capabilities
that are aggregated together
to mix up a solution
like a Lego piece,
put it together to to build one solution.
So it is
imperative to
have an internal mature
API management program
as well as that will feed
into that external
business
growth and digital transformation.
Yeah, I mean,
I've always kind of described this as like
build your internal
sort of microservice APIs
as though you're preparing
to externalize them
because you never know
when that sort of partnership
opportunity is going to pop up
and you know, some 60 day delivery window,
if you have to go back and redesign
everything to make it
external sizable, you know,
you're going to miss those opportunities.
So but I've noticed in some of the stuff
that you've published, you talk about
sort of treating microservices
and sort of APIs as a different thing,
like maybe
we're on a different perspective here.
So I'd love to hear a little more
about it.
Yeah, So it goes back
to the intention of,
of the microservice architecture
where in its inception
the main investments into a microservice
architecture was
the agility of the team
and getting rid of dependencies
and making sure there's a bounded context
and all of a
self-contained kind of service.
So you can go fast when you need to change
and you need, you know,
all the velocity of the team.
That was the main goal
and that's kind of goes.
I would say you look under the hood
within the internal
working of an application of a capability.
Right now if we define microservice
that way, this is within my own team,
within my own application.
How I'm going to put,
you know, the engine here and, you know,
with this flag here and this, you know,
like this is very internal to my team
and I can change anything in it
without impacting anybody or consumers.
Kind of like outside my bounded
context, my system domain.
Right.
Then APIs comes along.
We say those are boundary APIs.
Those are the one by contract.
I'm going to keep it backward compatible.
I'm going to identify you ahead of time.
I'm going to manage in a different way
the investment.
There is more
of a use now with those APIs.
The concept is to be able to
reuse those APIs
and externalize
those capabilities to the outside world.
So that's kind of the distinction.
Would drone this to level of management
and we have seen that a lot
when we don't have that,
you start to treat all APIs the same way
in terms of scrutiny, governance,
who need to approve.
We need to look,
you know, all these different things
and steam would start to push back,
say this, I'm doing this for my own self,
you know, like I'm just within my
you know, this isn't
and within my there's an iceberg of of the
I strategy.
I differentiate between two disciplines.
It's a multidisciplinary strategy.
There's discipline, disciplinary
discipline of application architecture,
which is the microservices, the breaking
down, the right sizing of the components
within my applications
or the modules within my application.
That's an application
architecture discipline.
And then there is the
the lifecycle management,
the versioning, the you know,
that's an API management discipline
for the lifecycle, for the, for the reuse,
the promoting reuse and promoting
some kind of
a higher level kind of of enterprise level
discipline as opposed to the application
architecture within my, my,
my application walls thing.
So that's, that's where we
so we do the distinction between I'm
sure there are there, there are listeners
there who would say like
why would you only optimize for reuse
for externalizing things?
Shouldn't your internal services
also be sort of optimized for use reuse
with, with,
with a certain scope within the team?
So and it's because of
the are in the catalog.
So there's a visibility into there is
could be some promotion
to say I started this as a microservice
by a will promoted to become
but this on a selective basis so it's not
because of the 91% of the effort.
You know,
I can you know that 1% of the promotable
I don't want to bog down
the management process
and treat everybody with the same speed,
with the same lower speed, you know, so
we can have a fast track for some of those
APIs that we know for now.
We don't overinvest in them
and we know for now the need to go fast
and then when the time comes,
because they're visible,
we can come to them and make them external
as well as is like a balance.
There's always a tradeoff
within those decisions.
What are you optimizing for?
So we want to optimize for reuse
and also for self
kind of contain speed within the team.
So if you want to do both,
you got to have two layers of management.
And also with the newer modern technology,
with the service mesh
and the ingress gateways and all of that,
it starts the infrastructure starts
to reflect that as well.
Within the East-West versus
the North-South traffic,
you start to manage,
you know, when you classify them that way
you could assign security policies
as a network policies differently as well.
So from a design time,
the approval process is different
and then from the runtime
also could be the the,
the network policies
and the security mechanism could be
mapping some of the infrastructure
technologies, native technology, as well.
Yeah, fair enough.
You had mentioned this iceberg of API
strategy.
Really interesting,
but Percy did kind of trying to break down
this, you know, kind of what faces
what's external
to the world
and what sort of internal concerns. And
much in the same way that like you know,
I know like PayPal as an example
like we had you know,
maybe 50 different endpoints
you could use externally
and there was like 5000 internally. Right.
But you're sort of arguing that along
the same lines that there's a whole set of
sort of disciplines
and sort of governance things
you should be doing internally
that aren't really visible outside, but
I don't know, I'm probably mangling your
explanation, so say it better than me.
No, I think it's yeah, the iceberg is like
the little head and stuff behind this,
like the tip of the iceberg is business
transformation.
That's the ultimate goal of our strategy
to get into new market, to get into new
business models
and having the
digital transformation strategy
kind of an API management
underneath the surface.
There's a lot you know, it's
one of the most direct precursors to
the digital transformation.
You got to get better at managing
all those assets and discovering them
and documenting them and securing them
and making sense out of them.
And then being able to access them rapidly
and and puts things together in a
in a high velocity fashion,
connecting the provider
and the consumers together in a way
that makes sense to them.
So there's in order to be able
to orchestrate all that underneath
the water, there is all those different
disciplines as a
as elements or part of the hidden work
that need to be orchestrated.
And I think, you know, one of the things
that we have learned over the years
is that you get out of API strategy
as much as you put into it, right?
So many APIs
programs could be, you know,
if you look at the order of the element
in the iceberg, at the very bottom
there is security and compliance.
Some program is just all about
that, right?
About secure and compliance.
That's a good place to start always.
You know,
there's you have to start somewhere.
So if the focus is security
and compliance,
you're going to get security
and compliance.
But you have not reached
the digital transformation
because that's you put
in, you get out what you put it right.
And then there is the
the right on top of it,
there is the application
architecture piece.
That's what we were talking about.
It's about,
you know, modernization of the stack,
right sizing the module, you know,
eliminating some of the dependencies
within the boundaries of a team
and all that.
Right?
All of that within the application
architecture, discipline.
Then you go a little bit higher.
And if you start to invest
in the lifecycle management
and the reuse and diversion strategy
and making sense and you are having
that kind of log
into taxonomy of APIs, then
now you are getting more and more out
of that strategy once you know.
And then there is the, the ability to
and there's a lot of going on
was discovered the first two years
about the developer enablement.
So it's a learning
organization, teaching organization
to be
able to have like an inner open source
collaborative model
for developers to contribute
and to be able to set
the standards in a collaborative way,
not an ivory tower way.
So that's where we
we call the Center for Enablement,
not a center of excellence, for example.
That's one of the enabler versus
ivory tower ish kind of of excellence,
call center of excellence thing.
And then on top of that, once,
you know, we we tackle
that enablement of the developers
and the teaching organization,
the learning organization,
that machine that spread
and keep evolving all the standard
from the community, community
community pattern and solution
driven patterns and all that,
you start to get into the product centric
and that's a whole set of environment
and the organization.
Every team is a product team.
Now the API strategy can really align
with the business,
can really align
with those products capabilities
that's already out of the boxes
is make it much easier.
Now as I put all the behind the scene,
like the security, the
the modernization of the technology
stack, the the taxonomy
and the lifecycle management and the
the teaching of, you know, all that.
Now I start to get more benefits
as much as I put into the
with the product centricity
right of of of that we can align easily
with the business that way.
And now you get to the tip of the iceberg
which is you know being able to have the
digital transformation
based on all those different disciplines
orchestrated
and working together in one one vision
to for that digital transformation.
Beautifully put.
We've heard all that sort of stuff before,
but I don't think I've ever heard
anyone describe all the layers.
Little design in one shot and made sense.
So much job.
Yeah.
You touched on some of this, like,
you know, this the shift away
from Center of Excellence
and kind of this more federated style
governance, all that sort of stuff.
I loved your recent post
on fallacies of API governance.
I feel like this is where you kind of
went down that rabbit hole a bit
and I love the connection to sort of,
you know, distributed computing
and kind of what we
and the SLA era and all these things
that we should have learned.
But you know, it's like you look around
and sometimes question
if anybody learned anything
or maybe we just forgot.
But yeah, I guess I'm curious,
you know, like, are there sort of high
points in that post that you feel like
we kind of haven't covered here?
Did we just do it?
Yeah. And I think, you know, there's
we talked about the products.
Interesting, right?
And then
that's kind of like the environment
to set teams for success.
You know, two years ago
we started that journey
within this cover
to move from project to product,
and now we're doing the from product
to platform.
The API strategy
is kind of getting into that
and I think some of the
the IT
policies that we've talked about,
I think we are at that mass critical mass
moment in industry where,
you know, there's still the old mindsets
trying to be applied
while we
we have all those thousands and explosion
of the number of APIs
and we don't know what to do with them.
And we keep trying with the same way
as in the past.
And I think there are two main
I see, you know, learning lessons here.
One is the
the open
well, we learn a lot from the open source
community
on how governance is happening
in the open source communities
and how there's a maintainer
and there's open for collaboration and,
and that kind of a mutual win win.
So running the engineering practice
as an inner open source
kind of collaborative model, right?
Maybe the best standard
wins kind of thing, right?
And having the, the openness
to have anybody in the community to
suggest or question
the standard and,
and have the built in mechanism
for teaching the standard
and getting feedback and having those.
So as part of our Center
for Enablement as a community,
we have many of the working groups,
one of the working groups just focused on
standards over for the communities
chaired by enterprise architecture
and many of the
the people are accountable
for the standards.
They are maintaining those standards,
but they are doing it in a fashion
that it's it's it's open collaborative
with every one in the engineering
community to participate.
And that's very helpful
because it's it's when people are
are listened to we evolve much faster
and we we
we shift before we publish that standard.
We know the community already
have a commitment to it, right.
And we can shorten that cycle
of adoption that way.
And it's an open invitation, transparent.
We have our repo get three
or four of the minutes meetings
and all that and anybody can join and all.
So, so all, all that is done in the open.
Right.
And then the other aspect as
is to move from
being like the ivory tower to a teaching
organization, learning organization.
So anybody in the community
as well can teach a pattern,
a solution, They can share their solution,
they're putting it together,
and that can be promoted
to become an enterprise standards.
There's a mechanism to do that.
So the openness and the
the learning organization, that's really
what gets the academy discover technology
internally and externally.
We have discover
technology experience to
discover that come
we published many of those, share
some of those patterns and solutions
to the outside world as well.
So it does have
those two
two aspects out of those policies.
If you want to flip
those forces on their heads now,
you've got to have that machine
learning machine
going coaches, advocacy
and all that as part of the governance.
You see that as part of the governance
is not really separate from that.
And then
you've got the openness, the open model.
So the API governance,
if you think about it now
with all those additions,
it becomes more of a dissertation body
than an enforcement body.
If I think about like the
the hipness ratio on a cash rate
within our processes for approval,
the hipness ratio would be very high
because all the solution would be
based on a solution pattern is on a
something that's everybody committed to
is already built in automation in there.
The community already built something.
Therefore, you know, it's,
you know, so so we can see all
those just passing through
as opposed to handing out exceptions
all the time
and being the enforcement
get late in the game and,
and being the surprise for everybody like,
oh, I didn't know I need to do that.
And, you know, I saw that teaching
organization extremely important
as well as the openness and being able to
do governance through with the open model.
Yeah, beautifully put.
You know,
I've seen it myself and we've heard it
a bunch from practitioners here that like
the technology part
of these transformations isn't the hard
part, it's the cultural change.
And I feel like that's part
of what you were just enumerating.
You know,
there's like,
I'm terrible about having like a one liner
to try to capture an idea
and then I'll just beat that one liner
to death for years.
So I think like it touched on
a bunch of things that I've said a bunch
times is like one, you know,
you can't have transformation
without APIs and a story like this.
That's the core thing, right?
Because that's how you
manifest
this sort of reusable capability mindset.
And then you can't do that
sort of transformative momentum with APIs
if you're not breaking down silos.
And that's kind of what you describe
as this inner source thing, right?
I find like that's one of the parts
that that companies get hung up on.
The worst is just this entrenched
dogma of like,
I have my thing and I protect it
and then I have the contract to integrate
and no one else can touch it.
But to your point,
if it's open enough and it's design
and everybody's working along
the same lines, then why wouldn't
you take contributions from another team
that you have some agreement with?
Right.
Right.
Like, and just getting those habits
changed is so hard.
Right.
And having the you know,
so there's two things here.
One is on on on the code itself.
You're you're adding features
on the cycles of other
you know, you're not using your resources,
you're using open source.
That's that's a Win-Win right?
It's you're maintaining your your product
on somebody else's dime if you
if you people
you know but humans value
a sense of control, right?
So that's in to your point,
it's a culture change to start to think,
oh, no, I'm winning here.
And it's not really I'm losing anything.
It's totally opposite of that.
And then the beauty of what we have done
and discover, I think in the past
two years is that applying this openness
and open source to managing standards
and managing other
you're not just not code but content and,
and and
standards of best practices
and all that, right?
So there's a guild.
We have something, you know, for,
for all those
types of standards
that people can contribute and there's
the, the maintainer of the built
a whole within the academy a whole
cycle lifecycle of those content
and of those patterns and can be reviewed
and updated and all that.
So it is it is fascinating
how many lessons we could learn
from the open source communities.
Yeah.
And how that could be applied
to multiple layers
for sure.
Well, and considering the failure
rate of these things
over the last 510 years, right.
Most like the vast
majority of transformation attempts fail.
So feel like these are the things that we
we beat the drum
a little bit here on the podcast
I think on these exact points
all the time from practitioners.
But it's because it's like problematic
so often.
Like so great advice.
So, you know, I'm
sure there are some listeners
here, let's say, you know, smaller company
just getting the ball rolling
and all this and imagining a future
where, you know, they're
in an organization as big as Discover.
But you know, you rattle off
a long list of stuff you got to do.
So I guess I'm curious for folks
who are looking to just get started,
or maybe they're even in a
larger, older company
that hasn't started modernizing yet.
When you look back on this past few years,
where do you think you would start
to have the biggest impact and kind of get
that momentum swinging the best?
Oh, yeah.
That's that's a good crutch
because for every it's a little bit tricky
because every company is unique
and there's certain constraints
that you have to to work within.
For some that's
yeah, our experience of this covers
too, you know, when we started
like Star Wars security for example,
and that was
I think, a good call to, to start there
because that gives us
the inventory of, of API
when it's when we have a mandate to every
API has to be secured,
it's easy to get the sponsorship
from security, from executives.
It's very easy to to to sell that. It's
easy to justify API security these days
when you dig into breaches, right?
So that's, that's where we could start
and that will help the inventory
because now if you have to secure it,
you have to register it,
you have to, you know,
so there's now a whole inventory
of what you have that's without that,
you can't even do anything like
the beginning of of wisdom.
I call it
a beginning of wisdom is to be able to
I call it like call things by its name,
but if you don't have it,
you don't have it.
You can even call it by its name. Right?
So the inventory is is where I would
start.
And security can give me that inventory.
And then just an interesting approach.
I mean, I definitely have, you know, sort
of seen and heard that before that like,
you know, step
one is like build the catalog.
That's another kind of,
you know, analog,
same kind of intent with the word catalog.
Inventory
is like at least know what you have
and these days everyone's got microservice
sprawl problems.
So it's often a good place to start.
But I love this idea of justifying
and building it through a security lens.
That's fascinating.
Yeah, that's our experience
and how we started.
And we ended up with almost,
I would say, virtually 100% coverage
in all our API business APIs
because there's all the slew
of infrastructure shipyards
that we were not managing now.
But, but it's, it's more of the business
APIs are because they have to be secured.
You know we have that catalog
was virtually
hundred percent coverage
and then we do have the
after the I think
if the organization is already product
centric,
that makes life easier
most targets.
But yeah, it's
just it's much easier to align with.
So you don't have to define
those boundaries yourself as a technology.
And that's one of the pitfalls
to try to technology, try to
define the bounded contexts or what
what you end up
with an engineered experience, don't you?
It's like it's all about the tools
and the technology,
but there's very hard to find business
value later on, right?
So yeah, you mentioned
like sort of grammar vocabulary
kind of stuff before,
which we've heard before.
And I think that's the side of the house
that tends to do better
at defining those things
versus a bunch of engineers
who name things in acronyms and system
names.
Yeah, we talked about this.
Yeah,
like maybe last year when we when we met.
Yeah, that was yeah, that's another thing.
On being really product centric
and having a well understood boundaries
by the business and the technology kind of
the infrastructure
would reflect those boundaries.
That's well understood by the business
and put the, our APIs there.
I think that's, that would be
a good next step
to sort of team for success.
Yeah, it's not a popular term anymore,
but in some ways you're
just describing the old inverse
Conway maneuver right?
Right.
Yeah, it's, it's,
it's only after we've intentionally
flipped the organization on its head
and design it as you want it to be
in the future and then fill in the blanks.
Yeah. So
cool. George Will,
I really appreciate you sharing
all kind of some of these insights.
We already kind of called out,
and I'll just double down.
Check out the Discovery now.
Sorry, Discovery Technology
Academy for Engineers.
You must get the Discovery Discovery thing
a lot.
We do this.
That's okay.
We get spotlighted stoplight all the time.
Any other kind of parting words of wisdom
or our folks that you think
folks should look at for kind of resources
to back this up?
I think it's yeah.
Technology will discover that the car
will have lots of those insights was great
colleagues of mine have discovered
the old publishing.
They're sharing that experience
and contributing to the open source,
the openness model that we were promoting
and discovering and outside.
That would be great.
And that was was really fun
talking with you today.
Jason Yeah, definitely.
It's always,
always a treat to get to talk with folks
running
kind of the program and governance stuff.
It's, you know,
it's a free pass for me to talk shop
and not have to work.
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.