James Pozenel, @dominos

Thank you for tuning in to today’s episode of the Breaking Changes podcast. I’m your host and chief evangelist for Postman, Kin Lane. With Breaking Changes, we explore topics from the world of APIs, but we look at things through the lens of business and engineering leadership. Joining me today we have James Pozenel, solutions architect at Domino’s Pizza. I really enjoyed learning about James and his team’s pragmatic approach to API design and how they balance the needs of their global operations to deliver secure and reliable APIs.

I always start simple, start with the basics. Who are you and what do you do?

Yeah, my name is James Pozenel Junior. I’m a solution architect at Domino’s Pizza. I’m currently building an API to replace their entire in-store deployment of software, and that’s based on a microservices deployment. So we have about 20 microservices, all with their own APIs and OAS, and I am one of a handful of architects helping to create the API, the API-first development.

I really, when we talked earlier, I was intrigued by your view of microservices and the landscape, because I think you have a very pragmatic view in a realm where there’s a lot of dogmatic and religious zealots about what is or isn’t a microservice, what is or isn’t an API. So what is a microservice in the context of your operations? What does it do?

Right, so a microservice—I think I’ll point to Chris Richardson as kind of one of the guiding lights for my pragmatism, I suppose. Microservices are just services. They do a job, they encapsulate some sort of logic that you want done. And so it’s really about the abilities of those services. I think Chris Richardson really talks about the fact that the abilities are what makes a microservice a microservice. This changeability, configurability, these kinds of things. It’s able to change on the fly, is essentially one of the big things. And I think for us, we have a really big landscape to cover. We’re a global company, we provide software all around the world to 86 different countries, many different languages. And if we’re making that piece of software to put in the store that’s in France and the store that’s in Canada and the store that’s in the United States, it’s got to be flexible from the very beginning. And so there’s a lot of abstraction points that I think we emphasize over maybe some of the other things that microservice people will kind of value, like event-driven architecture or things along those lines.

So there’s been a lot of focus over the last 20 years, or 10 years especially, on resource-driven REST, RESTful APIs, and people get very dogmatic about defining resources. But there’s a lot of patterns out there. GraphQL’s gained a lot of momentum, RPC is still very, very used in a lot of large—Amazon has a lot of RPC solutions. So what do you practice? How do you view resources versus actions and other things that need to be taken? How do you approach the design thinking behind this?

Yeah, I think this is really important when you start valuing the abstraction over a lot of other concerns. You need to plan almost all the time in a resourceful way out, right. You get caught—and it still happens, no matter what you do you get caught kind of in a corner where you’ve painted yourself with—let’s say you decided to opt for a string value for some key, or an object over an array, or whatever choices you made in the data structure, and then you realize six months later or a year later that you’ve put yourself in a corner. And so for a resource, sometimes we will—let’s say we have an ID of something. It’s an ID, it’s in another service, but we want to keep some information about that external service in this local service. And so we say, okay, well, we could just say there’s an ID here that points to the resource in that other object, or we could just lop off the word “ID” and just create an object out of that. Let’s say I’m a transaction ID or something like that, and instead of saying transaction-dash-transaction—and this is an object. I may not put anything in there other than ID, key-value pair, but I’ve left myself a way out in the future, like when some other business requirement comes along and they want—I don’t know, something else has got to come here that was in the transaction table, the resource over there, and now we want it over here. And it cleans up stuff. You don’t have all these keys that you keep adding. You kind of have the space that encapsulates a certain concern, which gives you power to abstract that too. So I think that’s one of the things we do.

I think the other thing we do, going kind of against the grain of dogmatic REST—which I totally appreciate that architecture—it was really hard to convince me, when I joined the team about three years ago. I kind of came in, they said, oh, we’re going to do HATEOAS. I’m like, oh, awesome, we’ll get to go HATEOAS. And that didn’t work out. And then they’re like, we’re doing this stuff called operational endpoints. And I’m like, well, what’s that? And they’re like, well, we just use this signature in the URL, we say it’s an underscore, and then we talk about what it’s doing. So it gets into RPC land where you’re saying, like, “open the business day.” Let’s say you have a business day resource. You don’t want just anyone changing the status of the resource. You want a process to unfold that will go through several steps and eventually get to a point where it can say it’s open. But you don’t want the client to declare that it’s—to mutate the object themselves. So this is an RPC way to kind of set a job. And I was like, okay, this is weird. And then he was like, well, this allows us to do security on that endpoint. You could say it’s a job. I’m going to set up a jobs endpoint and accept a bunch of jobs, and they could be all sorts of different kinds of jobs, and I could tell you to go look at the job representation once you’ve started it. But you don’t have fine-grained control over who can input into the jobs resource, and you kind of have this mismatch of tons of schemas that could essentially be accepted. So it really hones in on, I want to do this thing, and I want to let the client start that, and I can control the access at a security level too.

Well, and it feels like a lot of APIs I see are CRUD—create, read, update, delete. And when you see enough of them and you integrate with enough of them, you realize how it’s very caveman kind of vocabulary, create, read, update, delete. There’s not a lot of nuance to it. You can do a lot across a lot of different resources, but where you all have gone is much—I would say improving on that vocabulary, because we’ve got our nouns, our resources, and then we’ve got our verbs, our actions that we can take, and you guys created a nice little underscore in between them, and how we can start having more nuanced conversations. But then a layer of security or role-based access control based upon whoever’s consuming it: here’s the vocabulary that I can hear or see or have access to, however we want to describe it. So it feels like it’s a pretty—back to your pragmatic nature—it’s a very pragmatic API vocabulary is what I would call it.

And it was funny when he was convincing me of how good this idea is, he’s like, what’s the alternative? And the fellow that’s moved on, Jeff Nadeau, he’s at Salesforce now I think, he was like, well, what’s the alternative? I said, well, I guess you just need more verbs. And this gets to the whole problem. We have the caveman vocabulary—which I love that analogy—and so what’s the answer? We need more verbs. So we got a couple, but varying degrees of acceptance. But I think we could rally around a little bit more vocabulary. Search feels like a no-brainer. And there’s the others—closing things. I think there’s enough commonality around processes that you could probably develop another set of verbs that deal with those things. Even, like, “process” as a verb: do a process on this resource, and here’s the kind of processing I want to do.

Yeah, so you can get much more precise, you can benefit from the ubiquitous, low-cost nature of HTTP and the verbs and the structures it gives us for vocabulary. But that, as people like to point out, fails us pretty quickly in some areas. But now we’re able to go get more domain-specific for our businesses, for our industries, using this vocabulary structure. With this said, I’m going to pause here because I’ve got to shut my door. I made a mistake and didn’t actually shut my door and it keeps getting loud. So one second, I’ll be right back, and I’ll edit this out.

[Resuming.] I got interested in talking to you and didn’t run down my checklist and think properly. So, the expansive vocabulary I think is really critical here, because the successful programs I’ve seen are the ones who are learning to speak in a way that their consumers understand. This is why language is so important. You have a common set of ways that we communicate about things, and it can be done in a self-service, automated way, hopefully with light, not too verbose documentation. But it really helps get people on the same page from a producer and consumer side, but also other technical or business stakeholders involved in the process.

So you mentioned something earlier about this being defining jobs, and this is very much an approach to APIs that I see more and more, and it’s bringing more alignment with business stakeholders—looking at API design as you’re defining a job that needs to be done. So talk to me about how you guys see things as jobs, and how does, like, domain-driven design—do you guys have ways that you carve things up into bounded contexts? How do you approach it?

Yeah, so I think first of all, we got a lot of services, so that kind of gives you some natural boundaries. And not every service that’s interested in a particular domain needs the same view of the domain. It can still be specific to the needs of a particular service. Like payments is a good example. The payment service really cares about the nitty-gritty about what happened when I talked to the payment processor, and we’ll probably have lots of data that something like the ordering service doesn’t need. Like the cart service doesn’t need to know the EMV values of an inserted card or other things. It just needs to know that the order is paid, that this order can now go over to the next step and be shipped out to whoever, or put in a pizza oven, for example. So I think that’s one way to run a domain across a couple of different services—just being really considered in the approach to the data you’re going to store there, and trying not to—this is another thing that can happen too—duplicating data across all these resources. So you got a payment and it has some very specific data, and if you start marrying order information into the payment, and that order information is mutable, now you’ve got to mutate the payment too because it has a representation of that. And so this gets into abstraction of the resource itself. How do you provide enough of a pointer to the thing that you’re concerned about without putting too much onus on keeping everything in sync together?

And so a lot of abstraction applied in this particular set of microservices around the payment service—it just takes payments, it doesn’t really know why it took a payment. It has like a memo line on a check. That memo line on the check says that’s for this order over here. If you want to know anything about the order, you go over there and look at the order. And this gets into HATEOAS too, and this is my sneak-around when they said we’re doing HATEOAS and they said we’re actually not doing HATEOAS. I was like, well, I can still make it happen. So that little link—basically it’s a link, I’m saying there’s an ID in another service, you can go over there and look at it. I don’t have the actual constituted full URL for you, you’ll have to supply that, but at least I’ve made it so the subject of this payment exists somewhere. And that could be in the order service, it could be an accounting service, it could be somewhere else. But we took your payment, and that’s it.

Yeah, keep bounded context, keeping things isolated, but still with the references to the other domains and where you can find stuff.

Yeah. And so, you’ve mentioned a few times having to sell this to stakeholders, and you had to be sold, you had to be convinced as part of this. So what’s the journey look like? You mentioned this other person has left. What’s been this journey as far as who are you selling? Is it technical stakeholders, is it business stakeholders, how have you made this happen?

Yeah, it’s definitely been a journey, from going kind of like, I’m just making an API and passing this by my peers and my boss, to being in a different role and being more of a designer—designer in the sense that—I come from the front end originally, I was a front-end developer, I did PHP and HTML and CSS and JavaScript and all that stuff, open source. And 10 years ago, the big deal was A List Apart. I think it’s still a big deal, they still put out stuff. And they had these books. One of the books is by a front-end designer, just a guy who makes things pretty, and he works in his own shop, as a man selling you a design to a business. And I just read this book and it’s fantastic, but he’s talking about stakeholders, dealing with stakeholders. And so the stakeholders here are really not just the business, but also the technology. Domino’s is kind of an interesting place to be, because the technology is a revenue source. We make money for Domino’s Pizza, because we sell all the software that we make all over to the franchisees in the United States, the master franchisees across the world, they buy this stuff. And so we’re not a cost center, we make money. And so this focus of selling software means you have to pass it through your own IT staff to get their buy-in that this is a project that should receive funding, that should take up valuable resources that will be turned into profit somewhere down the line.

And so dealing with your stakeholders and trying to keep them focused on requirements—they want something done, they want some piece of software, they want to solve a problem. And what happens all the time is they keep telling you how to solve the problem. But you’re the guy that they hired to solve the problems. And so, trying to gain the trust with them—like, I’m not trying to bust your bank, I’m not trying to say no to you, I’m trying to get you something that is going to be worthy of resale across the entire globe. We’re talking about an API, a whole platform of services that we’re going to sell to you and let you either put it local or it’s a service that we maintain. They have to see that there’s value to it and that it works with their environments, with their own business processes, because they’re all different depending on where you are. And so it’s all about gaining trust and getting them to let go of their solutions to the problems. So I think I spend a lot of time now trying to get people to focus on what their problems are so that we can solve it and stay consistent.

Yeah, because at the end of the day, I think the design aspect is a pivotal part of APIs—that you’re creating an experience. It could be a developer experience, but it’s wider than that, like an API experience. What’s it like to use all these APIs across all these services on this platform, or even on another product line? Like, I’ve got this set here that does this stuff, and I got some other add-ons or other products, and what does that feel like across the entire enterprise to use those services? And a lot of times you’re talking about lots of little smaller teams, these microservice-centric teams. They all bring their own ideas into it, which is great, they’re all doing their architectures, and they’re empowered to do so behind their service layers, even in the representations. But what do you want it to be when it is looked at in a holistic manner, from a top-down kind of observational point? Like, does this all kind of make sense and look the same—not the same, but has a rhythm of vocabulary, of how these things all work, this idea of these operational endpoints, these underscore things that do some sort of RPC thing as opposed to a straight-up resource? Can you get that across your entire ecosystem? And that’s what I mean kind of by API experience.

Yeah. And you’ve evolved it and taken it—I’ve seen APIs evolve from being—and still in a lot of enterprises they’re still earlier on in their digital transformation, whatever we want to call it—but APIs are just a checklist on a project or on an application. The API is rarely a product in and of itself, or even seems to need an experience. Why would you need an experience for such a technical thing? But the groups who are further along in this transformation, this journey, they’re seeing APIs as a product. And this is the journey that you just described, you’re reflecting. And it requires more feedback loops with stakeholders, because you mentioned keeping it something that convinces people globally that they’re going to want it. That’s got to require some serious feedback loops to stay in sync with what people are needing, I’m guessing.

Absolutely. Each individual engagement is another opportunity to look at what you’re doing and see where you missed, because you’re going to miss, no doubt. And how can you solve your way out of that without breaking things, because you don’t want to break stuff. And where’s the good stuff, where were the wins in the designs that you had? We set up these abstractions through the payment service to take all different kinds of payments, so when someone asks for a new one, it’s a known quantity, really, what it takes to set up plumbing to do it. The hours are going to be the same every time you ask for another kind of payment to flow through the system. Where it gets variable is, what’s the integration with the provider? Because that can be all different. It could be XML, it could be segmented data sets at some bank. But you get benefits in these abstractions—they give you ways to reliably plan what it’s going to take to do something.

Yeah, you’re getting a much more known landscape, known set of capabilities, enterprise capabilities and resources that you have. It’s just a lot more knowns out there. And so I see a lot of telltale signs that I see with other conversations I’m having—people who have a known landscape, understand their digital resources and capabilities, have ways of planning around these abstractions and evolving and iterating, have these feedback loops in place—they’re usually hitting a point where they respond. It’s not just a request-and-response structure, it’s they need to respond to events happening, these more meaningful business events. So what’s your event-driven landscape look like, from webhooks all the way to asynchronous real-time, all of that?

So right now we are doing eventing. We really like the kind of synergy between AsyncAPI and OAS, and we’re using OAS. So I think a lot of our modeling is around that standard. We haven’t taken it all the way, we haven’t said, oh, we’re just going to do AsyncAPI, we’re going to publish all this stuff, it’s going to be amazing. But we are taking a page, at least in the resource modeling of an event, how that looks, and we can say, okay, well, here’s the schemas for all these events. And we haven’t bit off on something like a message queue, because time and time again they’re problematic. Everybody kind of has their complaints about message queues and how they play out in the vendor landscape. So we just developed a simple outbox on each service. It’s part of the base code that every service will get, is an outbox where they can publish their events. And so it’s not pub-sub either. It’s just, we’re putting it there and there’s an endpoint to go look at it. So it’s just another resource, essentially, in the service that interested parties, interested services, can go look at to see if they need to take some kind of action or not.

So we’re going really lightweight, where everything’s internal to each service, nothing gets lost. There’s no communication loss. When the service who controls the event publishes the event, it goes right to persistence, and you can go look at it anytime you want. So again, like that whole networking stuff—you just gotta, message queues present problems, and when they go down, they go down hard, and they cause lots of problems when they come up. So let’s just keep it local, and anybody who needs some updates because they were offline, or they’re just brought up into the container, can go check on what they might need to care about right now. So that’s been our approach: keep it low-level, keep it simple stupid, don’t let the events bring down everything around you.

Yeah, another very pragmatic, resourceful—I don’t want to say hacky in a negative way, but it, similar to how you married verbs and nouns together with the underscore, that’s pretty hacky, but it’s hacking in a good sense for me. I think these quick-and-dirty solutions—I was doing another interview with a customer earlier this morning, and they were talking about how many times someone throws Kafka at a need for event-driven and it’s just so overkill, and they don’t need it, they don’t need to go that far, but they did, and so they over-thought the problem. And I feel like with API design, back to how we design our APIs, so many people just go overkill. And it just feels like you’ve got these pragmatic approaches to keeping it simple, lightweight, scrappy, and not over-investing and going too far.

Yeah, we looked at Kafka, we looked at a time-series database at one point for some other concerns. There’s a lot of auditing mentality, kind of adding up stuff that happens over the course of a business day for a franchisee. And we just couldn’t justify it. Is this going to be so important that we have to buy a product and a huge miter saw in order to do the work? We’re like, well, I just need a hacksaw and we’ll be fine. Keep it simple. Anytime you’re going to rely on the network, you just gotta think it’s going to go wrong. And when you’re an enterprise of this scale—we’re the biggest pizza company in the world or something like that, and we take millions of orders during the course of the Super Bowl—it’s just crazy, and it cannot fall down. We have to take that order, we have to process that payment, we have to do all these things. And so anytime you introduce another network liability, you’re just increasing your chances. It’s all math at that point. It’s not that it might happen, it will happen no matter what you do. You’re going to drop millions and millions of transactions, interactions, upon an API. You can’t take a chance.

Yeah, I think you have a really healthy, pragmatic view of how to approach this, that I find refreshing, because I’ve gone down every rabbit hole technically. And the hypermedia—I fell in love with hypermedia early on, and as a database guy I really like GraphQL—but I always have, like, this is too much, here, we just need it to be scrappier, lightweight, simpler, easier to do. But you can still do that at scale, because you guys are not just doing that interpersonally, you’re doing a global, all the franchisees, and that kind of scale that the Super Bowl would need. It’s just multiple levels, but pragmatic, simple can do that. And you just gotta keep it simple and keep it usable.

HATEOAS—I remember us all hanging out at API Fest in Detroit, speaking of HATEOAS again.

Yeah, that was—just for the listeners, one of the first places we hung out in person was Detroit, 2013, 2014, I think.

I think it was 2013.

I’ll have to look back. And I had a panel. I pulled together a panel of the top hypermedia folks to discuss—it was right at that time where it was before GraphQL, but it was a—hypermedia was going to dominate the landscape. And there are some interesting implementations out there that I think are interesting, like AWS API Gateway is using HAL. So it’s really interesting to pull these folks together and have a conversation about which ones are better or worse. And HAL is one of the simpler ones, and I think it’s the one that I’ve seen the most implemented, if I’m correct.

Yeah, I agree. It’s got some beauty in keeping it simple, keeping it really low-cost and doing the right things, using the standards, not trying to do something new. It was leveraging just what was out there. These are attributes on HTML tags that were defined years and years ago. Really easy stuff to get your head around. It’s a link, it’s using all the attributes, it has all the benefits. A bunch of stuff comes along for the ride in that standard. That’s great.

Yeah, it’s ubiquitous. That’s why HTTP—I think people keep trying to come along with a startup and say REST is done, RESTful APIs are done, we’re going to replace REST. I’m like, okay, but it’s just built on the simple web, it’s kind of grown organically, I think you’re going to have a hard time doing that. But every new trend or technology comes along and wants to capture the mindshare of folks and provide these solutions for us. So how do you think about what’s new and the latest technology without being captivated by the VC myth and the problem-solving promises, and just take that pragmatic lens that you have?

I really think that part of it is, there’s a lot of focus on just the DDD, the domain-driven design. We don’t talk too much about what technologies we should use. We want really good resources, we want stuff that is capable to expand when it needs to expand, that is flexible enough to talk in lots of different contexts. And that’s where I think we spend a lot of our time focusing. It’s not the details behind the API that are necessarily a hundred percent important, or around a particular architecture. It’s really about having really good resources, so that the business throws you that curveball and you go, oh, that’s no big deal, I already got this one right. You want more of those out of your design than you want, like, let me go sit down and think tons of hours trying to figure out how I’m going to make this weird thing work. You really just want to leverage what you got and have the flexibility in all these places. And this is the abstraction areas where we do typing, and we say it’s a type of a thing that’s coming through, it’s going to flow down a different track somewhere down the line. But as it passes from system to system, nobody cares what it is as long as it meets the contract, it meets the interface contract. I need an object of type X. Well, we keep passing type X until it gets down to the place where we care about type X. And so the APIs carry a lot of water for a lot of different people, front end or an integration. But try not to make it part of the central concern of the API. You’re just trying to get data from point A to point B. Don’t make it overly complex. And so I think those are the things that become valuable and get you to be super flexible, and just kind of, yeah, we got a spot for that, we kind of planned. We thought maybe—sometimes they don’t work out, sometimes it’s got like a weird appendix sitting in the middle of your API design, and you’re like, yeah, we had plans, it didn’t work out, but it didn’t cost you anything too much to do it.

And I’ve been in this business long enough—I don’t troll people too much, but occasionally I’ll put out on Twitter, I’ll say, you know, APIs don’t matter. And I get a bunch of my people who jump at me and go, oh no, it totally matters. And I’m like, no, it’s actually—it’s your team’s capabilities, your strengths, those muscles that you learn from doing APIs, it’s those feedback loops that you have in place, it’s that trust you have with your consumers, it’s all of these things being able to play out. And yes, you’re building and designing new APIs and you’re iterating existing APIs, and that’s what carries the load, but that strength of your team is really where the value lies, and your ability to create contracts that matter and are meaningful to your business. But it’s more about people than it is about technology. And that’s what I’m hearing with your pragmatic lens, that it’s your confidence in your own ability, not the latest vendor tool or technology to come along.

Yeah, I mean, design—I really like this concept. I don’t think computer scientists think a lot about the implications of a design. It’s always the front-end guy who cares about that stuff—here’s how it looks nice. Everybody else is trying to get data from one side to the other, and that’s cool, that’s super pragmatic, but it doesn’t buy you much. It does get the job done. But what’s been really unique about Domino’s is—they were transformative, really, before. The stakeholders developed the architecture for these things that they wanted to sell, and then they give it to the developers, fine. That works for smaller companies, or even lots of places do it and they’re just fine. But they really put an investment at the start of this project, about five years ago, a little bit before my time, that they would place architecture at the center—not as a bottleneck but as an accelerator. To say, okay—you know, every developer in my mind’s an architect, whether they know it or not. When you give them a task, they’re architecting that task, they may not have a lot of experience in it, they’re going to make mistakes, and that’s not to take away from anybody, it’s just to learn those things. But they put this team of four or five people together and said, you’re going to be concerned with the API and how all these services interact and how do we get everything done, and that is your only job. As a solution architect, this is the only thing you’re going to do, is design an API and make it the best damn API you can with whatever you have in front of you, whatever you’ve collected over time. You’re going to make it the best.

And I think that approach—some people argue with me—that approach is pivotal when you’re at this scale. And we’re hand in hand. It’s not just solution in an ivory tower, it’s hand in hand with the app architects, the guys who are doing the implementation. We’re bouncing ideas off each other, we’re talking about limitations or advantages in the individual implementations of certain choices in the code, or tools that we have or want to use. So we’re constantly talking to one another about how this is going to play out, where’s the gotchas, where did we miss. So it’s not just we come down from on high with some stone tablets and say, here’s the law of the land. It’s a conversation. There’s not a lot of throwing over the wall, that kind of mentality doesn’t—

Yeah, but it sounds like you have a lot of breathing room, though. I encounter enterprise org after enterprise org where they’re like, you know, this design stuff sounds great, but we don’t have the time, we’re putting out fires, we’re responding to things, and their culture is very different. But it sounds like you guys have a little bit of space, breathing room. How do you acquire that space? How did that get established? Is it leadership, or is it through your practices?

I think it’s both. The leadership took a role, kind of a bit of a gamble. You’re going to sink some dollars into some guys, and what benefit are they really going to give you at the end of the day? And so they took that gamble. But I think it’s ours to lose. As the people being given that space, it’s ours to lose at every month, every solution, every handoff is ours to lose. So that trust and that work and all the conversations that go on with the app architects and the DevOps team and the business themselves—that’s what it’s all about. And I reference Mike Monteiro’s book Design Is a Job—he hits those things too. You have to have these relationships, you have to gain trust, you’re not going to go anywhere as a designer without trust. And so every engagement is a spot to gain more trust or to lose trust.

And in the end, the places that you don’t have time for that, where you’re putting out fires—it’s like, well, why are you putting out those fires? Because you made hasty choices, could be, or you’ve had a series of hasty choices over many years, some of them that you’re not even responsible for, as an individual on this team. It’s the buried bodies and the history of your organization that you have nothing to do with, but it’s yours to sort out and deal with in the end, because you’re the one on the hook to provide the solution. So I think that’s what it all boils down to: trust, and gaining trust every single time you make a change to the API.

Yeah, I mean, the name of this podcast is Breaking Changes for a reason, because you’re going to make or break these relationships and this trust. And I really identify that as the important piece of this. You gotta bring it home when it comes to—and for me, breaking changes don’t actually exist. There’s not-communicated changes, there’s hastily made—there’s many other things. The breaking change doesn’t exist. There’s just all these other human aspects around it that we neglected or messed up, and that was visible as, I think, the breaking change.

So where do you get your information? How do you stay knowledgeable on what you need to accomplish each day?

I feel bad about this, that I don’t read a lot of technical stuff anymore. I do a lot of stuff by gut, and I always have. I certainly have the RFC for HTTP bookmarked and reference it quite often, and also other specifications like OAS. So the standards are super important, and being able to help my team understand how to write that stuff is super important. But, man, I feel really weird saying, I really don’t—I’ve been at this, at this point it’s like 10-ish years in the API space, and it’s not all rote memory, it’s really that synthesis of the business with the API, these strategies about the APIs that you need. Really simple stuff, pragmatic stuff, don’t need a manual.

Yeah, this is back to—the value is in your muscle memory, your ability to respond, your confidence, and the standards are scaffolding for a lot of that. But you’ve just practiced and practiced and experienced, and that ability to respond and iterate and have the feedback loops and have the confidence—this is what API product management and APIs are about. A lot of enterprise organizations come to us and go, well, when are we going to be done with this API thing? It’s like, you’re never going to be done. The iteration and the strength and being able to respond and iterate is the API. It’s not that instance of your API or the design of the API entirely.

So the business is not going to stop growing, the business is not going to stop asking for changes. So how do you support them every day, in whatever they want to do, however crazy it is? I think that’s a great way—I’m going to end on that note right there, because I think that’s important, and this audience is going to enjoy it. I really appreciate your time today, James. This has been great. I love catching up with you again. We’re going to have to find another excuse to do another episode down the road.

I’m down for it. I’m so glad to get this opportunity. I really appreciate it.

Yeah, thanks for joining me, and I love your pragmatic view of things, and definitely keep eating your pizzas and supporting feeding the machine. Thanks, enjoy the rest of your day.

All right, you too, man. Take care.

Thanks again to James for stopping by. For more on James, you can find him on LinkedIn, and you can learn more about Domino’s Pizza at dominos.com. You can subscribe to the Breaking Changes podcast at postman.com/events/breaking-changes. I’m your host, Kin Lane, and until next time, cheers.