Scaling Enterprise API Programs: Governance & Design | Treblle Webinars

0:08We are live then.

0:09Cool, cool. Hi everyone, welcome,

0:11welcome.

0:12Hello everyone, welcome. We will just be

0:17waiting for some time being the

0:21zone until everyone joins in.

0:23Yep.

0:30Give us maybe we'll give people like

0:32maybe three three four minutes until

0:34everybody joins and then we're going to

0:35kick it off.

0:37Absolutely.

0:47James, how are you today?

0:50Good.

0:52I'm based in Colorado and we have a nice

0:53sunny day.

0:55Is there snow in Colorado at this time

0:57of the year?

0:59Usually up until around May.

1:02Um, it we're having a an unusually early

1:05spring right now, so we get these little

1:07snowstorms, but they melt away pretty

1:09quick.

1:11So, it's not too bad.

1:12Nice.

1:14Do a lot of people come come to Colorado

1:16for skiing or

1:18They do and our ski resorts are doing

1:20well. They still have lots of snow. I'm

1:22in the southern part of the state in

1:24Colorado Springs or just outside of it.

1:26And so we tend to not have snow build up

1:29quite like the ski resorts do. So, all

1:32the snow dumps onto those mountains and

1:34as it moves from west to east and then

1:36once it gets east, it's not usually too

1:38bad. Mhm. Mhm. Mhm. So, yeah.

1:42How's the weather on your side, Vedran,

1:44in Croatia? Uh, we've had like a lot of

1:48rough days what I would say, but

1:51I think next as of like this week the

1:54rest of the the it's going to be like 15

1:56degrees, which is really great.

1:58And I guess the rest of the US is like

2:01on daylight savings time already. We're

2:03still not.

2:05I think we're going to switch at the end

2:06of this month, so let's see.

2:10Let's see how that goes basically.

2:14I mean I still haven't understood the

2:15difference between

2:17I've just moved to Europe, so for me

2:19this whole concept of daylight savings

2:21time

2:23new.

2:25You'll get used to it. I think they they

2:27they wanted to back like

2:29not have that be switched and you know,

2:32we all decide on one time zone, but I

2:34don't think that worked out. Or at least

2:37not that I know of.

2:40Fun fact, I named my dog Aspen

2:44based on the

2:46Aspen Colorado.

2:49So yeah, yeah, all because he was all

2:51he's like all white and kind of always

2:53reminded me of Aspen.

2:56That's brilliant. I love it.

2:58Yeah.

2:59And then we have Aspen now as an

3:02API testing tool which was then named

3:05based on the Aspen like the pet.

3:08Yeah, we were sitting in a room and

3:10everybody was like, what are we going to

3:11name our API testing app and like there

3:15were a lot of names. I said, why don't

3:16we just name it Aspen? And

3:20there is a backstory and everything, but

3:22yeah.

3:26I think we can get started. We are I

3:28think so. Prateem, Matthew gave me a

3:30message that he added

3:32what you asked for. Just make sure you

3:34refresh the

3:36the the the thing and see if that's

3:39there.

3:40Okay, let me just quickly I think he

3:43added it to the last slides. You're

3:45going to have to move it. Okay, no

3:47problem.

3:50Let me just get that. Uh-oh, No. You

3:53have to refresh, I believe.

3:54Yeah, just a minute.

3:56Let of us refresh it. Again, welcome

3:58everybody. I think we're going to be

4:00kicking it off. Um

4:02Pratim is going to lead us into the

4:04webinar. Just give her a minute to get

4:07the presentation up and running and

4:10we're going to give you some

4:10instructions on how to behave, I guess,

4:13or what to expect and we're going to

4:15dive deeper into the conversation.

4:17Absolutely.

4:19Well, I think

4:21the slide

4:22doesn't want to load on specifically our

4:23introductions, but I don't think that

4:25should stop us because I've done my

4:27research well and

4:29I'm quite aware of everyone's

4:32names, why we are here, what we are

4:34doing. So, let me just share my screen.

4:39What is

4:40Oops.

4:41Yeah.

4:43Perfect.

4:49So, hello everyone and welcome to

4:51another webinar with Trebl and API

4:54experts. We we try to do this every

4:57month. We bring in experts from

4:59different sections of the API industry,

5:02software engineering, and overall

5:04anything that

5:05is required to scale enterprise software

5:08better. And on today's webinar session,

5:11we have with us James Higginbotham and

5:14he is an API expert and he's been

5:17working in this industry for quite a lot

5:20of time. He has worked with major

5:22companies and clients like Cisco, Dell,

5:25and currently is also an API strategist

5:29and consultant. Um and then with with

5:32us, we have the normal

5:36duo that you have, Vedran, the CEO of

5:38Trebl, and me I I work as Trebl product

5:41advocate. So, before I give it to Vedran

5:44to introduce himself, I would like James

5:46to give us a short introduction about

5:49him and what he's up to currently.

5:51Absolutely. Thanks for having me here

5:54and hi everybody. I see quite a few

5:55names on the attendees list that I

5:58recognize. So, you know who you are.

6:00My name is James Higginbotham. I'm the

6:02founder of LaunchAny. A lot of what I do

6:04is work with enterprise organizations to

6:06establish scale and mature their API

6:10programs. So, I do a lot of training,

6:12consulting. I have a development

6:13background, but also have a background

6:15in product management and in enterprise

6:18architecture. So, I kind of span those

6:20three areas and I combine that into a

6:22lot of what I do with API programs for

6:24enterprises.

6:27I think we are going to get into this a

6:28lot and we are going to understand

6:30different parts. But before that,

6:31Redjan, over to you. A short

6:33introduction. I'm curious to see how you

6:35will introduce yourself new this time.

6:37It's It's just one of those things that

6:40I say that

6:43I'm glad I think this is a first

6:45that we have an old developer background

6:50cast right here. So, I'm really glad.

6:52So, my name is Redjan. I'm the founder

6:55and CEO of Treblle. But before that, I

6:58was also an engineer. So, I spent at

7:00least like 10 to 15 years on the

7:02engineering side building and shipping

7:04APIs.

7:05And you know, today we build tools that

7:08help people that actually do that

7:11do that very

7:12easily. And I'm looking forward to

7:14learning more from James about all of

7:17the different things

7:19that governance and good API design,

7:22which I'm a very big proponent of, can

7:24actually

7:26benefit the entire organization and

7:28actually make more money in the long

7:31run.

7:33Super excited for this. Before we get

7:35into specifically governance and design,

7:38I want to give everyone a quick recap of

7:40what we'll be learning today and what we

7:42can expect what you can expect from

7:44today's webinar. We'll be starting with

7:47one of the biggest problems that we see

7:49in the API space today. You'll see it

7:51soon, but how can API design government

7:55and governance help to fix these? That's

7:57one of the major big topics that we'll

8:00be starting with. Then my favorite part,

8:03something that I'm looking forward to

8:04learn more from James, is around

8:06federated API governance. Now, sounds

8:09like a very heavy word, but I'm super

8:12interested to understand what exactly it

8:15means and how it has helped enterprises,

8:18how it can help any any team that's

8:21trying to grow.

8:22Then we'll be seeing some real-world API

8:24programs and examples from Vedran and

8:27James around what they've seen with

8:29customers, with clients, what has

8:31worked, what has not worked.

8:33And finally, we will talk about the

8:37biggest elephant in the room, which is

8:40AI, and how does AI fit into this whole

8:43conversation around governance and

8:46design and where it actually doesn't. I

8:48think James, you this is where I think

8:52you'll be bringing in a lot of expertise

8:54where um

8:56devs shouldn't definitely be using AI.

8:58So,

8:59pretty excited for that section. And

9:03finally, the questions we'll be taking

9:04questions in the end of the session in

9:06the last 15 minutes. So, you if you have

9:09any questions throughout the session,

9:10feel free to write them down. We will

9:13take them up in the last 15 minutes.

9:17But yeah, so the the main problem that I

9:20spoke about is

9:22API sprawl.

9:24Now,

9:25first I would like to give a quick

9:27understanding of like what API sprawl

9:29is. We're talking here about everyone,

9:32different teams building APIs back to

9:34back, come based on what customers are

9:36wanting, based on what different clients

9:38are expecting internally, externally,

9:41things coming in from both sides. And

9:43the end result is you build a lot of

9:45APIs, sometimes endpoints that you don't

9:48need, you need, and it ends up just

9:50being like a big big mess of the wool

9:53that is stuck together, and you don't

9:55know how to open it.

9:57And this is what we're seeing

9:59everywhere, right? Veteran like This is

10:00what the API report says.

10:03I I absolutely agree. One of the the

10:05first things that uh that we've observed

10:08is how complex and and vast the the

10:12enterprise API landscape is becoming, uh

10:15especially in the both in the number of

10:16APIs. So, like I said, any enterprise

10:19company we we meet, generally more than

10:211,000 APIs. Uh the second problem is I

10:24think the growth of the complexity. Uh

10:27when we compare the data from 2023, the

10:30the average number of API endpoints on

10:32an API grew from 20 around 22 to

10:35actually 42. So, that's almost like a

10:38double uh increase in complexity. Again,

10:40you can tie that into many different

10:42things, but uh I think AI is definitely

10:45uh contributing here. But uh I think

10:48overall, APIs are are growing, the

10:51number is growing, and they're getting

10:53more complex. I think a lot of

10:55organizations are simply not ready for

10:57that, and it does come to API design and

10:59governance. And I would love to hear

11:01from James what his kind of experience

11:05has been so far.

11:07Yeah, absolutely. Um yeah, so I can

11:10definitely confirm that that number from

11:13your survey, that 70% of enterprises

11:15manage 1,000 or more

11:17uh APIs. Um many of my clients that I

11:21work with, I consult to, they have

11:23anywhere between 4 and 6,000 APIs easy.

11:27And I think some of that is a result of

11:29some of the top-down mandates of we must

11:32deliver microservices.

11:34And so there's perhaps been a little bit

11:36more emphasis on breaking things down

11:39into smaller components,

11:40which then makes it a little bit more

11:42difficult when you start searching your

11:44catalog and doing discovery, trying to

11:46find an API you need to use, which one

11:48do I use? Is it this account's API or

11:50that account's API or another account's

11:52API? Because they all exist in different

11:55lines of business or domain areas,

11:56they're not differentiated,

11:58um or perhaps people have put boundaries

12:01around resources.

12:03And instead of

12:05business capabilities or

12:06capability-driven APIs. And so I've seen

12:08a a huge number of these APIs show up

12:10quite a bit. Uh sometimes they overlap

12:13and duplicate scope, sometimes there's

12:16just a lot of complexity in a particular

12:18part of the organization and it just

12:19requires a lot of APIs to get it all

12:21done.

12:22Uh but one of the things that I do see a

12:24lot of times is this focus on

12:26integration-based

12:28design of APIs rather than

12:30capability-based. So we don't start

12:31thinking about it from the business

12:32perspective, uh but uh instead thinking

12:35about it uh from systems and data models

12:39and that causes a lot of proliferation

12:41as well. And I really encourage

12:42organizations to start looking at it

12:44more capability-driven model, which

12:45we'll probably talk about a little bit

12:46later.

12:48One thing that uh that's very

12:49interesting to me, I kind of feel like

12:52organizations are actually becoming

12:54aware of all of this. Would you say

12:55that's true?

12:57Uh

12:58they're aware of the sprawl, they're

13:00trying to figure out how to manage it.

13:02Um and I'm seeing different tactics used

13:05to do that. Um yeah, so so a lot of the

13:08organizations that I work with will will

13:10say, you know, we have a lot of API

13:11sprawl, we're using a lot of tools to

13:12help try to get control over this, but

13:14how do we kind of address the root cause

13:16of it? How do we get in deeper into

13:18that? And that's what we spend a lot of

13:19time working on and rolling things out,

13:22rolling different processes out, better

13:24API governance, scaled API governance,

13:26and so on.

13:27Okay.

13:28So,

13:29what I'm what I'm hearing from you,

13:31James, is sometimes uh there's a system

13:34that's not being followed across the

13:36enterprise. Everyone's doing their own

13:38thing, probably, or everyone has their

13:40rules and uh set of um basically design

13:45system that everyone's following, and

13:46this is probably

13:48leading to more API sprawl. Is that a

13:50good way to see where this is coming

13:54from?

13:55Uh I would I would say that's part of

13:58it. Uh I would also say that there's

14:00been a huge emphasis on

14:03uh and and continued following of

14:05integration-based patterns. So, when we

14:07think about it, uh a lot of

14:09organizations are building APIs because

14:11they need uh data out of a specific

14:13system, so they build an API to wrap

14:14that legacy system or that current

14:16really running system, and then they

14:18start doing that over and over and over

14:20again, and so you have all these APIs

14:22that represent some slice of a business

14:24capability, and then they try to combine

14:27all those things together, and then they

14:29build an API layer on top, and it just

14:31becomes more and more complex, and the

14:33sprawl grows quite a bit cuz we're not

14:35sitting down and thinking, "Well, what

14:36is it that our customers, our partners,

14:38our business, what are the different

14:39ecosystems we're serving, and how uh do

14:43what kind of APIs do they need to serve

14:44those different ecosystems?" Instead, we

14:47end up thinking about systems, and we

14:48think about integrations, because that's

14:50what developers are sort of taught to do

14:52from their early days, and I think it

14:54requires a much a more fundamental shift

14:57uh to something that's more business

15:00capability-driven, that thinks about

15:01things from the outside in. And and so,

15:04when we take that approach, we don't

15:06start looking for boundaries around

15:08systems or proliferation of APIs around

15:10specific systems or data models, we look

15:12around how do we deliver outcomes?

15:14What's the problem, and how do we solve

15:16that with a Right.

15:17with a specific outcome and a series of

15:18steps to get there.

15:20Do you think design and governance

15:22starts at at an engineering level and

15:25and you know, getting enough education

15:27and making sure that you know, engineers

15:29are not just in charge of actually, you

15:32know, building this out in in a

15:34programming language but actually

15:36implementing some of these design

15:38principles or do you think that that

15:41should be done in some other area or in

15:44some other team?

15:46Uh I wouldn't say it's another team. I

15:47would say it's a collaborative effort.

15:49So, if I think of a Venn diagram, I

15:51think of business

15:53product representation, product

15:55managers, product owners within the

15:56enterprise and some representation from

15:59your IT group, your technical team.

16:01All need to work together. And what I

16:03continue to see is these siloed uh

16:06operations. And so,

16:09business says, "We want to achieve this

16:11goal." And the tech team says, "Great,

16:13I'm going to go run with it." And then

16:14they start designing stuff and figuring

16:16out what data they need instead of

16:18sitting down and having really deep

16:20conversations with the business folks to

16:22say, "Well, what's the what's the actual

16:24problem? What are the outcome? What are

16:25the steps we need to get there? How does

16:26this line up with our business

16:27architecture, our operating model? How

16:30do we align all those things together?"

16:32Uh the developers just may need to go,

16:33"I need this piece of data, this piece

16:34of data. This is going to be a lambda.

16:36This is going to be this." And we start

16:38solutioning before we actually know what

16:39we need.

16:40Um and and I would kind of attribute

16:42that to sort of more of a code-first

16:44Agile mentality that we've had over the

16:46last couple decades, where we've pushed

16:48Agile so far that we've stopped asking

16:50questions and just value code more than

16:53valuing requirements and understanding.

16:56And so, if we step back and we actually

16:57sit down and have understanding, the

16:58tech teams can in fact own those APIs,

17:02but they should be representative of

17:03business, which means we need to get

17:04those conversations going. If the tech

17:06team's not able to have those

17:07conversations, that might mean bringing

17:09someone in from product or letting

17:12business drive some of that. And I've

17:14actually implemented both models of that

17:17in in different clients depending on

17:19kind of what their culture is and their

17:21organizational structure and so on. Do

17:23you

17:24if I may protein one important I like

17:27being agile and speed and I think for

17:29for a lot of

17:30non-enterprise companies that's probably

17:32one of their priorities but it we do

17:34hear that you know some of these

17:35companies want to speed up. Does it

17:38necessarily mean that you're giving up

17:41on you know design quality and

17:43governance if if you're introduced those

17:45are you slowing down or is this just a

17:47matter of process and essentially making

17:50sure that

17:52you know you can actually implement some

17:53of the things that we'll we're going to

17:55talk about here in a very very efficient

17:57way.

17:58Yeah um so it's it's it's really

18:00fascinating. What I've seen is uh people

18:03will get a little frustrated. They're

18:04going to be a little uncomfortable when

18:05they have to sit down and actually start

18:06asking questions and capturing a few

18:08requirements.

18:09Um what they find is they they hit an

18:12aha moment usually about halfway through

18:14the design process that I teach. And

18:17what happens is they go oh okay yeah so

18:20this API isn't about a data model. This

18:22API isn't about an IT system that I have

18:24running. Maybe that I acquired through

18:26an acquisition perhaps.

18:29Um

18:30this API is about delivering an outcome

18:32to a certain group of people. It's a

18:34partner or set of partners. It's our

18:36customers. Maybe it's through a UI and

18:39it's indirect to an end user or maybe

18:41it's direct. We have developers that are

18:43going to be consuming these APIs. And so

18:45it will they they get a little

18:47frustrated and a little uncomfortable

18:49cuz it we're stepping back and we're not

18:50talking about JSON first thing. We're

18:52not designing our HTTP

18:55URLs and methods and everything else.

18:58And uh but what happens is they realize

19:01and and I just had someone say this to

19:03me about 2 weeks ago

19:04is what you did is you helped us one

19:07unify on a on a resource model that

19:10represents how our business operates,

19:13not how our systems operate. So, rather

19:15than having a bunch of APIs that take

19:16different inputs,

19:18uh they now have been able to unify on a

19:20resource that they can then use,

19:22uh you know, like a pipe and filter

19:24architecture pattern for those that are

19:25that have that kind of technical

19:27familiarity with that. The idea that I

19:28can take a resource and send it through

19:30a pipeline and it gets

19:32processed in different ways, it gets

19:34decorated and improved in different

19:35ways, and it comes out in in in uh you

19:38know, in this robust fashion instead of

19:40these anemic APIs that require me to

19:43think about that integration. So, what

19:46they end up doing is they spend a little

19:47bit more time up front, but the end

19:49result is less testing and everything

19:52else.

19:54Pretty I want to take a step step back

19:56here and uh imagine

19:58we I want to understand from you and

20:00overall how does uh Treblle look at

20:03governance and what is our definition of

20:05governance? Because it's a big it's a

20:07big spectrum and then I would like to

20:09know from James also because we will be

20:11getting into uh federated governance and

20:13more deeper aspects of that. But on a

20:16bigger scale, what does get governance

20:18mean for us?

20:20I think that the way that we look at

20:22things at at Treblle when it comes to

20:23governance, uh we look at three things.

20:26Uh we look at generally they're actually

20:29very close to what James does, but we

20:31look at design quality itself, security,

20:33and performance. I feel like those three

20:37are where we can actually measure and

20:39automate the most and we're going to

20:41talk about some of these things a bit

20:43later, but I know one of the pain points

20:46that we heard from a lot of these uh

20:48companies is, "Okay, we we want to

20:50introduce governance, but we don't have

20:53a a

20:53you know, an easy way to measure output

20:55or we don't actually have an easy way to

20:57measure these things." So, we sat down,

21:00we essentially uh took a look at what

21:03does uh uh how

21:05you know, what does a good API look like

21:08and we essentially define a pretty

21:10opinionated set of industry standards

21:13and best practices that we think spans

21:15across design,

21:17performance and security and we run

21:20every single API against that in real

21:22time giving you that runtime access to

21:25all of that data because I think one

21:28thing that we've learned is

21:30you know, having access to runtime data

21:32and trusting somebody that they actually

21:34did something

21:36is is rather different. So for us, for

21:38me runtime is the only source of truth,

21:41nothing else

21:43actually in when it comes to an API

21:45should matter.

21:46We do allow you to bring your own

21:48spectral rules and basically customize

21:50what those tests are, but at its core we

21:53look at three categories and we we like

21:55to get runtime data around that.

21:58Interesting.

22:00One small anecdote I would like to share

22:02is I recently visited a JS World where

22:04we spoke about the travel report and

22:07while I had a chance to talk with a few

22:08API developers specifically from

22:11job from JavaScript domain or some

22:13people who are working with uh

22:15uh

22:16the whole back-end infrastructure. I I

22:19ended up asking them so how do how does

22:21the the API infrastructure look and what

22:23do you do in cases of API sprawl and the

22:26first thing they mentioned was like if

22:29there's an API mess, I don't we don't

22:30take care of it. We have an expert

22:33governance team and they are the ones

22:35take care of to take care of it. And

22:37that was my first connection of that

22:39like instantaneous response to what

22:41we've been seeing in the report and

22:43I personally feel like does that

22:45waste more time or more resources back

22:48and forth and if this can be tackled

22:52earlier, James?

22:54Yeah, so

22:56let me let me

22:58talk about let me share my definition of

22:59API governance maybe I'll shed some

23:01light and then we can dig into that

23:02question, too. So, the way I I define it

23:06is API governance is a framework of

23:07policies, processes, and procedures

23:10that organizations implement to ensure

23:12their APIs are designed, developed, and

23:14managed in a consistent, secure, and

23:16efficient manner in alignment with

23:18business goals.

23:20And so, I look at it more than just

23:22runtime. Actually, um I have about eight

23:25I have eight pillars that I draw upon

23:28whenever standing up a new API program

23:30or API platform. And the three key

23:32groups are strategy enablement, uh

23:35operations, and management. There's

23:37three different areas. And so, those

23:39different disciplines all combine

23:40together to create an effective API

23:43governance program. Uh if we leave any

23:45one of these out and we focus purely on

23:47runtime, then we're not aligning our

23:50APIs necessarily with what our business

23:52needs, what our marketplace needs.

23:55Uh if we forget strategy, then we end up

23:59uh

24:00suffering from the perspective of what

24:01APIs are we focused on first, what are

24:03our priorities, and how do things line

24:05up. So, there are a number of policies

24:08that when you think about API

24:09governance, you probably are operating

24:11under your organization's operating

24:12under already, and you just maybe

24:14haven't written them down. So, uh one of

24:17the policies I mentioned before was if

24:18everything's going to be decomposed as a

24:20microservice, is there a policy and a

24:23procedure for how you identify the

24:25boundaries and then roll those out as

24:27part of your APIs? And if there isn't,

24:29then you can create sprawl. Or if your

24:31policy or one of your key metrics is how

24:33many APIs do we have, then we're valuing

24:35the quantity over the quality and I over

24:38the enablement of our uh partners, our

24:41customers, and our internal business

24:43operations.

24:45So, when we think about those things,

24:47it's really important to kind of think

24:48about it in that perspective. And I know

24:51it's easy sometimes to just think about

24:53the runtime because it's out there and

24:54we got to make sure they're scaling, got

24:56to make sure they're secure, got to make

24:57sure that we're not generating a lot of

24:59500 errors or something else.

25:01And and that's part of it, but that's

25:03not all of it.

25:05So, a lot more process, a lot more

25:07before runtime, I guess. A lot more

25:09involvement before you get to runtime.

25:12A lot of why. A lot of whys. Because

25:16if you just say, "Here's what we're

25:17going to do. We're going to use REST

25:19APIs. We're going to use GraphQL APIs."

25:21It's like, "Why? What's the advantage?"

25:23Uh

25:24we're going to use OAuth 2 as a

25:26framework. Why? What are we doing that

25:27for? Those are some simple ones. But you

25:29can get into deeper deeper and deeper

25:31ones. So, you can start thinking about,

25:33"Okay, what's our executive policy? What

25:35about an API-first culture? Why do we

25:38have an API-first culture? Why do we

25:39insist on doing a design-first whenever

25:41possible or at least collaborative

25:43design so that we're thinking about our

25:45APIs as digital representations of our

25:48business capabilities and what we bring

25:50to the marketplace?" Uh

25:52you know, why do we do that? That helps

25:54a lot because when teams get into the

25:57the the nuts and bolts of designing an

25:59API, implementing an API, deploying it,

26:03monitoring it, managing it,

26:05all of that, there's micro decisions

26:07everybody has to make every day. And

26:08you're never going to cover every micro

26:10decision in your government governance

26:12framework. But if you have a series of

26:14policies that help you to make that

26:17decision, you now have a decisioning

26:18framework that allows teams to be able

26:20to make some decisions that align with

26:23the way the organization's going. If you

26:24don't do that, then it's do's and

26:26don'ts. It's, you know, "Oh, those

26:29people that make those rules don't

26:30understand, you know, my woes of the

26:32day."

26:33If if we have policies and and then some

26:36procedures and processes in place,

26:39then we can make that decision to say,

26:40"Yeah, I know we do it this way, but for

26:42this particular instance, the benefit of

26:44the consumer outweighs our standard.

26:47Let's all talk about how this deviation

26:50might actually be to their benefit and

26:52improve developer experience and improve

26:54the onboarding experience and therefore

26:56win a customer for life potentially. So

26:59there's a there's a lot of different

27:01reasons why you would do that.

27:03So this all connects back to the one

27:05point that you had we had we spoke uh

27:07shortly before going on the webinar was

27:09communication and this is also something

27:11that you have mentioned in your book

27:13around API design. So tying it back

27:17when your tooling and your business and

27:21your API culture of the company work in

27:23hand in hand that's when you could

27:24basically have the best

27:26uh best way to do it without any

27:29bottlenecks or least amount of

27:30bottlenecks. Is that a good way to sum

27:32up our discussion around um

27:35starting like how how to set up

27:37governance and how what governance looks

27:39like.

27:40Yeah I think from the communication

27:42perspective what what really benefits is

27:44if you think about there's kind of three

27:46layers of communication. There's sort of

27:47the network protocol communication where

27:51we spend a lot of time in the API design

27:53world you know focused on which HTTP

27:55method to use and which response code to

27:56use and how JSON should be structured

27:59and do we serialize objects or do you

28:01hypermedia and all these different

28:02decisions and that's all well and good

28:04but there's also communication with the

28:06developers which is why we focus on

28:07great API documentation which might go

28:10back to a policy in your governance to

28:12say our APIs will be documented at least

28:15with open API specification or open API

28:17specification and a getting started

28:19guide or you know whatever it is and it

28:21may vary based on the type of API that

28:22you're building. So you have

28:24machine-to-machine communication that's

28:26the network level. You have the

28:28developer-to-developer communication

28:29that's how do you use this API and be

28:31effective with it and then there's the

28:33human-to-human communication. That's

28:36kind of the marketplace. Who am I

28:37serving? What do they need? How am I

28:39solving their problems? How am I

28:41bringing the job to be done in some

28:43automated way or some you know digitized

28:47manner that helps me get things done

28:49day-to-day. So, that communication and

28:52all of that builds upon the policies you

28:54define for your governance and will help

28:56your teams make decisions day-to-day on

28:59how they handle their API design

29:00efforts, how they manage, how they

29:02monitor, what tooling they select, and a

29:04lot of other things.

29:05I really like the API design analogy and

29:09and how you drew it to to that being

29:11equal to communication because in a

29:13sense, if we compare that to us humans,

29:15like, yeah, you know, sometimes you can

29:17walk in a room and you're be you're

29:19going to be saying something, but your

29:20body language says something else,

29:22right? And everybody picks up on that.

29:24And I kind of feel like that's that's

29:26the point of API design. Like, you're

29:28kind of essentially communicating

29:29something without actually saying

29:31anything. So, if if everything is good,

29:34like, if you have if you build a good

29:35API,

29:37to a degree, uh this might be

29:39controversial, but I don't actually need

29:40any additional documentation in order to

29:43actually be able to understand what I

29:44need to do in there. Where are the

29:46endpoints? Where are What are What What

29:48am I supposed to do here? How do I

29:49authenticate? And some other uh things.

29:52So, I definitely agree like getting API

29:54design to a point where where it speaks

29:58for itself uh is something that I think

30:00every organization should should strive

30:03should strive for.

30:05Yeah, absolutely. I mean, that's what I

30:06talk about in my book that uh that that

30:08you're featuring here right now is is uh

30:11the ADDR process. Uh align, define,

30:13design, and refine. So, a step-wise

30:15process that helps you align on the

30:17needs and requirements and really

30:18understand the problem, defining what

30:20the API needs to do before we get into

30:22all the network decisions, the protocol

30:24decisions, then designing it, REST,

30:26GraphQL, gRPC, what what have you, and

30:29then refining, which means getting

30:30feedback and improving it. And one of

30:33the core principles of this whole thing,

30:36and especially the align phase, is if

30:39our API design doesn't reflect the way

30:41the the end developers and marketplace

30:43talks about things. If it's not using

30:45terminology, domain terminology, not

30:47that you use internally. Everybody has

30:49these code names or acronyms for their

30:51systems, for their data models, their

30:53data data stores, their processes and

30:56everything else. That's internal.

30:58If you put that in your API, no one's

31:00going to know what that means. Uh but if

31:03you start talking about domain

31:04vocabulary,

31:06then the domain design, if it reflects

31:08that vocabulary, as you said, will then

31:10make it easier. What I don't need too

31:12much documentation. I might need

31:14inspiration. I might need things to show

31:16me what else I could do that I hadn't

31:17thought about with it. But the

31:20understanding of how to use the API

31:21should be straightforward. So, I see in

31:23like insurance and banking and others,

31:25they'll have all these internal

31:26terminology or internal lines of

31:28business or business units or whatever.

31:30And they'll have their own terminology

31:32within each one. And unifying on that

31:33terminology as you design your API makes

31:36a huge difference about how you can

31:37engage the marketplace.

31:39Absolutely. Yep.

31:41James, you mentioned you've spoken about

31:43versioning from day one. I want to

31:45understand from you and then whether

31:47because we we also have our internal

31:49APIs where we make sure that we have the

31:51best system ourselves. But then, what do

31:54you exactly mean by versioning from day

31:56one? Just making sure that versions are

31:58updated or does versioning your stand

32:01for more standard way of showing

32:04different updates?

32:06Uh it really goes back to your API life

32:07cycle. Uh if you go in

32:10uh unless you're a very disciplined team

32:11and there are some teams that are

32:12disciplined enough to design an API and

32:15evolve it and never have to introduce a

32:16breaking change.

32:18But when I think about versioning, I

32:19think about the life cycle of the API.

32:22And that means thinking about um

32:25when when you're introducing new

32:27capabilities to an existing API, what am

32:29I doing to that? Uh do I recognize what

32:32could potentially create a breaking

32:33change for someone? And if you haven't

32:35put versioning in from day one, uh

32:38recognizing that, you know what, APIs

32:40are forever and someone might stay on

32:41version one for a long time. Uh but I

32:44need version two because of certain

32:46reasons,

32:47uh then you're going to run both at the

32:48same time. You need to have that built

32:50into your life cycle and your design

32:52processes and everything else. Uh if we

32:54if we don't do that, then what I end up

32:56seeing is somebody just said, "Well,

32:58this is the only API we need, the only

32:59version we need of this API." They throw

33:01it out there, they don't have any kind

33:02of versioning strategy at all, and now

33:05how do they migrate their their

33:07consumers? If you have versioning from

33:09day one, you're actually going to

33:10establish expectations,

33:12uh a life cycle, and a set of processes

33:14for how do you roll out new versions of

33:17this API? How do you announce it?

33:19Communicate it? How do you communicate

33:21deprecations? How do you communicate new

33:22versions? How do you communicate when

33:24you're going to deprecate the old

33:25version once the new version comes out?

33:26If those things aren't figured out,

33:28you're going to be figuring them out on

33:29the fly, and it's going to be really,

33:30really hard because your consumers are

33:32going to get upset with you. So, I think

33:34it's important to recognize that APIs

33:35are forever. Once you lock in a design,

33:37you can add to it, but it's very hard to

33:39take away or rename things, and so there

33:41are certain breaking changes that we

33:42just can't involve. So, doing a little

33:44bit of upfront design is helpful to try

33:46to prevent that from coming up, but it's

33:48also recognizing that we have to have

33:49that life cycle in place.

33:52Got it.

33:53Mhm. Let's I think we have a lot to

33:55cover. Let's Let's move ahead and I'll

33:57talk about something uh I was looking

33:59forward to is different API governance

34:02models and specifically centralized and

34:05federated. But to start with, what

34:07exactly does a federated governance

34:10model look like, and how is it different

34:12from a centralized model?

34:16I'd like to know from you, James. So,

34:18sorry for you, Adrian. I'm I'm I'm going

34:20to give James the highlight for this

34:21one.

34:21He's the expert. I'm also learning here.

34:24Yeah, there's actually a third one. So,

34:25let me uh add the third one, although I

34:28it's it's much more were to manage. So,

34:31there's centralized, federated, and

34:32distributed.

34:34And in a distributed model,

34:36um

34:37what you really have is you have

34:39individual teams kind of making up their

34:40own things. And so, you'll see those in

34:42organizations that have a

34:43product-centric

34:45uh structural or organizational model.

34:47So, they've either acquired products,

34:49and every product has its own CEO CEO

34:50and CTO, and so they kind of manage

34:52everything themselves. And what I've

34:54seen is uh certain companies that I've

34:56worked with that have a distributed uh

34:59model like that, uh everybody does their

35:02own thing, they have their own

35:03authorization model. Some people are

35:05using basic, some people are using a

35:07while, some people are coming up with

35:08their own keys, they don't do refreshes,

35:11they don't do expiration dates, and

35:12things like that. So, that one's a very

35:14difficult one to deal with cuz

35:15everybody's kind of doing their own

35:17thing all the time.

35:18Uh I want to contrast that against

35:20federated in just a minute because I

35:21want people to understand that federated

35:23is not that distributed model.

35:25So, a lot of times what organizations

35:27that are launching their API programs,

35:28they start with centralized. They take

35:30one person, three people, some number of

35:32people, they stand up a center of

35:34excellence, center for enablement, API

35:36office, API guild,

35:38uh some sort of organization that has a

35:41name like that. And it's it's a group of

35:43people that are passionate about APIs,

35:44and they start pulling these things

35:46together. They put together style

35:47guides, they get all their governance in

35:48place, maybe they participate in

35:50selecting tools, they work with and

35:52collaborate with platform engineering

35:53teams to stand up those tools, get them

35:55to align with the way they want things

35:56to work.

35:58That doesn't always scale, and

36:00eventually what will happen is those

36:01three people get overwhelmed.

36:03So, in organizations that are very

36:04large, that centralized group is has a

36:07work queue that's three weeks deep, they

36:09can't take a vacation, uh they get

36:12behind, they're not meeting their SLAs,

36:13and it's just very difficult for that

36:15team. And that's where you start to look

36:17at federated governance models. That's

36:19where you have that centralized group,

36:21they're sort of driving the key

36:23processes and procedures, and and

36:25keeping things kind of organized

36:26compared to that distributed model. But

36:29you stand up API coaches. You find

36:31people in different parts of the

36:32organization that are passionate about

36:33APIs. You train them on how your

36:37governance model works. You train them

36:38on how to facilitate and communicate

36:40with teams and to help guide those

36:42teams. So what you have then, you have

36:44these representatives that exist all

36:46around the organization, these coaches.

36:49And these coaches are there working with

36:50teams directly. So the teams aren't on

36:53their own. They're not having to wait

36:54two or three weeks to get a hold of

36:55someone from a centralized group. And

36:57then they don't have to spend a lot of

36:58time teaching the centralized group how

37:00their part of the organization works.

37:02Cuz you're finding coaches that are in

37:04that same domain area as the teams that

37:06need their support. So they all already

37:08speak the same language. They know how

37:09things work. And so they're just

37:11applying what the centralized governance

37:13model would have for them, but they have

37:16that support on the edge. And so they're

37:17getting feedback sooner, quicker,

37:19faster, and they don't feel like they're

37:21alone or that they've got to wait and

37:24everybody gets upset. And now we're

37:25starting to do escalations with VPs

37:27involved and everything else to try to

37:29get some attention from some three

37:31people in a centralized group. So that's

37:33a model I've rolled out quite often with

37:34a lot of the clients that I have cuz I

37:35have pretty large uh organizations and a

37:37large number of developers.

37:39I definitely agree and we hear a lot of

37:43uh you know, from from a lot of

37:45companies about essentially things like

37:47center of excellences

37:49uh

37:50and and enablement and I think with

37:51APIs, the only thing that works is if

37:54you have those

37:55you call them coaches, but uh you know,

37:57enablers if you will, whatever the name

37:59is. Somebody who actually knows enough

38:03about APIs and can actually

38:05uh uh you know, relay that message

38:07consistently across the board. I think

38:10that uh one of the things that helps

38:13those folks specifically is, you know,

38:16when it comes to actually being

38:20actually being able to measure uh uh

38:22this is where I think we would uh

38:24I would help them with tooling and some

38:26stuff that will help them actually be

38:28more efficient and not have to do

38:30actually

38:32you know the repetitive boring work but

38:34rather focus on teaching and educating

38:36these

38:37these people so I think we've seen a lot

38:40of and heard a lot of success stories

38:42around that but it's a combination of

38:45like you said coaches and tooling in my

38:47opinion from everything that we've seen.

38:50Yeah and I think one thing to keep in

38:51mind too is that

38:54you know a centralized API governance

38:57group you know COE or C4E those three

38:59people see a lot more APIs

39:02and patterns and anti patterns

39:05than an average team that's tasked with

39:07designing and delivering an API and you

39:09want to spread that knowledge out and so

39:11that coaching model helps to do that the

39:13the three centralized teams are taking

39:15feedback back from the coaches they're

39:17hearing what's going on what's working

39:18what's not. Uh and then they're pouring

39:21into the coaches and the coaches pour

39:23into the people in their area and it

39:24just allows you to scale so what I like

39:26to say is it's allowing you to do

39:27non-scalable things the teaching the

39:29coaching the feedback in scalable ways

39:32because now you have this coach model so

39:34you have this

39:35structure where three people are pouring

39:37into 50 to 100 or 300 people and then

39:40they're they're pouring into thousands

39:42of developers potentially.

39:45Question I want to understand from you

39:47like what what James was mentioning is

39:49we're talking about a big scale here

39:51we're talking where there are teams and

39:53different sections involved where

39:56it gets difficult for centralized

39:58governance to take care of and manage

40:00everything but how does the space look

40:03for a teams that are in in between

40:06scaling where they have the customers

40:08they have the scale in terms of the APIs

40:12they also have the teams but they've

40:14been

40:15they've been on the previous

40:17small scale version of getting things

40:20working. They started out small. They

40:22saw like a huge spike and now they're

40:24like this big new company. So,

40:27how did this change might seem

40:28overwhelming to them, right, James? Like

40:30I I'd like to get your view also, but

40:32I'm I'm aware that when we work with a

40:35lot of

40:36such customers who've seen spikes and

40:38who have scaled, how does how do

40:40these concepts of federated governance

40:43or distributed governance make sense to

40:45them?

40:46Uh look, we've seen a lot of things. I

40:48think you know, to James's point, we've

40:51seen companies that have 10,000

40:53engineers in their

40:55you know, employed on in their company

40:57and five people five member API

41:00excellence team that basically have to

41:02you know, review every single line

41:05of updates that comes to the open API

41:08spec, which again, I definitely agree

41:12could potentially work, but in the long

41:14run, I think without actually tooling to

41:16assist those five guys, it's impossible.

41:18And without education, they're just

41:20going to be back at the front. Uh so,

41:22what we see from from smaller companies

41:25that are, you know, starting to scale is

41:27they tend to always

41:30kind of start introducing governance too

41:32late, meaning it's all about how can we

41:35build build build build build without

41:37actually implementing absolutely any

41:39safeguards in in in place. And

41:41you know, what James here is talking

41:43about to some of these companies might

41:46be, you know, advanced governance, but

41:49at at at its core, like we're even

41:51talking about people not implementing

41:53authentication their APIs.

41:55And you know, not even having rate

41:57limiting and some of these, you know,

41:59trivial things which in the long run

42:01cost them a lot of money. Insecurity

42:03cost them a lot of engineering hours in

42:05getting that fixed later.

42:07To to to that point, I would say, you

42:10know, you can start

42:12slow and introduce these patterns, but

42:14essentially

42:16one thing that even we do internally in

42:18trouble, we have, you know, like James

42:20said, we have sessions where people who

42:22have more experience in building a

42:24particular

42:25area of the product or even you for

42:27team,

42:29you had

42:30we listened to your session about AI and

42:32all how how does AI work and I learned a

42:35ton even though I I I kind of hear about

42:37that every day, but

42:39introducing that as soon as possible and

42:41even in smaller steps and increments,

42:44so it doesn't have to be like James said

42:47says painful or or, you know,

42:49at the beginning. So trying to introduce

42:52some of these things early on

42:54in in an incremental fashion helps a lot

42:56because

42:58if you tell an engineer, hey, you have

43:00to do this, a lot of them are going to

43:01hate you and going to hate their job and

43:03everything they they basically despise,

43:07but if you

43:08if you educate them on why this is going

43:10to be better and you give them tooling

43:12to help them understand that, I think

43:14that's that's the right way to go.

43:17Yeah, also, you know, one of the one of

43:19the techniques I use a lot is training.

43:22You might not be able to stand up and

43:23and be able to enforce

43:26all the governance policies you want

43:29at the beginning just like just like you

43:31you mentioned Vedran is, you know, the

43:33the idea of incrementally introducing

43:35them.

43:36The other is is training and I've been

43:37doing training for over a decade.

43:40Been, you know, flying all over the

43:41world doing API design training, getting

43:43people up to speed. And one of the

43:45things that I found that works really

43:47well is that we've recorded the training

43:50that we offer and and we license it to

43:52organizations so they can put it in

43:54their LMS and you know, so there it's in

43:56their learning management system and

43:57they can gain that self-paced scalable

43:59effort if we can then start to

44:03you know, train up developers in how to

44:06think about API design. That was kind of

44:08the reason why I launched API coach.io

44:10as well as to allow individuals to be

44:12able to do the same thing if their, you

44:14know, corporate organization doesn't

44:16have a license for the content, but to

44:17be able to go in and and learn these

44:19things and start to apply them. That can

44:21make a huge difference as well. And then

44:22that becomes the training that you use

44:24to start upskilling your coaches and

44:26preparing your coaches to go out and do

44:28what they need to do.

44:29Agreed.

44:30At the

44:31while respecting the time, we are coming

44:33to the last 15 minutes which we had

44:35promised we would keep for the question.

44:37So before that, I would like us to uh

44:40have

44:41a bit of discussion on what we meant by

44:44API at API design at scale. And James,

44:47uh we discussed uh the major areas

44:50around design, but uh one of the things

44:52that uh I wanted to understand from you

44:54is

44:55when requirements come from the customer

44:57side for things that are not available

45:00with with the existing API endpoints,

45:02how does that discussion work

45:04internally? And how do you align that

45:06with business goals? And overall, just

45:09mirroring whatever your APIs are on the

45:11outside with your business expectations.

45:15Yeah, there's a there's a technique

45:17called business architecture or business

45:18architecture modeling. It's something

45:19that I use quite a bit when uh dealing

45:22with APIs. So understanding what part of

45:26how the organization works and what its

45:27internal operating model is, we can kind

45:29of know how all the things are coming

45:31together and bringing that together with

45:32what those requirements are uh from our

45:35customers or partners. But what what the

45:36anti-pattern I see a lot of times is

45:39that we miss opportunities to actually

45:41develop APIs that represent how we can

45:43engage with the marketplace, and instead

45:45we end up becoming outsourced IT

45:47development shops because a partner

45:49says, "I'll pay you X amount to build me

45:51an API so that I can do this." And so

45:54you're catering to just that partner. Um

45:56so there's different techniques to deal

45:58with that, but one of those is to to

46:00thinking about, "Okay, let's dig in and

46:01understand what they really need and

46:03align on on their goals, what the

46:05internal business goals are,

46:07uh and then once we have that aligned,

46:09then it allows us to go forward with a

46:11design effort that hopefully takes into

46:13account all those different aspects

46:15rather than just a fit-for-purpose API

46:18for one partner that, you know, maybe

46:22maybe you get to reuse and maybe you

46:23don't. So, it means having the hard

46:26discussions. It means saying, "Well, why

46:28are we doing this? Why do you need this?

46:29What are you trying to do?" Um as an

46:31example in the insurance industry, we

46:33have a lot of uh brokers uh that work

46:36with carriers and represent different

46:37customers. So, if you think particularly

46:38in commercial insurance,

46:40uh you'll have a fleet of vehicles you

46:41want

46:42covered with insurance.

46:44Uh they'll go to a broker that will go

46:46shop that around to different carriers.

46:48The brokers themselves are then taking

46:50all these different quotes from all

46:51these different carriers. So, they have

46:53their own workflow. That is not the

46:54workflow of a carrier. So, if a carrier

46:56designs an API to give a quote, they're

46:58looking at it like, "Okay, there's going

46:59to be a quote come in and we're going to

47:00resolve this quote one way or another.

47:01We're either going to accept it, we're

47:03going to renegotiate it, whatever." But

47:05from a broker perspective, they're

47:06pulling aggregating a lot of different

47:08things all at once. Their flow is much

47:09different. They would love to have APIs

47:11from all the carriers to be able to do

47:12that. So, to be able to come up with an

47:15API that understands that aggregate view

47:18and workflow of a broker as compared to

47:21how you do things internally is really

47:24key. And that's and that's where the

47:25opportunity lies to be able to design an

47:28API thoughtfully and outside-in during

47:29that align phase compared to how we

47:32might just think of how we do things

47:33internally, our systems, and our data

47:35models.

47:37Interesting. Rajan, do you have anything

47:38to share in terms of

47:40how

47:42it looks on a like how any expectations

47:44that come from a customer could like how

47:46James mentioned that instead of looking

47:48for every purpose, you could either look

47:50at it from a point where

47:53you can look at a bigger business

47:54opportunity there, which would then fit

47:56for more use cases rather than having a

47:58one-to-one development process.

48:02I agree. I generally agree with that. I

48:04think at at at at its core, you know,

48:06most APIs are actually quite similar.

48:10And I think you can reuse a lot of the

48:13the knowledge that you learn on one API

48:15and apply it to a lot a lot of the other

48:18ones. Yes, there will be scenarios where

48:20you can't do that, but I think building

48:22that internal knowledge and building

48:24that internal sort of say database is

48:27crucial for basically enabling much more

48:31faster and much more rapid growth and

48:33development because if everybody is

48:34aligned and they know what they're doing

48:36and they have tooling that can help

48:37them, hey, you're out of the line or

48:39you're not out of line, it's it's a

48:40smooth process

48:42from there in my opinion.

48:45Well, uh

48:46let's talk about the common challenges

48:49that we when we see when people are

48:50building their governance models or

48:53overall like just scaling APIs and what

48:55happens. And James, as you mentioned,

48:58you've experienced working with clients

49:00from insurance, finance. What are some

49:02of the most common challenges that

49:03you've seen specifically specific to

49:06industry, specific to team size, and

49:09specific to I guess then

49:11uh tech stack as well?

49:13Yeah, yeah. Um

49:15so,

49:17from a perspective across all

49:18industries, I see silo teams constantly.

49:21I actually see business and IT still

49:22lacks a lot of trust.

49:25And uh that means that business doesn't

49:28necessarily think IT might deliver in

49:30time or will get it right. IT's like,

49:32oh, business can never tell us what they

49:33really want. If only they would just

49:34tell us the requirements the way we need

49:36them.

49:37Um there's a lot of siloing of of

49:40efforts that are undergoing right now

49:41with APIs and I think that's a result of

49:44just a lot of mistrust. It's going to

49:45take time to rebuild. And so, I

49:46encourage organizations to bring those

49:49teams together in a a

49:50way and have some sort of fusion team

49:52that delivers on something and can show

49:54that that actually in fact that's that's

49:56not the case. But I see that across all

49:58industries. Um over governance as far as

50:01uh

50:02um what do you mean by that? Just like

50:04uh too many rules or too strict?

50:07Yeah, uh so um

50:10that goes back to education a lot of

50:12times. I mean, if there i-

50:14what I found that's the best way to do

50:16this is to have a default

50:20definition of what a certain standard or

50:22practice needs to be and then one or two

50:24alternatives for certain cases. And that

50:26usually covers most of the situations.

50:28So, people have choice. They don't have

50:31to overanalyze and go crawl the web or

50:34hit 15 different LLMs and start asking

50:36questions about, you know, what what are

50:40all the different patterns for

50:41pagination?

50:42Here's the primary pattern we use.

50:43Here's two other ones that we might want

50:45to consider. Um

50:46here's how we're going to organize and

50:47manage our portfolio. Here's how we're

50:49going to do all these things. And and

50:51and trying to find ways to uh make

50:53things default. I think everybody's

50:55exhausted right now. I think if the last

50:57few years have taught us anything, we're

50:59all very overwhelmed. We're barely

51:01keeping our heads above water in some

51:02cases.

51:03Uh trying to deliver as fast as we can

51:05and get things done and do it the right

51:07way. And so having default decisions to

51:09keep people from getting into analysis

51:11paralysis is really key.

51:12And then from uh legacy system, uh a lot

51:15of times I think it's just curse of

51:16knowledge. Um curse of knowledge is uh I

51:20was at worked in a worldwide hotel chain

51:22helping them with their API program. And

51:24the API that they delivered had a char

51:26one field in the database that described

51:29like a pricing

51:31strategy or pricing model for a

51:32particular property, like how much is

51:33this room going to be for?

51:35And they exposed the char one. They

51:37didn't turn that into something could be

51:38understood. So, we have all this curse

51:41of knowledge. Well, I know what Z means,

51:43price levels price code Z means. Or if

51:46you look on your boarding passes on your

51:48phone, they'll have usually have codes

51:49on them that indicate what the point

51:51multiplier is for their reward system or

51:53whatever. Their frequent flyers system

51:56or whatever. So, the curse of knowledge

51:58is really hard with legacy systems. So,

51:59getting out and talking to people and

52:01asking questions, and that's why talking

52:02to businesses key, talking to your

52:04partners are key, doing collaborative

52:06API design that ADDR encourages, getting

52:10feedback, checking things out, making

52:11sure it just aligns. Those are some of

52:13the big challenges that I see, and that

52:15kind of spans really any industry. I

52:18gave you some examples in some specific

52:20industries along the way, but but it I I

52:22don't I think some people in some

52:24industries say, "Well, we're a unicorn.

52:25We do things a little different." I've

52:27worked in I've helped a startup airline

52:29get off the ground. I've worked in

52:30health healthcare, commercial insurance,

52:33retail insurance, retail banking, uh

52:36commercial finance, um bunch of other

52:39ones I'm not even thinking about right

52:40now, and pretty much all the the

52:42challenges are the same. So, there's a

52:43lot you can learn from that, and there's

52:45a lot that I've learned from that in

52:46working with with teams and

52:47understanding kind of where those

52:49difficulties are and how to overcome

52:50them.

52:53I I I cannot stop this question. I

52:54really want to I know we are at a

52:57short time, but shouldn't This is a

52:59question for both of you. Shouldn't silo

53:01teams be a problem that's already

53:03solved? Like, haven't we done like with

53:07I know with experience from like travel,

53:09we have

53:10in at every time there is like at every

53:13part of your API development or like the

53:16way you

53:17view at view your requests, your issues,

53:20you have an option to communicate,

53:22collaborate with your APIs.

53:24It is surprising to me that it's still a

53:26problem.

53:28What What do you think?

53:30I think

53:32this comes down to, you know, years and

53:35years and decades of of how people have

53:37silo things off, and you know, it's

53:40uh and also how some of the vendors and

53:41tooling approach these things. So, you

53:44would always you're always going to, you

53:45know, have a security solution

53:47specifically for the security team.

53:49You're going to have an observability

53:51solution for the DevOps team. You're

53:52going to have, I don't know, something

53:54else for for for some of these other

53:56folks. So, people tend to, you know,

53:59have been siloing things off uh uh uh

54:02for for a for decades. I think uh where

54:05it's

54:06really really hard and where it becomes

54:09obvious that siloing doesn't necessarily

54:12work is APIs because it's such a

54:14cross-functional, in my opinion, it's

54:16such a cross-functional effort that you

54:19really need, you know, the product team,

54:21the business team, the engineering team,

54:23uh uh as well as the architecture teams

54:26involved in actually producing a

54:29world-class uh API or a world-class API

54:32program. So, I think this is something

54:34that we're tackling and, you know,

54:35everything that we're doing at Treva is

54:37is there to support that thesis of

54:40enabling cross-functional teams, uh

54:42enabling them to have access to data,

54:45democratizing that data. Because if I

54:47have to go ask my engineer 5,000 a day,

54:50"Hey, what's going on here? Or do you

54:51have this? How many requests are we

54:53making?" Or, "You know, how many

54:54endpoints do we have and how does that

54:56look?" That's basically a bad scenario

54:58for me where I don't have access to that

55:00data. So, it's first enabling people to

55:03actually have access to the data, and

55:06that's when all these other roles will

55:08start asking questions, in my opinion.

55:11That's where you're going to get the

55:12architecture guy asking their engineer,

55:14"Hey, you know, why don't we have rate

55:17limiting on our API?" Or, "The product

55:20guy, you know, why did you name this set

55:22of endpoints like this?" Et cetera, et

55:24cetera, et cetera.

55:26Yeah, I I'll jump in really quick cuz I

55:28know we're short on time, but I what

55:29here's what I would say, and I just

55:30recently wrote this up for what might be

55:32a a new book that I'm releasing. Uh

55:35Uh

55:36digital transformation

55:38failed over the last decade. And the

55:41reason being is because we made it focus

55:44on modernization

55:46and not cultural transformation.

55:48So, we didn't take what was necessary,

55:51just like you said, Vedran, APIs

55:52intersect business, product, and tech.

55:55They span everything. Try to deliver a

55:58developer portal, and you will find

56:00every problematic area of of your

56:02organization

56:04because the effort required to get

56:08approval to put documentation out about

56:10an API, then put it on the gateway, and

56:12make it available, and then onboarding,

56:13guide people through it. It It's a

56:15stress tester for every part of the

56:17organization. It's cross-cutting. And

56:20And digital transformation focused too

56:22much on modernization, and let's put in

56:24Kubernetes, and let's put a layer on top

56:25of that, and a layer on top of that, and

56:26a layer on top of that, and we forgot to

56:29bring everybody else along with us. So,

56:31part of what we have to do moving

56:32forward, and part of the COEs teams'

56:35responsibility that's is building out

56:37these governance models, is that they

56:39have to bring everybody with them. They

56:41have to explain to business, why do we

56:42have these policies? We have to explain

56:44to business, why is the developer

56:46building that API worried about what my

56:49partner thinks or what my customer

56:51thinks? It's because all these things

56:53overlap, and business a lot of people

56:56don't really understand that. And so, we

56:58haven't had that cultural transformation

57:00that was absolutely essential for

57:01digital transformation. We just failed

57:02to do that. We focused too much on on

57:04modernization. And that that hurt us.

57:07So, we still have the silos.

57:09Well said, James. We are going to talk

57:12about the the biggest elephant in the

57:14room that I had mentioned initially. Not

57:16in the room, actually. Biggest elephant

57:18currently out there when it comes to any

57:21digital transformation, AI, anything,

57:23everything is

57:24um how AI touches this aspect of uh the

57:29industry, specifically around

57:30governance. And what are the benefits?

57:33what are things that you are seeing,

57:35what are different strategies, new

57:37innovations you've seen around in the

57:39around different customers and clients

57:41James, and what do you think are

57:43limitations because I am quite aware

57:45that

57:46you have a lot of

57:48opinion and experience around where AI

57:51shouldn't be used. Yeah, yeah.

57:54So, what I'm seeing today, I'm seeing

57:56people still experiment. A lot of

57:58enterprises have internal LLMs.

58:00They have their own internal models.

58:01They're using either cloud-based

58:03resources to make that happen or they've

58:05stood up some of their own

58:07infrastructure and they're making that

58:09happen. They may have one model, they

58:10may have multiple models.

58:11They're experimenting with code

58:14generation. They're trying things like

58:15Copilot and others.

58:17They're trying to get that into people's

58:18workflow.

58:20I personally

58:23don't think we have too much of a

58:24problem writing code. In fact, I think

58:26we have the opposite. We're writing code

58:29too quick and we're not thinking about

58:30what we're actually writing.

58:32And so, we're not meeting the needs of

58:33the business and the needs of our

58:34customers, we're meeting our own needs.

58:36And that's why it goes back to the

58:37integration-centric

58:39API design. We're focused more on

58:42building systems that have to be

58:44integrated than we are APIs that

58:46actually solve problems. So, I'm not too

58:49concerned about trying to go faster with

58:51code.

58:52I think we need to focus more on

58:53delivering the right thing at the right

58:55time and then leveraging these tools to

58:57deliver it in the right way. So, what am

59:00I seeing as far as API within the

59:02governance realm or within API realm?

59:05I've done some experimentation. I've

59:06worked with some of my clients on this.

59:07We've used some of their internal

59:08models, some public models. You cannot

59:12take the human aspect of the align phase

59:14out. You need to be able to ask

59:16questions, get clarifications and

59:18assumptions because that goes into your

59:19prompts

59:20for your AI

59:22generation.

59:23So, in the design phase, you need to be

59:26able to

59:27uh

59:28get better at doing requirements, which

59:30is why I say those skills are kind of

59:31atrophied because everybody just started

59:33writing code. Well, now if you're not

59:35writing code, you got to be able to

59:36explain what that code's supposed to do

59:38instead of taking it out of your head

59:39and immediately turning it into code,

59:41you got to explain it. So, now you have

59:43to start writing prompts. To write

59:44prompts, you have to have requirements.

59:45You have to align and understand on what

59:47you need to do. And then you can use the

59:48LLMs to kind of help you do some of the

59:50network communication. So, that

59:52human-to-human communication, we still

59:54need that. Can't get rid of that. Uh the

59:57developer-to-developer communication, we

59:59can try to help generate some better

1:00:01documentation, but tech writers are

1:00:03still very valuable and have an absolute

1:00:04valuable skill to copy write copy edit

1:00:07and to write text and content that

1:00:10guides people in a low-cognitive load

1:00:14kind of way.

1:00:15But, the machine-to-machine is where we

1:00:17can automate. We can write the code, we

1:00:18can generate open API specs and things

1:00:20like that. So, I'm seeing a mixture. So,

1:00:22it's about coming back and saying,

1:00:23"Okay, if I have a life cycle, what

1:00:25parts of the life cycle can AI handle?

1:00:27What can't it?" And usually where

1:00:29there's a human interpretation or human

1:00:31description, you're not going to be able

1:00:32to do it.

1:00:34I agree. Uh

1:00:36we I'm going to put my product hat on.

1:00:38We have uh two AI products specifically

1:00:41for folks in the API life cycle. And the

1:00:44beauty and the reason why they work so

1:00:46good and the reason why they're popular

1:00:48is exactly what James said. They're not

1:00:50trying to replace a human, but they're

1:00:52solving the boring part that a a machine

1:00:56can do. So, the number Our first product

1:00:58is Alfred, our AI

1:01:00uh based API integration assistant,

1:01:03which essentially allows you to generate

1:01:05uh or your team or anybody on your

1:01:07developer portal to generate integration

1:01:09code uh based on the open API spec. So,

1:01:12you essentially uh upload the open API

1:01:14spec to Trouble or Trouble generates

1:01:16one, and you can actually embed Alfred

1:01:19directly on your developer portal, and

1:01:21engineers can ask questions like how do

1:01:23I generate how do I make an API request

1:01:26to this endpoint in Node.js and we'll

1:01:28figure that out. Another use case is

1:01:32within our API governance product we

1:01:34actually check for AI readiness where

1:01:37again we try to quantify what does it

1:01:39mean to actually enable machine to

1:01:42machine

1:01:43communication between APIs and how can

1:01:46we how do machines and LLMs interpret

1:01:50your API so we built in a couple of

1:01:53different rules that we saw play a huge

1:01:55important role and we can automate all

1:01:57of these different checks. So those are

1:01:58the two things. I definitely I'm going

1:02:01to make an internal joke with Prateem. I

1:02:02definitely don't think that we're in the

1:02:06vibe governance area like we are in the

1:02:09vibe coding area

1:02:11but maybe one

1:02:14I do agree like although I am an

1:02:15internal AI advocate at Trebl one thing

1:02:18I have definitely seen is my usage of

1:02:21Trebl's governance and API score has

1:02:23increased with the more you build with

1:02:26AI and the best way to make sure like

1:02:28although if you're vibe coding or like

1:02:30you're using AI you're still sticking to

1:02:33the standards that will make sure your

1:02:35APIs are built more safely and securely.

1:02:38So I I completely agree

1:02:41we'll we'll definitely come back to see

1:02:43if there's an era of vibe governance.

1:02:47Um just to wrap up what I have learned

1:02:49from you James and what Vedran has added

1:02:52to this is

1:02:53around different

1:02:55there are not two types but there are

1:02:57actually three different ways we can

1:02:59look at governance distributed

1:03:01centralized and federated then there's

1:03:04also a lot of

1:03:06design is something that goes beyond

1:03:09fixed rules it involves a lot of

1:03:11communication and

1:03:12finally there there's a lot to learn

1:03:14from what peers are doing in basically

1:03:18the financial industry, the uh the

1:03:20medical industry, overall health care

1:03:22industry, and

1:03:23making sure AI is helpful, but not not

1:03:27giving up on the human the human part of

1:03:31interacting with experts. Is that a good

1:03:34thing I've wrapped up? Anything else if

1:03:36I'm missing out? Final thoughts?

1:03:39Uh I think that's a Yeah, that's a great

1:03:41summary of what we've talked about. I

1:03:43think that's uh that does a great job of

1:03:45of covering all the bases.

1:03:47start early. That's my

1:03:51Whatever we said, start earlier.

1:03:52So true. It is hard. Once everything's

1:03:55in motion and you have teams going, it

1:03:57is very hard to change. Uh you end up

1:03:59having to just grandfather in, you know,

1:04:01kind of legacy the old APIs and the old

1:04:03rules until they can come up to speed

1:04:06and I saw people spend 2 years try to

1:04:07unify their authorization model and a

1:04:09distributed governance model cuz they

1:04:11didn't have that unified. So, it's

1:04:13painful. Yeah.

1:04:14Cool. Uh let's take Let's dive into

1:04:17questions. We have a lot of them that

1:04:19I'm seeing. Uh a few have already been

1:04:21answered by James. Uh thank you for

1:04:23that, James, but I definitely like to uh

1:04:25read them out loud so that everyone

1:04:28who's not who doesn't have

1:04:30uh an access to reading to the charts.

1:04:33Andy has asked, "To what extent should

1:04:35we be pushing for industry-wide

1:04:38standards?" Uh James, would you like to

1:04:40quickly give a recap of what you

1:04:42Sure.

1:04:43Yeah, so standards can be a good thing.

1:04:45HTTP is an industry-wide standard. It's

1:04:47It's evolvable. It's extensible. Uh it's

1:04:50served us well, and we leverage that

1:04:52every day, a lot of us.

1:04:54Um

1:04:55but uh I I think as far as

1:04:56industry-specific standards, say like

1:04:59insurance or health care or something

1:05:00else, we have Accord in insurance and

1:05:03Fire and health care and others. Um

1:05:05treat those like separate ecosystems in

1:05:06your company. Design your APIs to

1:05:09provide what your business is unique,

1:05:12what its capabilities are that are

1:05:13unique to the industry, and then support

1:05:16and look at those standards as another

1:05:18ecosystem you need to you know, need to

1:05:20maintain

1:05:21rather than try to just adopt purely the

1:05:24standards. Most of the standards are for

1:05:25interoperability, data portability.

1:05:27They're not about your operating model

1:05:29day-to-day. And as soon as you start

1:05:31figuring that out, you start to realize

1:05:33that the industry standards are just

1:05:35another ecosystem that you need to

1:05:36support. It's another way to leverage

1:05:39your APIs, but it should not control how

1:05:42you design and deliver your APIs and

1:05:44operate as a business.

1:05:46Got it. Um Virgin, I think you'd like to

1:05:48take the next one because from personal

1:05:51ex- from personal experiences of what

1:05:52we've seen at Trulioo,

1:05:54uh for these for these metrics, how do

1:05:56you define an API that that is an API

1:05:59what

1:06:00what is defined with an open API

1:06:02document, related set of operations?

1:06:04Some people call each operation {slash}

1:06:07endpoint an API.

1:06:09For some reason, we get this question a

1:06:11lot. Did I hear this question a lot? To

1:06:13me, there's at least from my side, and I

1:06:16am pretty opinionated on this. Uh there

1:06:19is no doubt that in my mind, an API is a

1:06:22collection of endpoints or operations or

1:06:25resources, however you want to do it.

1:06:27So, uh every API has multiple different

1:06:30endpoints. I've heard this analogy where

1:06:32people think one endpoint is one API. I

1:06:35mean, you can go about that, but you're

1:06:38probably going to have like tens of

1:06:39thousands of APIs, which again

1:06:43perspective, I don't think is is easy to

1:06:45maintain manage.

1:06:46Definitely think that you should be

1:06:48building APIs that are purpose-built,

1:06:50meaning, hey, this microservice should

1:06:52be doing that, and that's a certain set

1:06:54of endpoints. But you should

1:06:57you know, at at its core, APIs are

1:07:00collections of endpoints, and

1:07:02uh

1:07:03if you specifically want to call them

1:07:04operations, you can.

1:07:06Uh would rather use the word resource.

1:07:09Uh so, a collection of uh resources that

1:07:11are made out of uh endpoints. So, there

1:07:13you go. I've

1:07:14I've embedded all the birds uh possible.

1:07:18Uh yeah, whenever something comes up

1:07:20like this, I always say add an extra

1:07:21word to clarify. So, like what you did.

1:07:24Is it a microservice API, a platform

1:07:26API, or um you know, is it a uh an API

1:07:30product? What what is it? And each one

1:07:33of them will have different traits, and

1:07:34it will determine what level of

1:07:36governance you need to have for them.

1:07:38So, um it's just like when we model uh

1:07:41like in the banking industry, you have

1:07:43savings accounts, checking accounts. Uh

1:07:46you might have an auto loan account and

1:07:48other things. Every one of those, if you

1:07:49just called it an account and you had an

1:07:50accounts resource, it'd be doing

1:07:52everything and anything. You'd have one

1:07:53API that does everything and wouldn't be

1:07:55able to do anything very effectively.

1:07:57So, adding one or two words to clarify

1:07:59and add context and create a boundary

1:08:01around it is key. So, I recognize API

1:08:04products, I recognize uh platform APIs,

1:08:06which represent business capabilities

1:08:08that might be combined with other

1:08:09things,

1:08:10and turn into products. And then

1:08:11microservice APIs, which are back end.

1:08:13And where people get into trouble is

1:08:15thinking a microservice that should be

1:08:17kind of more fit for purpose behind the

1:08:18scenes to decompose complexity, they

1:08:20turn it into a platform API or a

1:08:22product, and they try to make a product

1:08:23out of it when it was really designed

1:08:25for a specific system. That's where most

1:08:26people get in trouble.

1:08:28I see I see Anushree in the question.

1:08:30Hi, Anushree. Uh glad to see you here.

1:08:33Uh for a company just starting to think

1:08:35about API governance, what's the first

1:08:37step they should take?

1:08:40Ooh. Or James, any takers? Yeah, go

1:08:43ahead, Vedran. Do you have some thoughts

1:08:44on that?

1:08:44Wow, I get the hard I I get the hard

1:08:46one.

1:08:48I think if you're if you're a really

1:08:49small team that doesn't have uh uh a lot

1:08:51of APIs,

1:08:53I would start with uh you know, uh

1:08:56getting some tooling like our API

1:08:58insights or something like that that

1:09:00will get you up and running pretty fast

1:09:03and won't necessarily

1:09:06impose on your engineering processes and

1:09:08and whatnot, but would definitely serve

1:09:12more as like an educational thing. So,

1:09:14don't come in and say, "Hey, we're going

1:09:17to do API governance from tomorrow.

1:09:19Everybody who commits code is, you know,

1:09:22if they commit bad code, you're done."

1:09:25Start by introducing governance,

1:09:28introducing these processes, introducing

1:09:31tooling that enables you to basically

1:09:33understand what is going on because I

1:09:35think at a fundamental

1:09:38the fundamental problem with APIs is not

1:09:41a lot of people actually see what's

1:09:43going on on them. And like I said,

1:09:45giving access and democratizing that

1:09:47data early on is something across

1:09:50multiple different teams is something

1:09:54that you can do. Again, I'm going to

1:09:55plug Treblle here. All you need to do is

1:09:58basically install Treblle and you you

1:09:59can basically get up and running with

1:10:03minimum set of governance things. You

1:10:04can customize them later on. You'll get

1:10:06the understanding you need, but

1:10:08essentially,

1:10:09if you're starting out, you're going to

1:10:10be more than fine. Just don't go in

1:10:14crazy with an axe or something like that

1:10:16and start rejecting all those PR's

1:10:18because because somebody made a mistake.

1:10:21It's going to take time and that's about

1:10:23it.

1:10:25I I tend to encourage organizations to

1:10:27start with the whys.

1:10:28So, why are you doing it? Why do you

1:10:30have an API program? Who's using the API

1:10:32program? So, map out the strategy, the

1:10:34purpose, what does it mean to have a

1:10:35successful API program? Uh find out if

1:10:38the your leadership is bought into it.

1:10:41Uh if you if your leadership hasn't been

1:10:43bought into it fully, then you've got

1:10:44some work to do to make sure you have

1:10:45the right funding and support. So, that

1:10:47when it comes down to do we put this

1:10:50into our API governance or do we go take

1:10:52the API governance team and retask them

1:10:54on to delivering an API or delivering

1:10:56some feature in a UI or something, uh

1:10:59that trade-off is is very clear. And

1:11:01then start um if you're small group, uh

1:11:04I would start finding an API style guide

1:11:07that represents kind of what you need to

1:11:08do, and then start putting the tooling

1:11:10around that. Uh as Vedran mentioned,

1:11:12starting to put those pieces in place.

1:11:14Uh but make sure you understand the why

1:11:15and start to think about how you're

1:11:17going to manage toward it. Uh leadership

1:11:19today, they're looking for data points,

1:11:21they're looking for results. And if you

1:11:23don't know what they're looking for,

1:11:25then it's going to be really hard for

1:11:26you to deliver

1:11:27uh what they would see as success. It

1:11:29just means more uh bureaucracy process,

1:11:32and they don't understand why. So, get

1:11:34everybody aligned on it and uh and start

1:11:36there, and then start bringing in little

1:11:38pieces at a time, style guide, tooling,

1:11:41you know, putting things into the CICD,

1:11:43but not having a block the processes to

1:11:45get your teams up to speed.

1:11:48Let's try to uh go through the last few

1:11:50questions rapidly. Uh for team you

1:11:53pick one.

1:11:54I like David's. I like uh what do you

1:11:56think, James? Like David has asked about

1:11:58how do these goals around uh consistency

1:12:01and API evolution look when it comes to

1:12:04like runtime or real-time metrics?

1:12:07Yeah, um well, one of them is going to

1:12:10be um

1:12:11um scorecards for your APIs.

1:12:15Uh shout-out to Jason Harman who used to

1:12:16be involved with the PayPal API program

1:12:19and

1:12:19uh has is involved with another group

1:12:21now. I can't remember off top of my

1:12:23head. Sorry, Jason. But uh yeah, I would

1:12:26I would say scorecards that allow your

1:12:30API to be evaluated and leave room for

1:12:34improvement. So, not everybody is going

1:12:35to score 100% across their entire

1:12:37scorecard,

1:12:39but teams should know where they stand.

1:12:40They should know what the minimum bar is

1:12:42for an API to go out the door to ensure

1:12:43that consistency and those other goals.

1:12:46And if they ask, "Why are we doing

1:12:47this?" you point them back to the policy

1:12:48and say, "Here's why." So, it's all back

1:12:50to the why.

1:12:52Definitely, we actually have those

1:12:54scorecards up and running. You can

1:12:56literally drag and drop your open API

1:12:58spec into API insights or Trebl, and

1:13:00we'll give you the scorecards in real

1:13:02time. So, you're at least you're at

1:13:03least going to have a starting point.

1:13:06Finally, we have one question from

1:13:09Zoltan Simon. Can you tell more how to

1:13:12scale the the coaching practice?

1:13:16Ex- like coaching practice three experts

1:13:19are just three. How to coach

1:13:21thousand developers? I think James,

1:13:23you've already answered this.

1:13:24Yeah. Yeah. Uh a little bit. Uh let me

1:13:27just briefly expand on that. Here's what

1:13:29uh here's what we want to make sure you

1:13:30do. Uh don't try to coach everyone at

1:13:33once. You're not going to make it

1:13:35happen. If you have three experts, those

1:13:38three experts should pour into three

1:13:39more.

1:13:41And just grow it and invest in specific

1:13:44people. Uh so, it might be that they

1:13:47self-select themselves. You know some

1:13:49people you've worked with before that

1:13:50really have a good grasp on things. Get

1:13:52their managers' buy-in to make sure that

1:13:55the the manager agrees that if they're

1:13:57doing this as an add-on to their daily

1:13:59job role, that everything is is okay and

1:14:02and copacetic and they're not going to

1:14:03get in trouble for not delivering

1:14:05something else or making sure at least

1:14:07that they understand what their

1:14:08priorities are. Uh so, that's that's one

1:14:11thing.

1:14:12Uh and then, you know, just biased I

1:14:14help organizations do that all the time

1:14:15and take that load off the COEs so they

1:14:17can get their work done day-to-day. But,

1:14:19that's how we do it. We I go in and

1:14:21understand what the program needs, what

1:14:23its policies, what its strategy,

1:14:25everything is, and then I customize a a

1:14:27coaching program, and then I lead

1:14:31coaching sessions and train those

1:14:32coaches up, get to the point where I can

1:14:34certify them and say, "Yep, you you have

1:14:36demonstrated your ability to be a coach

1:14:38and to tackle some of the common

1:14:40decisions we encounter every day." And

1:14:42then, ultimately, those coaches coaches

1:14:44as they continue to coach other teams,

1:14:46hopefully, they're gaining more

1:14:48experience and they can teach someone

1:14:49else later on once they get a little bit

1:14:51of experience.

1:14:53Well, thank you, James. That was super

1:14:56helpful. Personally for me, I learned a

1:14:57lot and I'm definitely sure everyone who

1:15:00attended today's session has

1:15:03has good understanding of how to get

1:15:05started, how to move ahead if at

1:15:07whatever position they are with respect

1:15:09to their API programs.

1:15:11Thank you, veterans, for tagging along

1:15:14and making this conversation more

1:15:16interesting and fun. It's always

1:15:18Hopefully, useful as well.

1:15:20Absolutely.

1:15:22But, I will say that it was James who

1:15:24took most of the

1:15:26the highlight today and it was

1:15:28interesting to have you, James. Would

1:15:30love to have you again. Probably we do a

1:15:32part two because I know the these

1:15:34concepts need to be dealt with more

1:15:36depth. But, for now, we are we are

1:15:39beyond the time and I hope everyone's

1:15:41had a fun a good time.

1:15:43But, thank you so much.

1:15:46Have a great evening, morning, wherever

1:15:48everyone's located.

1:15:51Thank you, guys. Bye.

1:15:53Bye. Appreciate it.

1:15:53Bye-bye.