When the CoE got dismantled: Lessons from 5 years of API governance

Speaker A: Foreign.

Speaker B: Hi everyone and welcome again to the API Governance for Skill podcast. It's me, Ikenna Ikenna Wewu. I am principal consultant at Ikenna Consulting. Um, I'm an independent consultant and I help engineering leaders. I give them independent evidence based assessments of their API governance and delivery posture. Today I have with me Miguel, Miguel Quintero. How are you, Miguel?

Speaker A: I'm doing great. Thank you for having me. Thank you a lot for having me. It's a pleasure.

Speaker B: Good, good, good, good. Miguel, today we're going to be talking about a story you told me about um, API governance, you know, in a large enterprise and starting with things like an API governance center of excellence. But before we go into all those API governance stories, Miguel, tell us a bit about yourself and um, a bit of your story. Um, how you got in tech and how you got into API governance. Cool.

Speaker A: Well thanks anyway, thanks for the intro. Thanks so much for having me here. It's awesome just to be able to hang out and uh, talk to uh, different, you know, folks in the community. Yeah. So my name is Gian Quintero. I am ex, uh, HP, HX Delta, ex postman. I've been around for 20 plus years in tech. My background basically software development, software engineering. You know, you started out your career and um, support and just in general in tech and uh, yeah, so throughout that, uh, my career essentially and I was told, hey, let's do DevOps, let's do all these different trends that uh, come along. And so, okay, fine, get into that. And so I found myself, and it's known today back then as a developer experience team being, you know, supporting teams worldwide. So yeah, so I started getting more involved and that's where I started to get a sense of governance. Like you're gluing different tools, you're putting different processes and tools together. You notice you started noticing lots of inconsistencies. And uh, so I did that for many, many, many years. And then of course once you're doing that, and of course I did some along the way, did some DevOps work, DevSecOps work and well along the way you come across APIs and that's where the uh, I would say that's where the governance really hit me because it was such a, an initial bad experience. It was fun. I mean learning is fun, right? That, that part is fine. But you're trying to come up with, you probably know, right? You folks know a lot of integrations and different standards and different ways of doing things. I'm like, okay, this is an amazing space. So let's focus on APIs. So this is around 2014, 2015 timeframe. So ever since, you know, I started working in API, what's API First? That's really in any project. Okay, where's the API? Well, let's build one. Why don't we have one? Uh, and of course I've also gotten, you know, got to know more people and got, uh, invited to join the open API community. So I've been contributing to that project, uh, which is, you know, very great experience, meeting a lot of people over there, attending conferences, doing a few talks here and there, uh, mainly maybe API days and then some, some internal talks at, uh, Delta as well. So. So yeah, I, I do have, like you said in the, in your intro, right. I do have a lot of governance scars, lots of them. Wealth.

Speaker B: And one of the things that struck me when I spoke to you is, uh, again, one of those stories about API centers of excellence. And as many people who are listening would know, when introducing governance, it makes sense to have some sort of central enablement group. It can be called an API center of excellence, it can be called something else. You know, an, um, API governance group, whatever it's called, is this kind of central group that's meant to, uh, enable teams in terms of providing them with standards, helping them with maybe some of the tooling, just helping them answer some of the questions and really oversee the initiative. Really. Tell us a bit about how you've, you know, in different companies you've worked in, you've been involved in. Tell us about your experience with the early days of API centers of excellence. You know, let's set up this group, let's help teams tell us stories of how that started and how that started out. I'm sure in those days, you know, it's exciting to get into all that. What's been your experience with starting out, uh, an API cov.

Speaker A: Yeah, great question. So basically most of my career is spent in the enterprise. So we're talking about large organizations worldwide. And that also means enterprise. So it's bigger Org, lots of Org, lots of people. And inherently, as I discovered, lots of silos. Right? Uh, everywhere. And so when I was at HP, we were like, okay, we got a ton of APIs, right? I'm starting digging, exploring, exploring. Okay, where do we have a catalog, we have a portal where, what are our assets, how are people connecting all these interfaces, et cetera. And they're out there, but, um, essentially not much of a driver there. I try to reach out to people, try to look for, ah, other Folks who cared about the same subject. Not much there. Uh, and so basically I ended up, um. That's why I ended up in Delta. Right. So they actually started out with center of Excellence lot. I mean, it's a lot of hard work. It was really tough. Very quick go to market, you know, experience, you know, it's go, go, go, go. You know, you're competing a lot. So. So, yeah. So when I got there, there was a team. I came in as a designer and, uh, very, very little tooling in place.

Speaker B: Right.

Speaker A: So. But that's okay. You need to get started. Like, I. It was basically nothing. It was just sporadic, spread out, uh, pockets of people trying to do the right thing. And they don't talk to each other. Maybe they do. They don't. But I. Delta was different, right? It was more formal. I said, okay, great, this is fun. This is what I'm looking for. Everyone's going in the same direction and let's go. And so our rest style guide, about 22 pages. Very modest. Right? Uh, you know, but by then, by the time I arrived, I seen 22 pages.

Speaker B: Sorry, did you say 22 pages?

Speaker A: Yeah, yeah. It's very small. It's a small PDF, you know, because that's one of the first things I did. I said, okay, what is that? Goodbye. By the time I arrived, I had seen many, many, many guides out there. Uh, this is back in mid teens. People were trying to come up with these style guides. And I was learning a lot back then from like, Mike Adamson, API handyman, and Loren, he was collecting a lot of the information. So I was just basically learning from those, you know, I call them my mentors back in the day. And so I've. I've seen a lot of style guides and I got a sense of how different folks, uh, different organizations were working on their APIs. I said, I said, great, okay, we have one. That's good. Good stuff. Yeah. I looked at the M, you know, our developer portal. Great. Okay, so we've got your initial tooling that I would say maybe some of these. Many of these teams start out with these. Okay, you got your portal, you got your standards, and then you start working your way, uh, from there. Right. Um, this is in place engagement. We had a form, a document you have to fill in, you know, your intent, what are you trying to do, you know, architecture, uh, information about your API, et cetera. And we, um, send that across, we take a look, and then of course, we assign someone to work with that teams, maybe, I don't know if you can call that the classic model, like a central team, where we're just receiving those requests. Uh, back then, back then, in sort of an informal way, we did the ticketing system or anything of that for. We just wanted to get, um, just get started. Right. So, yeah, you know, and then I started just spreading out, talking to more teams and more teams and more engagements and engagements. And engagements. And uh, yeah, it was actually, for me, it was quite fun. I mean, you learn a lot about different part, different domains, different parts of the organization, which is really, really awesome because then that ultimately that helps you understand, okay, where the APIs are coming from, who's going to talk to, what you get to step back and see, okay, is our sort of catalog or assets taking, taking the right shape and, you know, so on and so forth. So.

Speaker B: Yeah, so. So one interesting thing you mentioned there, Miguel, is this. You. We always have this classic tension between speed. You know, at that company there was a lot of pressure to deliver, you know, there was market pressure to get something out. But they also, at the other hand, you're kind of the governance person who is meant to, uh, ensure standards and consistency and all that good stuff with APIs. And there's a whole story there to be told about. There are lots of stories there, I guess, on that tension between speed and quality, reliability, um, all that standard stuff. And one of the things you told me was this idea of champions finding people. As you walk across different teams, finding people to champion, champion that governance. Now this is a common pattern, you know, when people roll out, when people are in the enterprise adopting not just APIs, but, you know, testing or technologies or whatever, you have people champion, championing, but particularly at APIs, in your experience. Tell us more about your experience with kind of rolling out your C of E with, with API champions and kind of enabling champions, supporting champions. How did that go? Did that work? Well, did you have problems? What kind of problems did you face with getting API champions to support you?

Speaker A: Yeah, so basically, yeah. Ah, so early days, uh, as I, as I met more people, you get more engagements and you're meeting more folks, you're meeting more API teams. You start, you start getting a sense of, um. Some people sort of tend to stand out. I'm looking. So for example, I'm looking for people who maybe, uh, are very passionate about standards. Right. So in fact, let's just say consistency, not just an APIs, but consistency across the board. But of course we care about API, so it's consistent, you know, be consistent about API and uh, you know, and also worry about say some of the optometrics is the onboarding. Who's consuming my API? That question, you know, who's consuming my APIs in my team and so on and so forth. Right. And so that's the kind of person with a. So we're, we're in our day to day engagement and we're looking at a design, we're looking at API to go.

Speaker B: Okay.

Speaker A: They're gravitating towards those concerns that I say, okay, I think we have a potential champion here, someone who uh, maybe who can also influence their team. That's also very, very key. You can influence their team, you can influence your domain. Who goes beyond. Okay, here's an integration point and uh, that's it. We're done with this API, right? Go beyond that. What makes this difficult is if you have, if you're talking to that person but they only consume APIs within their own team, within their own org, it makes it really, really hard. They don't not think outside the box if you will. Right. But when they do, like okay, one domain is consuming APIs from another domain, let's say private APIs for example, then yeah, yeah, they start as, you know, they start getting concerned about, okay, the onboarding experience, the developer experience and now the agentic experience. You know, you're going to consume my agent, whatever, you know, what's behind the agent and all that. So now those concerns come to the pictures and go, okay, I think this is a person who can make a good chance. Not only that, but it's also the Persona. I started out obviously talking to developers and I'm thinking, well what if um, those concerns about let's say business capabilities, developers don't they just coding, want to code, they want to develop their controllers and whatever. They're not necessarily thinking, hey, what's the business capability here? How's the end consumer going to use it or the actual customer? All the way out here, the customer is going to use this product, which in turn uses my PI. How does that all translate? So business analysts, right? I'm reaching out to business analysts, that kind of Persona and I'm going, hey, this uh, is, you know, you're in an API team, you're building this product, et cetera. Have you thought about all these things and that? Ah, oh yeah, yeah, I'm thinking about it. But then you have the flip side problem if we go, oh, but I'm not a developer, I'm not should be care about the. No, no, yeah you do, you do. So I'm Trying to look for that well rounded person, the developer who should understand some of the business capabilities and aspects and on the other side the business analyst who understands that and has a big picture, maybe the product person, product focus person who needs to also understand how APIs work. So yeah, that's the kind of makes, that's the kind of person I'm looking forward to. Uh, and I did find a few, I did find a few uh, champions. But it, but it's hard, it's just more work that you have to do. But I think it's well worth it.

Speaker B: Yeah, yeah. I mean very interesting point you raise. Um, there are two points you raise I want to talk about. One is this thing about the business analyst and then the second point about um, come back to that. But for the business, uh, you know we talk a lot about API first and API as a product and API first and I think as a consequence of that, when we really start, when that start gets, when that starts getting embedded and teams begin to understand, look at things from that business capability, then you're absolutely right. It's my experience that the business analysts kind of people, product owners kind of level people become ah, really interested in the, in APIs and in the design and I guess that's where tools like um, yeah, depending on what tooling they use but they really get interested in that design because they're seeing that interface, seeing it from uh, um, a customer journey perspective, seeing those touch points between systems and they're really seeing it from a kind of capability perspective. Right. Uh, from a business operation perspective. So that's um, you know, I think that's, that's a really, really interesting point in terms of people who buy into that kind of API first. But then the other, the other thing as well you said, I thought was interesting is, is about um, I'm not, I'm not going to call them silos but industries that are not necessarily, we're not talking about you know, the digital people providing digital services. So as a product. So if we think of traditional industries and you know, logistics or transportation or things like that, where you know, you really have different departments and different orgs and API governance kind of really comes into its own when people actually consume or Try to consume APIs across different business units. Right. And that's where I think that's what you're talking about, where you have, if it's all within one team, you know, once, you know, one small team, then it's like okay, why the bother? But once it's across different domains and even across different business units, it really comes into people then see the need for that, um, consistency. Yeah, maybe, maybe you can share a bit more about your experience there and this kind of. Yeah. Cross team, cross business unit.

Speaker A: Well, yeah, so yeah, when that happened, when you cross that boundary, I mean you definitely. Then you're going beyond API design.

Speaker B: Right.

Speaker A: And so you're going to have to have that conversation, you know, because that's the other thing. Sometimes the folks may, the perception is, oh, this is a governance team, they only do API standards. But which might be the case, but I think this center of excellence should evolve more towards, you know, the, even what I call ROI readiness, you know, to be able to, if someone comes to you, C level or some general manager, manager, say, hey, explain the return on investment, why we're building these APIs. So you got to be ready for that. Maybe in some of your other questions. We'll get to that in a minute. But um, but yeah, I mean, yeah, when you cross that boundary, definitely need the government comes to do the picture. But you know what's interesting, and I ran into this a few times where I go, I talk about this concept that you're mentioning to teams who are building internal APIs, right? APIs. And I go, you know, one day, you know, maybe that API you've built is so successful that is gets consumed outside of your team, outside of your org. Guess what? Maybe even, even beep evolves. If that's maybe the right word. Do a partner PI. Now, now we're talking a much bigger problem here. And I go, you have to be, you have to start, perhaps start with that mindset, say, okay, one day the interfaces that I'm writing turn only and have so much concern. And then when become partner APIs, that's a different. Uh, you might be, you might even, I mean most likely probably design a separate API. But you take your learning, you know, you take that learning and then you translate that to a partner API. Because now your team that went from writing internal APIs to possibly, uh, partner APIs, and so that, that you're definitely crossing a lot of boundaries there.

Speaker B: Yeah.

Speaker A: So you better be ready. So.

Speaker B: Yeah, yeah, yeah. Ah, I'm talking about partner APIs. You know, what we find is, you know, organizations have lots of internal APIs. Some organizations have customer AP, but lots of organizations integrate with third parties, you know, partners, suppliers, those kind of things. And that is a layer that also needs governance.

Speaker A: Right.

Speaker B: That's a layer that involves integration, some level of visibility on who we're integrating with. Um, perhaps some, you know, security, security concerns there. You know what, what has been your experience with that third party side of connecting with, you know, with third party vendors over APIs?

Speaker A: Yeah, yeah, that was for me. Uh, I mean I've worked with a few partners and um, it was tough because let's say for example, you have the tooling, they don't. So how do you collaborate? Let's just talk tooling alone. Where's the platform to collaborate? Worst case scenario, you put a contract out there and you start emailing it to each other. Dropbox or uh, Google Drive, you know, you start using this very ad hoc. And M, maybe some, maybe you know, security concerns there when you're, you know, sharing this intellectual property back and forth. Right. So you have to m. Have the right platform, uh, uh, to, to do so. Right. Though once you get past that then you're like oh, then it's um, maybe this partner has a set of governance and you have your own set of governance, you have your own set of standards. They have their own set of standards. Is how do you bring those together, right? Their architect, your architect, your designer, their designers. A lot of times if I remember they, I never worked with outside designers. It's just basically they, they, the partner assigned one or two developers to the project. And these developers, you know, to be honest, Ikeda, uh, the, a lot of developers that I've met, they're very brilliant, they know what they're doing, et cetera. But the subtleties of API design are not something that you know, they brought to the table often when I, when I met them. They're brilliant people anyway. But so it was like, okay, you have to get into some education there and translate these requirements into business outcomes and so to make sure the API balls in the right way. And so developers, yeah, they again, they just focus on the sort of the tech, tech aspect of IT frameworks, uh, and language, whatnot. So I had to deal with a lot of that and say okay, this is our standard. You're going to be the consuming partner, you're going to build it, we're going to consume it. Okay, so our models, et cetera, how does that, you know, naming conventions and whatnot or schemas and all that. How does that, how does that supposed to work? And you know, a lot of times if you're lucky, maybe they say okay, we'll follow your standards. Go, you know, we have none. I was brought into this project, we have none. So we'll do, we'll do what you say. So we can Smooth things out. And mind you, these, these integrations and this whole process took weeks and weeks and weeks and weeks. It just wasn't um, wasn't as pleasant. But it was, it was good. Learning is good. But as uh, DX wasn't as good.

Speaker B: Yeah, yeah, yeah. Can you imagine on the partner side. Yeah, that third party side, not. Yeah, it's DX, not as good as customer facing APIs. So we have this center of excellence. You get started, you've introduced API champions as uh, an organizational design thing to support your API governance rollout. And that's going well. And along the line the COE gets dismantled. Okay, tell us that story. You know, why, what, what was the driver, uh, to, to make that happen?

Speaker A: Well, yeah, as I mean essentially, you know, some, like some of these organizations, they go, they start with oh, we have a, we have a new dig, we have a new digital transformation or we have a new initiative, we're going to the cloud, we're going from on um, PREM to the cloud, et cetera. Fine. Uh, and then it's just a general change of direction unfortunately. And in this depends on the culture, depends on the people involved. You don't, sometimes you don't take what you've learned and say because oh, this is a new transformation. We're doing this things way new and shiny. And then you don't take what we've been doing already. And so that gets, you know, basically pretty much for the most part gets thrown away all that learning unfortunately and say okay, we have a new initiative, this is a new set of guidelines, these are all these great ideas and off you go. Usually, uh, you know, from my experience and you know, the sort of, the standards just uh, at least from the API perspective were really follow us at that point. It's like, you know, um, it got split up and everyone's you know, pizza team squads and everyone's doing their own, their own thing as far as APIs. Right. There are other layers, there are other concerns. But as far as I could, I could see it just sort of fell apart and like okay, it was just kind of unfortunate but it's just one of the things that you know, just happens.

Speaker B: So yeah, so we have this new initiative comes in some new initiative, um, whatever that is. And so there's less emphasis on the API program and on that um, on API governance and the API CoE or C of E. And your center of excellence gets um, dismantled. Do you see? Because one of the things I think I mentioned to you like in our previous discussion is how uh, first of all. The reason of that being, uh, because of a perception perhaps, that the center of Excellence is like, you know, this governance body that's always saying no, always maybe being a blocker to processes. Um, is that something you've seen that can contribute to, um, either the coe, either not getting removed, but maybe slimmed down or something like that? Um, what are the patterns around, you know, C of E not done right. Or where, you know, where it can, um, be a blocker. Really?

Speaker A: Yeah. That's a great question. So, um, a couple of things.

Speaker B: Sorry. Just as you answer that, if you also touch on the, Should I say political.

Speaker A: Yes.

Speaker B: Aspects of that perception as well.

Speaker A: Yeah, well, I mean, because, say, for example, to answer your question, that like, depending on your industry and how heavily regulated you are or how sensitive you are to any downtimes, any issues. So, for example, change management has a lot of teeth. There's a lot of, you know, something goes wrong, uh, it's all eyes are on it. So it's a much harder gate, it's got more support. Right. So if you're operationally sensitive that it sees a lot of attention. Right. And it could be slow, it doesn't matter, but it's there.

Speaker B: Right.

Speaker A: It's a tough one to get past. Then also, likewise, security. It's the same thing when something happens in security, then you have branding issues, reputation, et cetera. So all eyes on it, and it gets a lot of attention. But when your API, you know, when, uh, it's not, uh, you know, some design choices are not maybe the best choices, and the evolvability aspect comes into the picture later on, it'll. It'll bubble up. It'll be. Make itself present, by the way, when you're getting into AI, but that's another. We'll get into that later. But then you go, okay, that's fine. You, you know, you have an initial deport, the, you know, red champagne, et cetera. But once you get past that, hey, that's fine. We, we have got past that. The project's good. Uh, we are making money now. You know, the initiative is. We, you know, we're measured on something else, um, on the revenue, et cetera, et cetera. And so it doesn't, It's. It. It's fine. Like, this is the sort of part of the pain that we, uh, could deal, we could deal with that. It's sort of politically speaking, it just. It's an easy concern to pick to look at and say, okay, we don't. We don't. I don't think we need this or we're not ready or maybe we should implement more effort like what you mentioned in your book. Like uh, with apiops, for example. Now API ops plus AI, give it more time, give it a chance to be more of a native experience. But it doesn't happen. It's just say we have to move on. And um, so that goes, uh, for the most part it just uh, goes out the door. So unfortunately, I think that's the pattern that I see that you've got, you know, change management and again, depends on your industry. So. But yeah, yeah, absolutely.

Speaker B: Do you know what I mean? I like, I really want to talk to people at Stripe, you know, um, different companies I've worked with. Stripe was always the kind of like, you know, the example of how to do APIs and because, not just because they do good APIs, but because they do it consistently well. Yeah, not um, just good APIs, but really pushing the boundary of what good should be and what good to expect. Because one of the things I find, I was talking about this to someone yesterday is that um, like API governance is really apart from the security aspect, which is a big part of API governance. Right. You can really make a case for the security aspects of API governance. Right. Nobody wants a breach. Unfortunately, some companies, they only look at API governance when there's been a data breach, there's been a security issue, then everyone is into that kind of API security. But all the other stuff around, you know, lifecycle management and inventory of your APIs and you know, deprecation of APIs and standards and things like that, it's not as, it's not, it's not, it doesn't always seem as urgent. Um, it doesn't always seem as compelling. And so a lot of the thing about API governance is how to tell the story of how to really make the case of why investment needs to go into making, you know, APIs consistent, uh, making APIs easy to use for humans, for agents, making them discoverable and all that good stuff. And it's not always easy to make, or should I say it takes an effort to make that case and to make it clearly, you know, with, with, with clarity. Uh, that, that makes it attract the investment, that, that, you know.

Speaker A: Sure. I mean, to your point, I mean, how many, how many seed levels or higher ups are looking at a catalog? Do they even know it exists? I mean, do they. That's why those concerns that you're talking about are hard to explain because they don't, they don't even look at These things. Maybe, maybe an engineering manager because he's closer to the team and maybe they own an API or let's just say they own a product that consumes a lot of API. Fine, but the driver is there. But uh, other, other than that, higher. They just don't, they don't, they don't know, they don't realize there you're, you know, you have an API sprawl when it's too late. Zombie APIs, shadow APIs, that stuff is, you know, it's not, not, it's not under radar. No. And they want, by the way, and they, and they, and they want, it's funny, not in the radar. But then sometimes they mention, well, I want tooling that will. Let me see this. So. Okay, that's great. So, but usually like to your point, they're not, um, likely not concerned. I mean we're not aware, let's just say not aware

Speaker B: and so, and so kind of, you know, in your story. So this API center of excellence gets practically, let's say removed. And, but the model that the company wants to move to is say instead of having the central body, let's make this self service. You know, let every team do the self service. Now self service is good, right? Center, uh, of excellence really is there to enable self service. Right. Because you know, centrally doing governance doesn't scale, but enabling other teams scales. Um, but then can we enable teams so much that they absolutely do not need any central oversight? You know, let's get rid of the central and everything is self service. How have you seen that go? Because that's almost like a fully federated model. You know, no need for any central kind of oversight or standards. Everything can happen um, in teams. So tell us the story of what you've seen when COVs have been jettisoned and everyone is just trying to do things in future teams.

Speaker A: Well, the first thing that I see, I see a lot of pain, a lot of stress. I, you know, uh, this whole shift, left, shift, left shift, left. Okay. And what I saw was a lot of these small teams who now have to own a lot of responsibility on their plate. A lot of stuff that they have to own it. That is just massive amounts of stress that they have to go through. It's just uh, almost uh, you know, inevitable. Right. And so what I, what I, what I did was try to continue, had other responsibilities but continue to help. I know I, I, I care.

Speaker B: Right.

Speaker A: So I'm just trying to continue to help as much, as much as possible. But yeah, to your point, yeah, There's a lot of cognitive distress. Oh, infrastructure, yeah, go ahead and handle it. Uh, you know, you're doing infrastructure, you're doing this, do that the other. And, and in all those aspects, governance is in there. It's just not, um, again it depends on the organization is not weaved, uh, into the tooling. It's not weaved. Like I mentioned to you in my survey, the compiler, right. It's uh, a developer doesn't think about it, say, okay, here's the version, I'm using it, I'm coding and it's doing this work, it's translating bytecode, blah blah blah, et cetera. It's doing that so there's no friction there. It's just a part of the tooling. So that opportunity doesn't present itself, at least not soon enough. And so the developer, that team has to absorb a lot. Even when you're, remember the early days, you know, governance, what it looked like you had a document with a checklist and a human walking around, human engaging, engaging. And then it goes, and it went faster when you now apply code. Right. Infrastructure as code and whatever, as code. And that's an awesome opportunity to have governance just get in there.

Speaker B: Right.

Speaker A: Uh, you know, codify that as well. Right. And so, but that, I don't think it's happening fast enough, at least in my exam, in my example. We just have to go, go, go, go, go. And the team has to own everything. Everything, everything. And so it's just pretty uh, pretty tough. Pretty tough for those folks.

Speaker B: Yeah. And I think again when we were talking in kind of my survey, you were talking about embedding gateway config enforcement, you know, for the things, for the controls you embedded in the gateway or in the CI CD pipeline, you know that even though a team is in there, that's, that, that lives longer. Right. So the, the goal really is to embed as much as you can in the, in the automation. Right. To make sure that you have, that you have all that built in. But um, yeah, it's good to know when, what happens when that doesn't happen when we're not building, in

Speaker A: building.

Speaker B: Um, but that also brings us that, bringing us when we start talking about automation that way, uh, bringing us to our ah, favorite topic of everyone is AI, you know, and seeing how do you see when I talk to a lot of people now a lot of people or teams I talk to are focusing on making sure that their APIs are AI ready. And some would argue that's just good, that's just good API design and API governance practices. Anyway, so there's, there's nothing perhaps you know, too different with um, um, making them AI ready. But you know, some, some would, some would see differently. So what do you see in terms of how. Not just the, so on one side, the consumptions of APIs, whether that's through APIs, or we're providing MCP servers for consumption for agents, but also on the build and governance side. Right, how AI is helping a lot of the. Both in building out the APIs, designing the APIs, and then governing, governing the APIs. What's your thoughts on that?

Speaker A: Like, you probably suspect it's faster now. It's much, much faster now. Um, you have to, in a way, you got to fight fire with fire, right? You have to. That's why I think that's why I've been thinking about, okay, and probably I'm not the only one, but I'm um, putting together, thinking about, okay, how do you. I think to me the key is of course like, you know, API ops plus AI, get it embedded even. Don't even, it's, it's built in, you know, don't even. You have to think about it too much with, of course, with the right balance of human in the loop, you always have to. I think at least for now, at least in my opinion, you still have to have that putting together like for example, putting together a skill. And I, and I said to myself, I'll say, okay, maybe I can pick, uh, I'm a big fan of the API ops, uh, cycles, the methodology. So I built a skill of that. And then below that, you know, you have references to OS, API top 10, you know, lots of different best practices, et cetera. And then eventually you might have reference your company style guide. I mean, but you have to of course codify that or at least maybe turn it into some sort of markdown file with the right semantics. Right. And so being able to do that and invent that, okay, if they're using AI, maybe using a, like uh, a cloud scale or something, something along those lines where you can aim it and throw it in your pipeline as well as you have building more, your pipelines are more agented, for example. So basically I'm sort of experimenting with uh, that idea, you know. And again, I probably are not the only one you probably heard of. Other folks are probably doing something similar basically along those lines. So that as you're, as you're working, the agents are picking up, they're sort of determining that your methodology or your approach is drifting Right as right there on the spot, not maybe after the fact or anything. In other words, across the, across the life cycle. So that's where the design, the thought process should be to say okay, here's a skill that should apply. When do we trigger that? What are the hooks? Right? What are the events throughout the API lifecycle? Whether you're ideation all the way to. And if you're fortunate enough, all the way. If you, you've been part of the same API until it gets deprecated and sunsetted, you know, where, where does that happen? And you know, so that's more or less what I'm, what I'm thinking. So I've got, I mean I'll, I'll, I haven't get a reprochet share with, with what I have so far and I still need to test it. But uh, yeah, so something, something along those lines because this is going, this is going faster and faster and, and of course as you know, Okena, the, the lack of context, uh, is very important. I think governance is. So I'm not saying this is, I'm not sure if this is like a golden age of governance, but at least there's. So these agents, right. The context is very important. The ambiguity. You have to be very, very explicit as much as possible when the human was reinterpreting your instructions and your steps and your poor documentation making it. Now the agent won't do that. Right. It'll try to, as hard as it can to please you to do the right thing. And that could lead to bad, bad things. So you really, I'm sorry, developers, AI people. But you're really going to have to put more thought into how you describe those APIs and the right balance, et cetera.

Speaker B: Absolutely. And lots of people are using that. I've talked to people who are using that. You know, um, the drive to be AI ready if you like, in enterprise to make sure that the documentation is good. Right. All those hygiene things are there, the API documentation. Because if that thing is really poor, then that's going to hamper the, you know, the, the vision of that uh, agentic consumption. If I just step back a bit to the kind of looking at the operating model again, the people side of this, you know, imagine you have a head of platforms or kind of enterprise architect or someone like that who says, look, we do want to set up a center of excellence, right. We want to set up some API governance group. What are the, you know, two, three things you would ask them to. You want it to be top of mind for them in setting up this group. Group, this group. What are the top two, three things you'll tell them across? Across everything. Across the people, the processes and the technology that they're using it. What are the gotchas they need to watch out for?

Speaker A: Well, yeah, that's a great question. I mean that's really. Yeah, it's awesome. I would say um, if I was to start again and then walk into an organization said okay, of course you have to take stock of where, where you are obviously. But I would definitely look into API Ops obviously and then apply to just Automate. Maybe not automate, but just, I'm not sure, I don't know. People get really hung up on automation, what's automated or not. But let AI assist you in some of the simpler tasks when it comes to uh, whatever all the concerns when it comes to API ops Rome. So definitely invest into that, right? And then one problem that I know I have and from time to time is the roi, be able to, the ROI loop, so to speak, uh, be able to have that team or those champions be able to explain that return on investment on APIs and uh, you know, very, very succinctly like the ops metrics, the onboarding, uh, you know, the business capabilities, all things that really matter because then that forces you to have say, better conversations with C levels, right? The GMs, right? The folks who are basically driving or supporting these initiatives, you know, like the same, like I barely had opportunities to actually have that kind of ah, talk to say, okay, how are APIs are consumed in our organization? Be able to explain that, that, that alone is a, it can be a difficult conversation. So be able to be ready, be ready to have a, to do that or, or at, at least if you're say in a center of isolate. Be able to educate, let's say the other teams, the other folks across the organization on aspects of roi. And then why is it that you're doing and, and because of that point now don't go just go crazy. Let's do AI, right? Everyone's rushing to do that. Great, that's fine, that's fine. But don't forget the experience that you have. Don't forget the ROIs, don't forget the APIs, because it's APIs all the way down, right? I think I've heard of that phrase before, uh, some folks in the community. So just don't throw away what you've done in building interfaces and past digital transformations. You went from soap to rest or combination rest to GraphQL, et cetera, just, um, you know, keep that in mind. And um, you have to. Right, because if you want to claim that your, uh, APIs are going to be ready for um. And yeah, you have to go back and definitely take, uh, a closer look. So that's what I would be good. Because especially that ORI conversation. Just to say, this is what we're doing, this is where we're going next. ROI is this, ROI is that. And keep going, keep going. By the way, we're investing in vi, OPS and AI, of course. Uh, and basically those two and everything else should be able to sort of trickle down from there.

Speaker B: Yeah, definitely. That's definitely, uh, um, a powerful argument to support that investment. And another thing I know you've also, you just talked about as well, you hinted at training, right? Like being able to train, support that enablement, if you like as well, involves training. And yeah, how do you see that again? How important is that in terms of embedding governance in the, in the organization or embedding this to say, look, this is how we build APIs in this organization. Right? Because I've seen organizations who have that, they offer that API specific training for new engineers to say, no. And this is not just generic, you know, this is how to build the REST API, but this is these resources, this is how we build our APIs. These are the results. This is where you find our inventory. This is, you know, is that kind of. Yeah. What, what do you think about that? That kind of.

Speaker A: Yeah, that's great. I mean, exactly. So that's one of the, one of the reasons, like, you know, when I joined Postman, you know, as a technical trainer, I said, okay, this is an opportunity to talk to a lot of customers about those concerns. Even though, even though you're talking about the platform or how to do certain things. But I go, by the way, this is what you were thinking about, maybe what you were not thinking about, discovery, et cetera. This is how you use with, you know, with the platform. So, yeah, education is a big, big, big, big deal. You know, like I said, I've met a lot of, uh, developers over the years and they sometimes. What do you see nuances of API design in these. Well, how do you make this API bubble? It just doesn't, it doesn't. I think they kind of get it, but they don't actually put it into practice. So that has to be a continuing, really a continuing effort, to be honest. I mean, once you, and I think it goes beyond like, okay, you take a course, you watch a couple videos and then it stops. And then like, okay, then you're back to the day to day grind of building APIs and as fast as possible. And so it should be more like uh, like I said, the, the, the embedding piece. Make it sort of bring in sort of, sort of assist that developer now that they want to uh, say building skills, for example, building. Take, here's the governor. These are the set of ideas built it into agentive workflows, whichever those may be, make them part of that, not necessarily hand them off. Of course you can always consult with maybe more experts, et cetera, maybe people like yourself, et cetera, but at least get them into that mindset. Right? Um, that's really the challenge, really the hard part. I mean especially like you meet a lot of folks, uh, especially new projects, they hire a bunch of developers and oh, I just do UAPIs in company A and I came from company B and I came from company C. They all have the different strategies and mindsets, etc. Which is fine to some extent, but that is really fragmented. So they have, they have to have that conversation or even people to facilitate it. You know, that's uh, I mean that, that's definitely important, I think basically to be able to facilitate. Okay, why do we need APIs, know the design and developability and all those things. And ongoing, I mean. And ongoing.

Speaker B: Yeah, that's really good. Thank you so much. Thank you so much. Miguel. This has been fascinating speaking with you. Um, and thank you. Thank you so much. If people wanted to find out more about you, kind of, uh, maybe connect with you, find out more about you, what you do, where can they find out more?

Speaker A: Uh, uh, email's fine. Uh, makemakermail. Ah, dot com. Um, where's. I don't hang around much. In Slack, maybe, uh, uh, in LinkedIn, of course. Maybe in the open API Slack, uh, channel. Sometimes I'm hanging around there, try to answer a few questions here.

Speaker B: All right, I'm sure I will bump into you again somewhere very soon, but thank you so much for being on the show. Really enjoy chatting with you. Miguel.

Speaker A: Yeah, yeah, thank you so much for having me. It's been a pleasure and uh, great conversation and I love your questions. Yeah. Again, very honored to spend some time with you. Thank you.

Speaker B: Thank you. Bye. Bye.

Speaker A: Bye.