Unbundling the Enterprise

Intro

Erik Wilde: Hello, and welcome to the GOTO Book Club. My name is Erik Wilde, and I have the great joy today to present to you this wonderful book, "Unbundling the Enterprise." I have the two authors here with me, and I was really happy... So, I read the book. I loved it. And I proposed to GOTO and said, "Hey, we really should do an interview in the book club on this book." So, I'm really glad that we did this. And thanks so much, Matt McLarty and Steve Fishman, for joining. And maybe you can just introduce yourselves very briefly, so that people get to know you a little bit before we start talking about the book. Matt, maybe you can get started.

Matt McLarty: Sure. Well, first of all, thanks, Erik, for going to GOTO, and recommending the book. We really appreciate that. And we're very thankful for this opportunity. So, my name is Matt McLarty. I'm the CTO of Boomi, and obviously, the co-author of "Unbundling the Enterprise: APIs, Optionality, & the Science of Happy Accidents." Throw in the subtitles in there, because I'm sure we'll be talking about a lot of those things. But I'm based in Vancouver, BC, Canada. And it's just great to be here. Stephen.

Stephen Fishman: Just like Matt, thank you, Erik. Really a wonderful opportunity to discuss the book, and really pleased to be here. Thank you for making this happen. My name is Stephen Fishman. I'm the field CTO of Boomi. I live in Atlanta, Georgia. And Matt and I have been working on this for a couple years, and we're really excited about it. Wonderful to be here today.

Erik Wilde: Maybe I will complete things, then, by saying I'm in Zurich, Switzerland, so I'm joining from a different continent. Again, my name is Erik Wilde. I work for INNOQ as a principal consultant. I deal with these things all the time, so it was great to read a book that looks a little bit at the API as kind of an enabling factor, in a really big way. 

Recommended talk: DDD Today - Modeling Uncertainty • Vaughn Vernon • GOTO 2017

Embracing Uncertainty with the OOOps Process

Erik Wilde: As you already pointed out in the subtitle, it's about happy accidents. It's about making sure that you embrace your multiple options. Could you maybe start by just talking a little bit about the motivation for the book, and why uncertainty...? I mean, it sounds a little bit maybe not quite intuitive, but why is uncertainty such an important thing to embrace when you think about businesses, and how to succeed as a business nowadays?

Stephen Fishman: All right. I'll start with that. So, Matt and I, did have an inspiration to write a book about APIs, and very quickly, it became a book about APIs and optionality, as optionality being a significant part of the value that's yielded through the approach. But we did not necessarily set out to write a book about uncertainty and happy accidents. That found us, that one of the things that Matt was very insistent on at the beginning, which I'm very grateful that I listened to, was we didn't want to pontificate based upon our experience, and have it just be, you know, "this is what we think." Instead, we went a different direction, of interviewing more than a dozen of, you know, maybe closer to 20 different CIOs and execs from around the world. And hearing them informed the direction we went because one after the other after the other said the same thing. They might have used slightly different words, but it was, "We didn't plan on this. We had this architectural approach, and this other thing happened. The future found us." Every time, whether it was, you know, talking with the people at Google, talking with people at Slack, talking to the people at Coca-Cola, at Best Buy, and over and over and over again, every single one.

But nobody clarified that as that was their goal. It just kind of happened. And that is what happened, honestly, with the book. That concept found us through the interview process, and it became this organizing theme, throughout, of that instead of preparing for one future, prepare for any future, and that future will find you, and, you know, asymmetric value return will come, because of the nature of how the market changes. There's a deep cut in the book that speaks to the work of Carliss Baldwin out of Harvard. Real, you know, deep, you know, super nerds will, might've heard of the book "Design Rules." But Carliss says option value is high when consumer tastes are heterogeneous and unpredictable. And it plays out exactly that way, because the world changes very often, and people change what they like very often, and no two people really, you know, fully gravitate towards the same thing. And that's also true of enterprises. So, because of the way the world is, conserving your options and creating your options will lead to asymmetric value opportunities in the future. You just have to be ready to exploit it when it comes.

Erik Wilde: You came up with this wonderful "OOOps" process, which is, or, I was not quite sure whether this is O-O Ops, but that would be object-oriented, so that's not good. So, let's call it "OOOps."

Matt McLarty: OOOps.

Erik Wilde: You came up with this idea of how optionality, after you embrace it, then how to also make it work, right, because just creating options is, as a wonderful phrase and logic says, it's necessary but not sufficient. The idea then would be that this OOOps process gets you to the point where it's not just you exploring options, but also you being ready to capture on them and capitalize on them, and make sure you make the most out of them. So, Matt, maybe you could talk us a little bit through this process, what it's for, and what the different stages look like.

Matt McLarty: It's, branding is always good, right? We had sort of an epiphany around happy accidents. I remember we were, you know, talking about, we had... We were looking at pictures of Bob Ross. We had all sorts of Bob Ross graphics in it, for happy accidents early on, and then I think OOOps, OOOps came about because we were just trying to... Essentially, what Stephen said, bang-on, we wanted to discover. If APIs are the tip of the iceberg, what's the iceberg? Optionality was a big part of it. We went through those stories. And as he said, it's not like those companies were using a science of happy accidents. Right? It was more like because they created the options, they had these different places where things happen serendipitously. I think part of our ambition then became, well, what if you were aiming for happy accidents? What if it just wasn't serendipity that was happening? Could you come up with a methodology around engineering those happy accidents? And that's where the oops came from.

Optionality, obviously, is the first ingredient, but optionality isn't enough on its own. And I think, you know, one of the things that's really, you know... Again, we sort of take these APIs for granted, those of us who have worked in space for a long time. When you try to step out of that frame and look at things with fresh eyes, what is it about APIs? Well, they've decontextualized business capabilities, right? And that was a lot of what we were focusing on, is how do you decontextualize things... It's the fact that they can be decontextualized and then recontextualized in different ways, that makes them so valuable. What digital business gives us, I think, is, if you take the technology away, and just think of it from a business perspective, is it really just removes a whole lot of friction, a lot of the historical friction you'd have in business around cost of moving things, cost of logistics, cost of communication, all that, because that just goes closer to zero as things become more and more digitized. When you decontextualize the business capabilities, then you've got this ability to assemble these complex networks of capabilities. And so, that's where the value network stuff came in, to look at, you know, when we think about business models, if you think about how companies come up with new business lines, new profit schemes, or even just formulate new companies from scratch, it comes down to the business model.

Digital business allows us to come up with more and more complex business models, and the way you do that is through these value exchanges, where it's not like the early 20th century, where Ford had a competitive advantage because they would just buy up their entire supply chain, end to end. Now you can break things down into much more granular capabilities, focus on the things you're good at, and then assemble a bunch of commoditized services from other companies. So, opportunism through value dynamics is really about the property of these digital business capabilities being decontextualized. So, that's like, okay, now we have a way of looking at the landscape of opportunities and thinking about how we can exercise the options that we have. And then, the optimization through the feedback loops piece is, again, digital business gives us the ability to instrument things very cheaply and widely, so now we can get much more current feedback on how things are performing. We can adjust the course as quickly as possible.

One of the other analogies, we were really, we were consciously trying to put in memorable analogies and things, and terms. This is probably obvious now, but we used this pirate analogy throughout, right? Where we talk about, instead of thinking about business as if you got a treasure map, and you have one place where you can dig for treasure, and you've gotta have an expensive crew and all this. It's more like optionality, it means that there's probably treasure all over the place. The opportunism and value dynamics mean you're, you might not know where X is on the map, but you wanna find the right island or set of islands to go to. And then the feedback loop is kind of these thousands of robotic pirates digging all at once. So, and getting feedback in real time. I think that the OOOps methodology is a theory around being intentional about finding happy accidents, but it's all based on those experiences that we heard from the people that we interviewed and the research that we did.

Recommended talk: One Rule to Rule Them All • Pragmatic Dave Thomas • GOTO 2023

Applying the OOOps Methodology Beyond Digital Business

Erik Wilde: One of the things I found fascinating was that, as you said, of course, in the digital space, a lot of the value equations just look very different, things scale differently, and so forth. So this kind of skews things in a certain direction. But on the other hand, and I don't know whether it's in the book or it was some talk that I watched you doing somewhere. I do remember the 3D-printed pirates. That's hard to do, right? What I'm wondering is, now, if you are not specifically in the digital place, I mean, you also have some interesting case studies where it still makes sense. I mean, you have to be a little bit more, I would probably say be careful about the cost structure of the options, right, and what it takes. But it's not just a digital thing. I mean, it's a general kind of business strategy, that I guess, depending on the market you're in, might even make sense if you take digital out of the picture. Is there something that you would like to share with, in terms of how this might apply to even not entirely digital scenarios, Stephen?

Stephen Fishman: Sure. Well, one thing you'll notice like the first half of the book is very dedicated to unpacking what this science is. How does math work? How does economics work? How do the three different parts of the OOOps methodology interact with each other to yield this thing? The second half of the book is all about the case studies. And in the case studies, you'll notice that more than 50%, it's more like 80%, are not digital giants or digital companies to begin with, whether it was like the ones we previously had talked about, like Coca-Cola, Lowe's, Best Buy, Cox Automotive, which is a weird hybrid of both digital and physical. The examples there are so interesting, in terms of how they arrive at this place. And while I 100% agree with you that instrumenting feedback loops in a non-digital world is harder than in a digital world, there's still, the Coca-Cola example from the Freestyle machines amazing. The Freestyle machines, where you can go and program your flavor, get your drink as you want it. They would send that information back to Coke, to find, "This flavor could sell if we package that flavor." It's just a great example of organizations can do pretty much anything if they're focused on it, and they have enough commitment in there, of, you know, who would have thought 10, 15, 20 years ago that you could create that sense and respond movement, with really rapid turnaround times, from your soda fountain? Or why would you want to do that? And now, it's the no-brainer, because you're looking at it in reverse, and seeing that they did it that way.

If you look at the studies, a lot of them focus on that idea, or not that the... You know, and this is part of, like, it comes back to something Matt McLarty was talking about a second ago, of how the methodologies work together, is that the APIs in and of themselves are necessary because it not only decontextualized and does all that other stuff, it pulls your ability to get the value out of that capability right up close to the surface. And because it is close to the surface and easy to combine, access, pand ull out as an isolated thing, because it is isolated by definition, because it is that way, the cost to experiment with it is, by definition, lower than if it were already inside the monolith, and you had to pull it out. Because it is by its nature to combine and recombine and do other things with it, that, by and of itself, without you having to do anything else, brings your cost to experiment down.

Then, if you do the four other things that the book lays out, which are ramps, statistical, statistical nuance inside your team, feature flags, and I'd have to pull the fourth out of the book, and having the right tools for that team, visualizations, if you have those four, you can not only bring the treasure closer up to the surface but create the conditions with your team and your tools to make it rapidly easy to find the winners. One of the points that's in the first half of the book, where it speaks about serial optionality, and convex tinkering, from Nassim Nicholas Taleb. He laid it out, and it's right. Because you could see from the case studies, each of, so many of those case studies were, they didn't hit a billion dollars just through one innovation. They found a winning option, and they doubled down, doubled down, doubled down. You know, AWS is amongst the best examples of that anywhere, and I think probably all your listeners probably know what that is. But remember, they didn't get to $100 billion in revenue in a day, or a year. They got there over 20 years, by building the first three, seeing that that was working, and then both, at the same time, adding new things, and keeping the cost to experiment low. And that uses all three things, all the three parts of the methodologies. Decomposition by default, that's the Bezos mandate. At the same time, it's making things both internally and externally available. They didn't have to make them externally available. It had to be possible. That kept the treasure close to the surface. They would always look at the map, and see what the opportunities are. And they had a relentless focus on keeping the cost to experiment low. Those three things in combination will run you up that convex option curve. You'll find these enormous wins.

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Overcoming Resistance to Optionality 

Erik Wilde: One of the things I keep seeing, and I find this fascinating as a recurring theme, is that I mean, I buy into everything that you're saying. I love the book. But then you also see quite several organizations, I would say, who are a little bit not quite as visionary, right, and may not see that as such an obvious thing to do, keep your options open, and so forth. And for them, sometimes, or, oftentimes, from what I can see, keeping this machinery up that allows you to exercise these options seems like an unnecessary cost, right? For them, it's like, oh, why do we have this stuff? It's not driving revenue right now, right? Would you have any kind of recommendation on how to change that mindset a little bit, or how to make it easier for organizations to embrace this, kind of, as it's an investment into the future, right? But the question then is, well, are you, you know, how much do you wanna invest, and then how much money do you have, right? So, I think that's the really interesting part there. I'm just wondering if there is anything you can share in terms of this trend. Sometimes to focus too much on cost, and not enough on opportunity that I'm kind of buying with that cost.

Matt McLarty: We've seen, we probably lived through many examples of this. I think a lot of times, it's pressure from finance or whatever, or perceived pressure from project managers. If you break it down into where the decisions get made, and where the options get snuffed out, right, a lot of times, it's in the name of finance. If we take the time to build it in a way that drives up optionality, we're spending too much money, and we need to get to this predictable outcome, right? The interesting thing, I mean, it depends on who you're talking to, but if you're talking to finance people, I think it's pretty interesting that this whole notion of optionality, and measuring options, option value, came out of the world of finance, right? So, Carliss Baldwin, who Stephen mentioned earlier, started her career focusing on economics and studying option value in financial markets and had the aha moment of saying where else could this option value be applied, and started to study the world of technology, and found this phenomenon in the technical world and software, that the ability to drive up option values is humongous in this space.

Make Option Value part of your Organizational Math

Matt McLarty: I would start by just discussing the notion of option value. On all the business cases that are being done out there. Is anybody measuring option value? Is anybody saying "Here's an estimate of the option value that we've got?" Because that is a very financial concept. It's like saying... I think that's where the analogies can help. Like, and using examples. Like, I remember, I worked at a bank for many years, and these are sort of pre-web APIs, but it was very much in the idea of building optional components in software. We had a huge project where they did a, they created an online account open process. This is going way back here, like, when online banking was a new thing. So, it was like, "Oh, well, we should allow customers to open accounts online, from the web. wouldn't that be awesome?" The bank hired a big third-party consultancy, they came in, and they built this big monolithic blob on the side, that did this online account open. The results were, like, "Hey, this is great. Now we want to use it to revamp our branch account open process." It was "Okay, let's start from scratch," because we couldn't harvest any of the software assets that were there.

I think every company is riddled with projects that were over time, over budget, and all that stuff. They end up with a monolithic result. There are probably a lot of ways you have to attack it. Introduces the concept of option value. Ask your financial people, "How are you measuring option value? Where is the option value in the business case?" Because this is one of those things... Erik, you probably remember when we were doing our sort of API 360 methodology, we were talking about APIs as much about what they enable as what they deliver, day one. That was sort of another way of describing optionality. So, putting it in financial terms, saying, "There is real option value. We have case studies that show it. How are you measuring option value?" could be a start. And I know, Stephen, the work that we did with Cox Automotive, talking about the new math, I think, is a good example there.

Erik Wilde: The Cox story is great, right? But they seem to be very strategic on that, right? For them, it was clear that they needed to invest. I like this idea with the optionality. I would keep that in mind, because it does always fascinate me a little bit that, at least in a lot of organizations, it seems that there's much less fear to just spend huge amounts of opportunity cost, right? Because of that, you can never really kind of put a number on that, right? It's like, probably we didn't make all the money we could, but who knows what we could have made, right? And then there's this huge focus on cost, because that you can count very easily. And I think that's kind of an imbalance. So, having something like the option value actually, that would be a cool thing to just throw into the mix, I think, because it seems to me that a lot of companies might not have that in their math, right? That's something that maybe is something they could use.

Decompose by Default (but think about the cost)

Stephen Fishman: One nuance I think I'd like to add here is that Matt and I, we cover this every time, in so many different conversations. The book doesn't say build APIs and decompose everything everywhere. It doesn't say that. It says decompose by default. And what that means is to shift the default in the funding conversation from, "You have to prove the value of that decontextualized approach..." Versus instead of that, "You have to prove the value of not doing it that way." Because, by definition, you're killing the option value by not doing it. And we're not even talking about how you have to build all these capabilities. It's because these are processes and things that people are going to be building anyway. And if they are building them, it's one extra step. And once you get decent at it, and your teams know how to do it, there is no additional marginal cost. Marginal costs will go down over time. The finance argument is the right argument. And if you unpack it, to what is the marginal difference in this particular case, what is the option value that you're killing or not, the default conversation needs to be one of they need to prove that, hey, that this shortcut will be beneficial for us. That's the opposite of optional by default, which is a shortcut by default. And that's the thing that ends up in the big balloon payments of tech debt, that so many organizations are struggling with right now. Optionality is the opposing force to technical debt. And we can show it, and it's real.

Erik Wilde: I like that phrase you just used, Stephen. It's like, "You're killing option value." I think that's a phrase that I will start using. I like that. That's great. But, let's dig a little deeper because I'm really curious about what you think about that.

Identifying and Creating Valuable APIs for Business Option Value

Erik Wilde: One of the things that you're saying is that APIs are kind of the enabling thing for optionality, at a technical level, let's say, because they are these, what did you say, decontextualized business capabilities, right? That's what you said? Yeah. Very nice. I love that. But, now, how do you create the good ones? Right? That's also a conversation I think that all of us have had very often, right? What's a good API, and not on the technical level, right? But what are the useful APIs that would drive this kind of option value? How do we find those? Because clearly, some probably are not as good as others, I would say. And then, what would be kind of the process to end up with those that are the big drivers of that option value?

Matt McLarty: This is a great question, which I'll share a brief answer, then I'll get. I'd like to hear Stephen Fishman's take on this as well. But in the context of the book, I would say, we've said for a long time, right, APIs should be products. APIs should be business-aligned. I think to put it more practically, this is where I think the value dynamics approach of mapping out value exchange helps. Because we don't have the visual aids here, value dynamics is really about creating these visual maps of value networks, which show how you deliver value from your organization out to your customers, ultimately, and that can be through indirect means, and you might have services from suppliers and partners and so on. So, you end up with this map of all these either capabilities inside your organization, or services outside. And then it becomes a matter of, like, the sort of nodes and edges in a graph, of saying, any place where value is exchanged is a good opportunity for a great business. Oh, there we go. There's the visual. A business API is the point of exchange there. We offer a visual way of sort of seeing, surfacing, where some good APIs might be.

Erik Wilde: I would like to hear more from you also, but, so you would drive it from kind of that visual representation of how value is getting moved around, and then basically see, do I have APIs serving all these functions, or is there something in there where I basically can't really explain how that happens in the current environment that I have?

Stephen Fishman: One of the best examples of how the value, like, the value mapping really plays out, the Cox example is great. Because it's not just whether I have APIs or not. It's closer to how are we exchanging value today, in either physical or digital realms, and how might we add additional value that we're not considering today, whether it's through adding a data feed API for informatics, for thing X or thing Y, that your organization is trying to do? I do a lot of consulting and engagement with a lot of organizations on digital products, and how to create new lines of revenue. And a lot of times, they talk about cannibalization. If I offer X here, will I kill Y revenue there, and, through cannibalized revenue? But accretive revenue is just as plausible, and that's in your control, that a lot of value dynamics stuff leads to a packaging question, of how do I wanna package value, and what's inside that package? And that can include all the physical forms of value delivered today, all the digital forms of value delivered today. And then, additionally, more decontextualized data, and other tools that people can use on the outside of the value consumer, to find other ways to achieve value and higher levels of performance for the things that they're trying to do with your capabilities and data. The mapping gives that very visual way, to point between two constituents or three constituents inside of a value network, and say, hey, wouldn't this party benefit by having this one more or two more pieces of digital information? Could we be the right provider of that benefit? What would it take to make them pay for it?

Erik Wilde: I would assume that still is a little bit of identifying opportunities, and maybe acting on it. 

Recommended talk: Insights on How Team Topologies Drive Organizational Success • Manuel Pais • GOTO 2024

Optimizing Option Value: From Experimentation to Business Strategy

Erik Wilde: One thing I would also like to talk a little bit about before we have to wrap it up at some point, I'm afraid, but one thing I also would like to talk about a little bit is the optimization phase, right? One of the things is this idea of optionality, creating all these options, and then identifying opportunities in that set of options that you have created. And then you also have this thing where you say, and now you need to be good at optimizing things. How does that look in practice? Like, how have you seen this optimization being also, one, I would say, necessary ingredient if you want to make this whole model succeed?

Stephen Fishman: So, I'm looking up, there's the picture that's inside the book, that talks about the four methods, and these are not ones that we invented. These are ones that came both out of the interviews and out of the research, and just keeping up with things, from having to do our jobs. And Etsy did a great, amazing job at being able to show people how to do this type of stuff, with ramps, feature flags, visualization tools, and statistically literate teams, that by having those four things, like we were talking about a minute ago, APIs bring value closer to the surface, easier to experiment with. But if you don't have your ability to do A/B, in wide ranges of multi-variant testing, you're not gonna be able to keep your, to get the velocity of the number of experiments to make the whole thing work. The phrase is, "small bets placed wide." To support a thousand bets, like, at one point in time, you're going to have to have those opportunities close to the surface. Individual experiments are cheap.

You're also gonna have to have the ability to read the results from them in comparison to other options, such that you can find the one that has the highest margin of value for you, which not only means that combination, but also the rapid ability to see that in a visual form, with the statistical tooling to help you understand what it means and what it doesn't, and then the smart people, who can internalize what the metrics are saying so that you can define what the right course is. Because statistics are nasty and dirty, in that they can prove almost anything you want them to prove. But you need not only the visual to be able to see it, and not have to do all the synthesis yourself, but you have to have the critical thinking skills and the statistical knowledge skills to know what they mean, know when things are reverting to mean, know when things are, you know, the sample size is too small, and know when things are hitting the right point that the, for statistical significance. That's a human job. At least it still is.

Matt McLarty: If I can just sort of segue from that into, I know we're gonna be closing soon. So, just to point, to kind of wrap all this together. We published the book on IT Revolution, which is, you know, Gene Kim's publishing house. And there are a lot of affinities. I'm just segueing because, Stephen, a lot of what he's describing are best-in-class DevOps practices. There we go. There are four. We have a real affinity with, very complimentary to DevOps practices that are out there, I think there's a big platform engineering movement that has spun up, which, you know, we've got really good examples and instruction on how to build high-performing technology organizations to deliver digital capabilities. I think what we're trying, the gap we're trying to fill is tying that back to the business strategy. Because you can build a high-performing technology organization, but it's gotta be building the right stuff. That doesn't mean just take orders from the business on what the corporate strategy is, and aim for that X marks the spot, right? This is really about how the technology organization blends with the business organization to say, "Look. These are, we're not just coming to this out of architectural purity, and saying, decompose things into microservices or APIs, whatever. There's actual economic theory behind this, and proof points with all these case studies, to say optionality matters, and here's an approach to take." So, I think all the lessons you may learn in "Team Topologies," around organizational structures, and "Accelerate," and DevOps handbook, all that is very complementary to what we're doing, but really kind of putting a little bit of business meat on the bone around, let's dig into the business strategy, and show some techniques that add value there.

Stephen Fishman: Erik e, if I have 30 more seconds here, we picked up a nice nugget from another IT Rev book, "Project To Product," by Mik Kersten. And he said it so well. You know, transformation done for technology objectives is doomed to fail at the start. That grounding your transformation efforts in a business goal and a business outcome, that's the only way to be sustainably successful. That drove a lot of our thinking for how to put the financial grounding in, making sure we were talking in terms business teams could understand.  A big goal of ours was not to make this something that only tech nerds could read but to be making something that more business nerds could read, and get value out of.

Erik Wilde: Kind of a mix of both. But no, I think you hit that spot very well. 

Recommended talk: Effective Platform Engineering • Chankramath, Cheneweth, Oliver, Alvarez & Reisz • GOTO 2024

The Platform's Role in Supporting Business Strategy and Optionality

Erik Wilde: But I have one last question because you mentioned this one, which also is a great book. And here...and you also mentioned that term, right, platform engineering. So, platform engineering is dear to my heart. I think that's one of the things that is interesting, that has grown tremendously in the last two years. 

When I was reading your book, I was wondering, is that something that should also inform how we built the platform? Because what you said, Stephen, was also that you need, for example, these kinds of measurement things, right? You need to gather the data so that you can interpret that. So, that, I would say, should be something that everybody should be doing by default, because you need that information. And then, I think that idea of platform engineering would get pushed down into the platform. Is that something that you see a lot, or that you would recommend people do, you know too, when you think about what should my platform be, to also say your platform should support optionality? Or am I just taking things a little bit too far here?

Matt McLarty:  I've had a little bit of a discussion around the term "platform." You'll see parts of the book, I think, maybe in Chapter 1 even, where we're talking about the platform approach. It was interesting that several people we interviewed, in business terms, like, business as a platform is kind of how you can explain APIs to business people. But that's different than, I think, platform engineering as a movement, which I think has its own biases, to me, is very focused on empowering developers to build solutions, right? So, it's kind of like developer platform engineering. The short answer for me would be, I feel like we need to burst through that bubble a little bit around platform engineering as a movement and think about, look, all these API options you have are part of the platform. They may not be the things you're focusing on in platform engineering, but yes, you can have workbenches for developers to build code, and have reusable technical services, identity management, whatever it is, but you should be thinking about these business capabilities as part of the overall platform. And I think a lot of organizations aren't at that point yet. They're a little too focused on the bias around developers. I think that for organizations that are gonna scale to meet the demands of development in 2025, whatever that is gonna look like, you've gotta have that. We made it this far without mentioning AI, and I hate to say it, but as we go through this transformative period of AI being in the mix, even if you look at how AI agents are being built, or AI applications, right, they're being built with these tools that are effectively API-enabled options.

So, once again, the companies that have the optionality around their digital capabilities are gonna be able to take much more advantage of the whole AI space. So, again, I think it's gonna disrupt the whole platform engineering movement as much, but again, it becomes this big blended-together thing, and I think you should look at your overall IT estate, or digital estate, as this set of capabilities, and think about the whole thing as a platform, not just maybe what you're focusing on in your developer platform.

Erik Wilde: Thanks a lot for saying that. 

Stephen Fishman: Sorry, Erik. If I could add one last thing to that. What we saw, something I think you're hinting at, in the very last stages, we were like, "Uh-oh. What does this mean for team topologies? What does this mean for developer experience being the optimal thing to focus on?" And we went back in, we brought all these concerns back to David Rice, one of the main interview subjects, and he laid it out so clearly for us, in terms of...and Matt hinted at it a second ago, when he talked about business as a platform or platform as the business, in that, if you're trying to do these things well in advance of your business teams understanding what that is, and even seeing the platform as the business, you are by definition doing something unsustainable. You may get marginal wins right now, but because people are so itinerant in their jobs, and leadership changes happen, disruption happens, all these things happen, almost all of the advantage that you gain will be lost in, when the organization reconfigures itself, when the reaction to disruption starts to carve stuff out. Because it'll be seen, just like you said it. "Not revenue add, kill. Not revenue add, kill." And it will always... Like, and the people who are making those decisions, those are not, like, the detailed architects who know, and even if the architects are in the room, they're grounded in fit-for-purpose, and they see the cost center mindset in those decisions, and they will keep doing the same. Until the wider group of people see the platform as the business, or as the lever, it's going to be cut. And placing your bets, your teams and your capabilities closer to the point of revenue generation is the only way to insulate yourself from that universe, because efficiency is great, but it's not the end goal.

Erik Wilde: These are the perfect closing words. Efficiency is great, but it's not the end goal, because you can do very pointless things in a highly efficient way, which doesn't help much. Thanks so much for joining, Matt McLarty and Stephen Fishman. That was a great conversation, once again. Read this book. It's great. And it's also something that you can very nicely recommend to your business friends. It's not a tech book. It's really about embracing that style of thinking and that way of exploring the landscape that is out there, to find those hidden treasures. 

Stephen Fishman: Thank you, Erik.