May 4, 2023 • 31 mins
For this week's API Intersection podcast at Stoplight, we interviewed George Mitry at Discover to discuss approaches that can be applied to any business's API program. George is the Expert Application Engineer - API Enablement & Standardization at Discover Financial Services. The Discover team works with over 1,500 external and internal APIs, which are used to provide cash-back bonuses or card payments. Their current focus has revolved around security as a top priority in their API program, as well as increased demand for speed, digitalization, and transparency.
To keep up with the pace of development demand, George and his team must remain agile, product-centric and have well-understood boundaries by the business to set the team up for success. We sat down with George to discover the significant mindset shifts he’s applied to get his business leaders and API team all on the same page.
_____
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:17):
I'm Jason Harmonand this is API Intersection
where you'll get insightsfrom experienced API practitioners
to learn best practices on thingslike API design, governance,
identity, auth, versioning and more.
(00:40):
Welcome back to API Intersection.
I'm Jason, your host as always.
And today we have a guest from DiscoverFinancial Services, George Mitry.
George and I have hung out a bit beforebut 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.
(01:03):
Yeah, I
have beenit 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 placeto work in technology in the U.S.
and in the UK as well.
(01:24):
We have recently joined
the Linux Foundation Open Source,
the FinOS Foundation again, open source
and it's a very exciting placeto work at it
and the API making it even more exciting.
And, and it's my passion at Discover here.
(01:47):
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 Amazonand you find your cashback
bonus reward to pay with your cashbackbonus or your bonus balance
(02:10):
and all thethat 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 APIfor the Samsung pay, for example, right?
So that's the, the, the external API
as a financial servicefree partner with a lot of merchants of
(02:34):
B2B partnerships through APIs, it'svery easy to partner with discover,
differentiate itself
as easy to partner with, differentiate itfrom other competitors.
It's quite very large.
And then on the internal APIs,
we do have a very large program,about 1500 APIs
(02:56):
and microservices
that mix up the internal capabilities
within Discover, and
we can talklot 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,
(03:18):
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 commonthing we do here, having done
a bit of kind of time in FinTech, myselfat PayPal and Braintree.
(03:43):
It's, it's different, right?
It's a little a little uptight compared tosome 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 kindof the financial specifics?
And I ask this in part because I knowlike there's a sweeping movement
(04:05):
through fintech right nowto sort of APAC, everything.
And so I'm sure there's listeners who arecurious, you know, how that scales out.
Yeah, there's within the bankingand financial industry, there is
things are moving very fastand there's no question about that.
And even though there'sa lot of regulations, a highly regulated
(04:26):
industry, but it's it's, it's the demand,the increased demand for for speed
and that makes more pressureon the API strategy and the API programs
and to be able to balance that Right.
And and within the API program securityfor example, is top of mind.
Those are the internalor external security
(04:49):
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 scrutinywith the financial regulators
and spend a lot of cycles with auditorsand the feds and all that,
that adds a lot more scrutiny to thatfor those processes.
But there's yeah,the demand is is very high
(05:11):
for being digitaland being transparent about what
we're doing within our controlsand the company.
Yeah, I feel like one of the things that
really openedmy eyes at my time and kind of fintech was
I felt like there was a lack of generalunderstanding
(05:31):
for folks getting into fintechthat sort of the,
the risk and compliance factorsof 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, workingin a sort of credit card company
(05:52):
like this, that that risk and compliancefactor must be a lot of the time spent.
Right.
And it's a core capabilityfor those global networks like when
when you're you're really globally readyand have a footprint
and accepting paymentsand all all those countries it makes it's
a no brainer for fintechs to partnerwith that kind of scale.
(06:14):
And APIs are really the way to partner.
There's the expectation now as towhere 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 wantsand easy to collaborate with.
(06:38):
It becomes a no brainerto 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
(07:01):
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 orderto be able to go fast on the outside,
to fast track the external.
We've got to have our act together rightwithin our internal capabilities
(07:22):
being unlocked because it'slayers of APIs, not just one API.
You want to call her API, going to callanother one to another one, right?
It's a chance kind of rightlayers of of other capabilities
that are aggregated togetherto mix up a solution
like a Lego piece,put it together to to build one solution.
So it is
(07:44):
imperative to
have an internal matureAPI management program
as well as that will feedinto that external
businessgrowth and digital transformation.
Yeah, I mean,I've always kind of described this as like
build your internalsort of microservice APIs
(08:07):
as though you're preparingto externalize them
because you never knowwhen that sort of partnership
opportunity is going to pop upand you know, some 60 day delivery window,
if you have to go back and redesigneverything to make it
external sizable, you know,you're going to miss those opportunities.
So but I've noticed in some of the stuffthat you've published, you talk about
(08:27):
sort of treating microservicesand sort of APIs as a different thing,
like maybewe're on a different perspective here.
So I'd love to hear a little moreabout it.
Yeah, So it goes back
to the intention of,of the microservice architecture
where in its inceptionthe main investments into a microservice
(08:52):
architecture was
the agility of the teamand getting rid of dependencies
and making sure there's a bounded contextand all of a
self-contained kind of service.
So you can go fast when you need to changeand you need, you know,
all the velocity of the team.
That was the main goaland that's kind of goes.
(09:17):
I would say you look under the hood
within the internalworking of an application of a capability.
Right now if we define microservicethat 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
(09:37):
and I can change anything in itwithout impacting anybody or consumers.
Kind of like outside my boundedcontext, 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 waythe investment.
(09:58):
There is moreof a use now with those APIs.
The concept is to be able to
reuse those APIs
and externalizethose capabilities to the outside world.
So that's kind of the distinction.
Would drone this to level of managementand we have seen that a lot
(10:18):
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 myyou know, this isn't
(10:39):
and within my there's an iceberg of of theI strategy.
I differentiate between two disciplines.
It's a multidisciplinary strategy.
There's discipline, disciplinarydiscipline of application architecture,
which is the microservices, the breakingdown, the right sizing of the components
within my applicationsor the modules within my application.
(11:00):
That's an applicationarchitecture discipline.
And then there is thethe 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
(11:23):
discipline as opposed to the application
architecture within my, my,my application walls thing.
So that's, that's where weso we do the distinction between I'm
sure there are there, there are listenersthere who would say like
why would you only optimize for reusefor externalizing things?
Shouldn't your internal servicesalso be sort of optimized for use reuse
(11:46):
with, with,with a certain scope within the team?
So and it's because ofthe are in the catalog.
So there's a visibility into there iscould be some promotion
to say I started this as a microserviceby a will promoted to become
but this on a selective basis so it's notbecause of the 91% of the effort.
(12:10):
You know,I can you know that 1% of the promotable
I don't want to bog downthe 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 thoseAPIs that we know for now.
We don't overinvest in themand we know for now the need to go fast
(12:33):
and then when the time comes,because they're visible,
we can come to them and make them externalas well as is like a balance.
There's always a tradeoffwithin those decisions.
What are you optimizing for?
So we want to optimize for reuseand 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.
(12:57):
And also with the newer modern technology,
with the service meshand the ingress gateways and all of that,
it starts the infrastructure startsto reflect that as well.
Within the East-West versusthe North-South traffic,
you start to manage,you know, when you classify them that way
you could assign security policiesas a network policies differently as well.
(13:17):
So from a design time,the approval process is different
and then from the runtimealso could be the the,
the network policiesand the security mechanism could be
mapping some of the infrastructuretechnologies, native technology, as well.
Yeah, fair enough.
You had mentioned this iceberg of APIstrategy.
(13:40):
Really interesting,but Percy did kind of trying to break down
this, you know, kind of what faceswhat's external
to the worldand what sort of internal concerns. And
much in the same way that like you know,
I know like PayPal as an examplelike we had you know,
maybe 50 different endpointsyou could use externally
(14:00):
and there was like 5000 internally. Right.
But you're sort of arguing that alongthe same lines that there's a whole set of
sort of disciplinesand sort of governance things
you should be doing internallythat aren't really visible outside, but
I don't know, I'm probably mangling yourexplanation, so say it better than me.
No, I think it's yeah, the iceberg is likethe little head and stuff behind this,
(14:22):
like the tip of the iceberg is businesstransformation.
That's the ultimate goal of our strategyto get into new market, to get into new
business models
and having the
digital transformation strategy
kind of an API managementunderneath the surface.
(14:43):
There's a lot you know, it'sone 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 themand making sense out of them.
And then being able to access them rapidlyand and puts things together in a
(15:07):
in a high velocity fashion,
connecting the providerand the consumers together in a way
that makes sense to them.
So there's in order to be ableto orchestrate all that underneath
the water, there is all those differentdisciplines as a
as elements or part of the hidden workthat need to be orchestrated.
(15:30):
And I think, you know, one of the thingsthat we have learned over the years
is that you get out of API strategyas 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 bottomthere is security and compliance.
(15:52):
Some program is just all aboutthat, 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 securityand compliance,
you're going to get securityand compliance.
But you have not reachedthe digital transformation
because that's you putin, you get out what you put it right.
(16:13):
And then there is thethe right on top of it,
there is the applicationarchitecture 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 teamand all that.
Right?
All of that within the applicationarchitecture, discipline.
(16:34):
Then you go a little bit higher.
And if you start to investin the lifecycle management
and the reuse and diversion strategyand making sense and you are having
that kind of loginto taxonomy of APIs, then
now you are getting more and more outof that strategy once you know.
And then there is the, the ability toand there's a lot of going on
(16:58):
was discovered the first two yearsabout the developer enablement.
So it's a learningorganization, teaching organization
to be
able to have like an inner open sourcecollaborative model
for developers to contributeand to be able to set
the standards in a collaborative way,not an ivory tower way.
(17:18):
So that's where we
we call the Center for Enablement,not a center of excellence, for example.
That's one of the enabler versusivory 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 developersand the teaching organization,
the learning organization,that machine that spread
and keep evolving all the standardfrom the community, community
(17:42):
community pattern and solutiondriven patterns and all that,
you start to get into the product centric
and that's a whole set of environmentand the organization.
Every team is a product team.
Now the API strategy can really alignwith the business,
(18:02):
can really alignwith those products capabilities
that's already out of the boxesis make it much easier.
Now as I put all the behind the scene,like the security, the
the modernization of the technologystack, the the taxonomy
and the lifecycle management and thethe teaching of, you know, all that.
Now I start to get more benefits
(18:25):
as much as I put into thewith the product centricity
right of of of that we can align easilywith the business that way.
And now you get to the tip of the icebergwhich is you know being able to have the
digital transformation
based on all those different disciplinesorchestrated
and working together in one one visionto for that digital transformation.
(18:47):
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 awayfrom Center of Excellence
and kind of this more federated stylegovernance, all that sort of stuff.
(19:07):
I loved your recent poston fallacies of API governance.
I feel like this is where you kind ofwent down that rabbit hole a bit
and I love the connection to sort of,
you know, distributed computingand kind of what we
and the SLA era and all these thingsthat we should have learned.
But you know, it's like you look aroundand sometimes question
if anybody learned anythingor maybe we just forgot.
(19:29):
But yeah, I guess I'm curious,you know, like, are there sort of high
points in that post that you feel likewe 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 environmentto set teams for success.
(19:50):
You know, two years agowe started that journey
within this coverto move from project to product,
and now we're doing the from productto platform.
The API strategyis 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
(20:13):
moment in industry where,
you know, there's still the old mindsetstrying to be applied
while wewe have all those thousands and explosion
of the number of APIsand we don't know what to do with them.
And we keep trying with the same wayas in the past.
And I think there are two mainI see, you know, learning lessons here.
(20:39):
One is the
the open
well, we learn a lot from the open sourcecommunity
on how governance is happeningin the open source communities
and how there's a maintainerand there's open for collaboration and,
and that kind of a mutual win win.
So running the engineering practice
(21:02):
as an inner open sourcekind of collaborative model, right?
Maybe the best standardwins 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
(21:25):
for teaching the standardand 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 onstandards over for the communities
chaired by enterprise architectureand many of the
the people are accountablefor the standards.
(21:46):
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 engineeringcommunity to participate.
And that's very helpfulbecause it's it's when people are
are listened to we evolve much faster
(22:07):
and we wewe shift before we publish that standard.
We know the community alreadyhave 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 threeor four of the minutes meetings
and all that and anybody can join and all.
(22:27):
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.
(22:50):
So anybody in the communityas well can teach a pattern,
a solution, They can share their solution,they're putting it together,
and that can be promotedto become an enterprise standards.
There's a mechanism to do that.
So the openness and thethe learning organization, that's really
what gets the academy discover technologyinternally and externally.
(23:11):
We have discover
technology experience to
discover that comewe published many of those, share
some of those patterns and solutionsto the outside world as well.
So it does have
those twotwo aspects out of those policies.
(23:33):
If you want to flipthose forces on their heads now,
you've got to have that machinelearning machine
going coaches, advocacyand all that as part of the governance.
You see that as part of the governanceis not really separate from that.
And then
you've got the openness, the open model.
(23:54):
So the API governance,
if you think about it nowwith all those additions,
it becomes more of a dissertation bodythan an enforcement body.
If I think about like thethe hipness ratio on a cash rate
within our processes for approval,
(24:15):
the hipness ratio would be very high
because all the solution would bebased on a solution pattern is on a
something that's everybody committed tois already built in automation in there.
The community already built something.
Therefore, you know, it's,
you know, so so we can see allthose just passing through
(24:37):
as opposed to handing out exceptionsall the time
and being the enforcementget 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 importantas well as the openness and being able to
(24:58):
do governance through with the open model.
Yeah, beautifully put.
You know,
I've seen it myself and we've heard ita bunch from practitioners here that like
the technology partof these transformations isn't the hard
part, it's the cultural change.
And I feel like that's partof what you were just enumerating.
You know,
(25:18):
there's like,
I'm terrible about having like a one linerto try to capture an idea
and then I'll just beat that one linerto death for years.
So I think like it touched ona bunch of things that I've said a bunch
times is like one, you know,
you can't have transformationwithout APIs and a story like this.
That's the core thing, right?
(25:39):
Because that's how you
manifestthis sort of reusable capability mindset.
And then you can't do that
sort of transformative momentum with APIsif you're not breaking down silos.
And that's kind of what you describeas this inner source thing, right?
I find like that's one of the partsthat that companies get hung up on.
(26:00):
The worst is just this entrencheddogma of like,
I have my thing and I protect it
and then I have the contract to integrateand no one else can touch it.
But to your point,if it's open enough and it's design
and everybody's working alongthe same lines, then why wouldn't
you take contributions from another teamthat you have some agreement with?
(26:20):
Right.
Right.
Like, and just getting those habitschanged 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 featureson 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
(26:43):
on somebody else's dime if youif you people
you know but humans valuea 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 doneand discover, I think in the past
(27:06):
two years is that applying this openness
and open source to managing standardsand managing other
you're not just not code but content and,
and and
standards of best practicesand all that, right?
So there's a guild.
(27:27):
We have something, you know, for,for all those
types of standardsthat people can contribute and there's
the, the maintainer of the builta whole within the academy a whole
cycle lifecycle of those content
and of those patterns and can be reviewedand updated and all that.
(27:47):
So it is it is fascinating
how many lessons we could learnfrom the open source communities.
Yeah.
And how that could be appliedto multiple layers
for sure.
Well, and considering the failurerate of these things
over the last 510 years, right.
Most like the vastmajority of transformation attempts fail.
(28:09):
So feel like these are the things that wewe beat the drum
a little bit here on the podcast
I think on these exact pointsall the time from practitioners.
But it's because it's like problematicso often.
Like so great advice.
So, you know, I'm
sure there are some listenershere, let's say, you know, smaller company
(28:29):
just getting the ball rollingand all this and imagining a future
where, you know, they'rein an organization as big as Discover.
But you know, you rattle offa long list of stuff you got to do.
So I guess I'm curious for folkswho are looking to just get started,
or maybe they're even in a
larger, older companythat hasn't started modernizing yet.
(28:49):
When you look back on this past few years,where do you think you would start
to have the biggest impact and kind of getthat momentum swinging the best?
Oh, yeah.
That's that's a good crutchbecause for every it's a little bit tricky
because every company is unique
and there's certain constraintsthat you have to to work within.
For some that's
(29:10):
yeah, our experience of this covers
too, you know, when we startedlike Star Wars security for example,
and that wasI think, a good call to, to start there
because that gives usthe inventory of, of API
when it's when we have a mandate to everyAPI has to be secured,
it's easy to get the sponsorshipfrom security, from executives.
(29:31):
It's very easy to to to sell that. It's
easy to justify API security these dayswhen you dig into breaches, right?
So that's, that's where we could startand 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
(29:56):
the beginning of of wisdom.
I call ita 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 wouldstart.
And security can give me that inventory.
(30:17):
And then just an interesting approach.
I mean, I definitely have, you know, sortof seen and heard that before that like,
you know, stepone is like build the catalog.
That's another kind of,
you know, analog,same kind of intent with the word catalog.
Inventoryis like at least know what you have
and these days everyone's got microservicesprawl problems.
(30:37):
So it's often a good place to start.
But I love this idea of justifyingand building it through a security lens.
That's fascinating.
Yeah, that's our experienceand how we started.
And we ended up with almost,I would say, virtually 100% coverage
in all our API business APIsbecause there's all the slew
of infrastructure shipyardsthat we were not managing now.
(30:58):
But, but it's, it's more of the businessAPIs are because they have to be secured.
You know we have that catalog
was virtually
hundred percent coverageand then we do have the
after the I think
if the organization is already productcentric,
that makes life easier
(31:19):
most targets.
But yeah, it'sjust it's much easier to align with.
So you don't have to definethose boundaries yourself as a technology.
And that's one of the pitfallsto try to technology, try to
define the bounded contexts or what
what you end upwith an engineered experience, don't you?
(31:41):
It's like it's all about the toolsand the technology,
but there's very hard to find businessvalue later on, right?
So yeah, you mentionedlike sort of grammar vocabulary
kind of stuff before,which we've heard before.
And I think that's the side of the housethat tends to do better
at defining those thingsversus a bunch of engineers
who name things in acronyms and systemnames.
Yeah, we talked about this.
Yeah,like maybe last year when we when we met.
(32:02):
Yeah, that was yeah, that's another thing.
On being really product centric
and having a well understood boundariesby the business and the technology kind of
the infrastructurewould reflect those boundaries.
That's well understood by the businessand put the, our APIs there.
I think that's, that would be
a good next step
(32:23):
to sort of team for success.
Yeah, it's not a popular term anymore,but in some ways you're
just describing the old inverseConway maneuver right?
Right.
Yeah, it's, it's,
it's only after we've intentionallyflipped the organization on its head
and design it as you want it to bein the future and then fill in the blanks.
Yeah. So
cool. George Will,
I really appreciate you sharingall kind of some of these insights.
(32:46):
We already kind of called out,and I'll just double down.
Check out the Discovery now.
Sorry, Discovery TechnologyAcademy for Engineers.
You must get the Discovery Discovery thinga lot.
We do this.
That's okay.
We get spotlighted stoplight all the time.
Any other kind of parting words of wisdomor our folks that you think
(33:07):
folks should look at for kind of resourcesto back this up?
I think it's yeah.
Technology will discover that the carwill have lots of those insights was great
colleagues of mine have discoveredthe old publishing.
They're sharing that experienceand contributing to the open source,
the openness model that we were promotingand discovering and outside.
(33:29):
That would be great.
And that was was really funtalking with you today.
Jason Yeah, definitely.
It's always,
always a treat to get to talk with folksrunning
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.
(33:49):
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a question
and we'll do our bestto find out the right answer for you.
I'm Jason Harmonand this is API Intersection
where you'll get insightsfrom experienced API practitioners
to learn best practices on thingslike API design, governance,
identity, auth, versioning and more.
(00:40):
Welcome back to API Intersection.
I'm Jason, your host as always.
And today we have a guest from DiscoverFinancial Services, George Mitry.
George and I have hung out a bit beforebut 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.
(01:03):
Yeah, I
have beenit 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 placeto work in technology in the U.S.
and in the UK as well.
(01:24):
We have recently joined
the Linux Foundation Open Source,
the FinOS Foundation again, open source
and it's a very exciting placeto work at it
and the API making it even more exciting.
And, and it's my passion at Discover here.
(01:47):
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 Amazonand you find your cashback
bonus reward to pay with your cashbackbonus or your bonus balance
(02:10):
and all thethat 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 APIfor the Samsung pay, for example, right?
So that's the, the, the external API
as a financial servicefree partner with a lot of merchants of
(02:34):
B2B partnerships through APIs, it'svery easy to partner with discover,
differentiate itself
as easy to partner with, differentiate itfrom other competitors.
It's quite very large.
And then on the internal APIs,
we do have a very large program,about 1500 APIs
(02:56):
and microservices
that mix up the internal capabilities
within Discover, and
we can talklot 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,
(03:18):
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 commonthing we do here, having done
a bit of kind of time in FinTech, myselfat PayPal and Braintree.
(03:43):
It's, it's different, right?
It's a little a little uptight compared tosome 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 kindof the financial specifics?
And I ask this in part because I knowlike there's a sweeping movement
(04:05):
through fintech right nowto sort of APAC, everything.
And so I'm sure there's listeners who arecurious, you know, how that scales out.
Yeah, there's within the bankingand financial industry, there is
things are moving very fastand there's no question about that.
And even though there'sa lot of regulations, a highly regulated
(04:26):
industry, but it's it's, it's the demand,the increased demand for for speed
and that makes more pressureon the API strategy and the API programs
and to be able to balance that Right.
And and within the API program securityfor example, is top of mind.
Those are the internalor external security
(04:49):
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 scrutinywith the financial regulators
and spend a lot of cycles with auditorsand the feds and all that,
that adds a lot more scrutiny to thatfor those processes.
But there's yeah,the demand is is very high
(05:11):
for being digitaland being transparent about what
we're doing within our controlsand the company.
Yeah, I feel like one of the things that
really openedmy eyes at my time and kind of fintech was
I felt like there was a lack of generalunderstanding
(05:31):
for folks getting into fintechthat sort of the,
the risk and compliance factorsof 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, workingin a sort of credit card company
(05:52):
like this, that that risk and compliancefactor must be a lot of the time spent.
Right.
And it's a core capabilityfor those global networks like when
when you're you're really globally readyand have a footprint
and accepting paymentsand all all those countries it makes it's
a no brainer for fintechs to partnerwith that kind of scale.
(06:14):
And APIs are really the way to partner.
There's the expectation now as towhere 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 wantsand easy to collaborate with.
(06:38):
It becomes a no brainerto 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
(07:01):
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 orderto be able to go fast on the outside,
to fast track the external.
We've got to have our act together rightwithin our internal capabilities
(07:22):
being unlocked because it'slayers of APIs, not just one API.
You want to call her API, going to callanother one to another one, right?
It's a chance kind of rightlayers of of other capabilities
that are aggregated togetherto mix up a solution
like a Lego piece,put it together to to build one solution.
So it is
(07:44):
imperative to
have an internal matureAPI management program
as well as that will feedinto that external
businessgrowth and digital transformation.
Yeah, I mean,I've always kind of described this as like
build your internalsort of microservice APIs
(08:07):
as though you're preparingto externalize them
because you never knowwhen that sort of partnership
opportunity is going to pop upand you know, some 60 day delivery window,
if you have to go back and redesigneverything to make it
external sizable, you know,you're going to miss those opportunities.
So but I've noticed in some of the stuffthat you've published, you talk about
(08:27):
sort of treating microservicesand sort of APIs as a different thing,
like maybewe're on a different perspective here.
So I'd love to hear a little moreabout it.
Yeah, So it goes back
to the intention of,of the microservice architecture
where in its inceptionthe main investments into a microservice
(08:52):
architecture was
the agility of the teamand getting rid of dependencies
and making sure there's a bounded contextand all of a
self-contained kind of service.
So you can go fast when you need to changeand you need, you know,
all the velocity of the team.
That was the main goaland that's kind of goes.
(09:17):
I would say you look under the hood
within the internalworking of an application of a capability.
Right now if we define microservicethat 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
(09:37):
and I can change anything in itwithout impacting anybody or consumers.
Kind of like outside my boundedcontext, 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 waythe investment.
(09:58):
There is moreof a use now with those APIs.
The concept is to be able to
reuse those APIs
and externalizethose capabilities to the outside world.
So that's kind of the distinction.
Would drone this to level of managementand we have seen that a lot
(10:18):
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 myyou know, this isn't
(10:39):
and within my there's an iceberg of of theI strategy.
I differentiate between two disciplines.
It's a multidisciplinary strategy.
There's discipline, disciplinarydiscipline of application architecture,
which is the microservices, the breakingdown, the right sizing of the components
within my applicationsor the modules within my application.
(11:00):
That's an applicationarchitecture discipline.
And then there is thethe 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
(11:23):
discipline as opposed to the application
architecture within my, my,my application walls thing.
So that's, that's where weso we do the distinction between I'm
sure there are there, there are listenersthere who would say like
why would you only optimize for reusefor externalizing things?
Shouldn't your internal servicesalso be sort of optimized for use reuse
(11:46):
with, with,with a certain scope within the team?
So and it's because ofthe are in the catalog.
So there's a visibility into there iscould be some promotion
to say I started this as a microserviceby a will promoted to become
but this on a selective basis so it's notbecause of the 91% of the effort.
(12:10):
You know,I can you know that 1% of the promotable
I don't want to bog downthe 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 thoseAPIs that we know for now.
We don't overinvest in themand we know for now the need to go fast
(12:33):
and then when the time comes,because they're visible,
we can come to them and make them externalas well as is like a balance.
There's always a tradeoffwithin those decisions.
What are you optimizing for?
So we want to optimize for reuseand 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.
(12:57):
And also with the newer modern technology,
with the service meshand the ingress gateways and all of that,
it starts the infrastructure startsto reflect that as well.
Within the East-West versusthe North-South traffic,
you start to manage,you know, when you classify them that way
you could assign security policiesas a network policies differently as well.
(13:17):
So from a design time,the approval process is different
and then from the runtimealso could be the the,
the network policiesand the security mechanism could be
mapping some of the infrastructuretechnologies, native technology, as well.
Yeah, fair enough.
You had mentioned this iceberg of APIstrategy.
(13:40):
Really interesting,but Percy did kind of trying to break down
this, you know, kind of what faceswhat's external
to the worldand what sort of internal concerns. And
much in the same way that like you know,
I know like PayPal as an examplelike we had you know,
maybe 50 different endpointsyou could use externally
(14:00):
and there was like 5000 internally. Right.
But you're sort of arguing that alongthe same lines that there's a whole set of
sort of disciplinesand sort of governance things
you should be doing internallythat aren't really visible outside, but
I don't know, I'm probably mangling yourexplanation, so say it better than me.
No, I think it's yeah, the iceberg is likethe little head and stuff behind this,
(14:22):
like the tip of the iceberg is businesstransformation.
That's the ultimate goal of our strategyto get into new market, to get into new
business models
and having the
digital transformation strategy
kind of an API managementunderneath the surface.
(14:43):
There's a lot you know, it'sone 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 themand making sense out of them.
And then being able to access them rapidlyand and puts things together in a
(15:07):
in a high velocity fashion,
connecting the providerand the consumers together in a way
that makes sense to them.
So there's in order to be ableto orchestrate all that underneath
the water, there is all those differentdisciplines as a
as elements or part of the hidden workthat need to be orchestrated.
(15:30):
And I think, you know, one of the thingsthat we have learned over the years
is that you get out of API strategyas 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 bottomthere is security and compliance.
(15:52):
Some program is just all aboutthat, 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 securityand compliance,
you're going to get securityand compliance.
But you have not reachedthe digital transformation
because that's you putin, you get out what you put it right.
(16:13):
And then there is thethe right on top of it,
there is the applicationarchitecture 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 teamand all that.
Right?
All of that within the applicationarchitecture, discipline.
(16:34):
Then you go a little bit higher.
And if you start to investin the lifecycle management
and the reuse and diversion strategyand making sense and you are having
that kind of loginto taxonomy of APIs, then
now you are getting more and more outof that strategy once you know.
And then there is the, the ability toand there's a lot of going on
(16:58):
was discovered the first two yearsabout the developer enablement.
So it's a learningorganization, teaching organization
to be
able to have like an inner open sourcecollaborative model
for developers to contributeand to be able to set
the standards in a collaborative way,not an ivory tower way.
(17:18):
So that's where we
we call the Center for Enablement,not a center of excellence, for example.
That's one of the enabler versusivory 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 developersand the teaching organization,
the learning organization,that machine that spread
and keep evolving all the standardfrom the community, community
(17:42):
community pattern and solutiondriven patterns and all that,
you start to get into the product centric
and that's a whole set of environmentand the organization.
Every team is a product team.
Now the API strategy can really alignwith the business,
(18:02):
can really alignwith those products capabilities
that's already out of the boxesis make it much easier.
Now as I put all the behind the scene,like the security, the
the modernization of the technologystack, the the taxonomy
and the lifecycle management and thethe teaching of, you know, all that.
Now I start to get more benefits
(18:25):
as much as I put into thewith the product centricity
right of of of that we can align easilywith the business that way.
And now you get to the tip of the icebergwhich is you know being able to have the
digital transformation
based on all those different disciplinesorchestrated
and working together in one one visionto for that digital transformation.
(18:47):
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 awayfrom Center of Excellence
and kind of this more federated stylegovernance, all that sort of stuff.
(19:07):
I loved your recent poston fallacies of API governance.
I feel like this is where you kind ofwent down that rabbit hole a bit
and I love the connection to sort of,
you know, distributed computingand kind of what we
and the SLA era and all these thingsthat we should have learned.
But you know, it's like you look aroundand sometimes question
if anybody learned anythingor maybe we just forgot.
(19:29):
But yeah, I guess I'm curious,you know, like, are there sort of high
points in that post that you feel likewe 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 environmentto set teams for success.
(19:50):
You know, two years agowe started that journey
within this coverto move from project to product,
and now we're doing the from productto platform.
The API strategyis 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
(20:13):
moment in industry where,
you know, there's still the old mindsetstrying to be applied
while wewe have all those thousands and explosion
of the number of APIsand we don't know what to do with them.
And we keep trying with the same wayas in the past.
And I think there are two mainI see, you know, learning lessons here.
(20:39):
One is the
the open
well, we learn a lot from the open sourcecommunity
on how governance is happeningin the open source communities
and how there's a maintainerand there's open for collaboration and,
and that kind of a mutual win win.
So running the engineering practice
(21:02):
as an inner open sourcekind of collaborative model, right?
Maybe the best standardwins 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
(21:25):
for teaching the standardand 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 onstandards over for the communities
chaired by enterprise architectureand many of the
the people are accountablefor the standards.
(21:46):
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 engineeringcommunity to participate.
And that's very helpfulbecause it's it's when people are
are listened to we evolve much faster
(22:07):
and we wewe shift before we publish that standard.
We know the community alreadyhave 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 threeor four of the minutes meetings
and all that and anybody can join and all.
(22:27):
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.
(22:50):
So anybody in the communityas well can teach a pattern,
a solution, They can share their solution,they're putting it together,
and that can be promotedto become an enterprise standards.
There's a mechanism to do that.
So the openness and thethe learning organization, that's really
what gets the academy discover technologyinternally and externally.
(23:11):
We have discover
technology experience to
discover that comewe published many of those, share
some of those patterns and solutionsto the outside world as well.
So it does have
those twotwo aspects out of those policies.
(23:33):
If you want to flipthose forces on their heads now,
you've got to have that machinelearning machine
going coaches, advocacyand all that as part of the governance.
You see that as part of the governanceis not really separate from that.
And then
you've got the openness, the open model.
(23:54):
So the API governance,
if you think about it nowwith all those additions,
it becomes more of a dissertation bodythan an enforcement body.
If I think about like thethe hipness ratio on a cash rate
within our processes for approval,
(24:15):
the hipness ratio would be very high
because all the solution would bebased on a solution pattern is on a
something that's everybody committed tois already built in automation in there.
The community already built something.
Therefore, you know, it's,
you know, so so we can see allthose just passing through
(24:37):
as opposed to handing out exceptionsall the time
and being the enforcementget 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 importantas well as the openness and being able to
(24:58):
do governance through with the open model.
Yeah, beautifully put.
You know,
I've seen it myself and we've heard ita bunch from practitioners here that like
the technology partof these transformations isn't the hard
part, it's the cultural change.
And I feel like that's partof what you were just enumerating.
You know,
(25:18):
there's like,
I'm terrible about having like a one linerto try to capture an idea
and then I'll just beat that one linerto death for years.
So I think like it touched ona bunch of things that I've said a bunch
times is like one, you know,
you can't have transformationwithout APIs and a story like this.
That's the core thing, right?
(25:39):
Because that's how you
manifestthis sort of reusable capability mindset.
And then you can't do that
sort of transformative momentum with APIsif you're not breaking down silos.
And that's kind of what you describeas this inner source thing, right?
I find like that's one of the partsthat that companies get hung up on.
(26:00):
The worst is just this entrencheddogma of like,
I have my thing and I protect it
and then I have the contract to integrateand no one else can touch it.
But to your point,if it's open enough and it's design
and everybody's working alongthe same lines, then why wouldn't
you take contributions from another teamthat you have some agreement with?
(26:20):
Right.
Right.
Like, and just getting those habitschanged 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 featureson 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
(26:43):
on somebody else's dime if youif you people
you know but humans valuea 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 doneand discover, I think in the past
(27:06):
two years is that applying this openness
and open source to managing standardsand managing other
you're not just not code but content and,
and and
standards of best practicesand all that, right?
So there's a guild.
(27:27):
We have something, you know, for,for all those
types of standardsthat people can contribute and there's
the, the maintainer of the builta whole within the academy a whole
cycle lifecycle of those content
and of those patterns and can be reviewedand updated and all that.
(27:47):
So it is it is fascinating
how many lessons we could learnfrom the open source communities.
Yeah.
And how that could be appliedto multiple layers
for sure.
Well, and considering the failurerate of these things
over the last 510 years, right.
Most like the vastmajority of transformation attempts fail.
(28:09):
So feel like these are the things that wewe beat the drum
a little bit here on the podcast
I think on these exact pointsall the time from practitioners.
But it's because it's like problematicso often.
Like so great advice.
So, you know, I'm
sure there are some listenershere, let's say, you know, smaller company
(28:29):
just getting the ball rollingand all this and imagining a future
where, you know, they'rein an organization as big as Discover.
But you know, you rattle offa long list of stuff you got to do.
So I guess I'm curious for folkswho are looking to just get started,
or maybe they're even in a
larger, older companythat hasn't started modernizing yet.
(28:49):
When you look back on this past few years,where do you think you would start
to have the biggest impact and kind of getthat momentum swinging the best?
Oh, yeah.
That's that's a good crutchbecause for every it's a little bit tricky
because every company is unique
and there's certain constraintsthat you have to to work within.
For some that's
(29:10):
yeah, our experience of this covers
too, you know, when we startedlike Star Wars security for example,
and that wasI think, a good call to, to start there
because that gives usthe inventory of, of API
when it's when we have a mandate to everyAPI has to be secured,
it's easy to get the sponsorshipfrom security, from executives.
(29:31):
It's very easy to to to sell that. It's
easy to justify API security these dayswhen you dig into breaches, right?
So that's, that's where we could startand 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
(29:56):
the beginning of of wisdom.
I call ita 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 wouldstart.
And security can give me that inventory.
(30:17):
And then just an interesting approach.
I mean, I definitely have, you know, sortof seen and heard that before that like,
you know, stepone is like build the catalog.
That's another kind of,
you know, analog,same kind of intent with the word catalog.
Inventoryis like at least know what you have
and these days everyone's got microservicesprawl problems.
(30:37):
So it's often a good place to start.
But I love this idea of justifyingand building it through a security lens.
That's fascinating.
Yeah, that's our experienceand how we started.
And we ended up with almost,I would say, virtually 100% coverage
in all our API business APIsbecause there's all the slew
of infrastructure shipyardsthat we were not managing now.
(30:58):
But, but it's, it's more of the businessAPIs are because they have to be secured.
You know we have that catalog
was virtually
hundred percent coverageand then we do have the
after the I think
if the organization is already productcentric,
that makes life easier
(31:19):
most targets.
But yeah, it'sjust it's much easier to align with.
So you don't have to definethose boundaries yourself as a technology.
And that's one of the pitfallsto try to technology, try to
define the bounded contexts or what
what you end upwith an engineered experience, don't you?
(31:41):
It's like it's all about the toolsand the technology,
but there's very hard to find businessvalue later on, right?
So yeah, you mentionedlike sort of grammar vocabulary
kind of stuff before,which we've heard before.
And I think that's the side of the housethat tends to do better
at defining those thingsversus a bunch of engineers
who name things in acronyms and systemnames.
Yeah, we talked about this.
Yeah,like maybe last year when we when we met.
(32:02):
Yeah, that was yeah, that's another thing.
On being really product centric
and having a well understood boundariesby the business and the technology kind of
the infrastructurewould reflect those boundaries.
That's well understood by the businessand put the, our APIs there.
I think that's, that would be
a good next step
(32:23):
to sort of team for success.
Yeah, it's not a popular term anymore,but in some ways you're
just describing the old inverseConway maneuver right?
Right.
Yeah, it's, it's,
it's only after we've intentionallyflipped the organization on its head
and design it as you want it to bein the future and then fill in the blanks.
Yeah. So
cool. George Will,
I really appreciate you sharingall kind of some of these insights.
(32:46):
We already kind of called out,and I'll just double down.
Check out the Discovery now.
Sorry, Discovery TechnologyAcademy for Engineers.
You must get the Discovery Discovery thinga lot.
We do this.
That's okay.
We get spotlighted stoplight all the time.
Any other kind of parting words of wisdomor our folks that you think
(33:07):
folks should look at for kind of resourcesto back this up?
I think it's yeah.
Technology will discover that the carwill have lots of those insights was great
colleagues of mine have discoveredthe old publishing.
They're sharing that experienceand contributing to the open source,
the openness model that we were promotingand discovering and outside.
(33:29):
That would be great.
And that was was really funtalking with you today.
Jason Yeah, definitely.
It's always,
always a treat to get to talk with folksrunning
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.
(33:49):
If you have a question you want to ask,look in the description of whichever
platform you're viewing or listening onand there should be a link there
so you can go submit a question
and we'll do our bestto find out the right answer for you.
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.