Las Vegas 2023

Optionality & the Science of Happy Accidents

As a "sneak preview" of our upcoming IT Revolution book Unbundling the Enterprise - APIs, Optionality & the Science of Happy Accidents, this session will unpack and explain how optionality works and lay out the path for business teams, app-dev and operations can align to create the conditions for big value events (AKA "happy accidents") to occur in their organizations.


Matthew McLarty

Co-author, Unbundling the Enterprise


Stephen Fishman

Co-author, Unbundling the Enterprise





So, welcome everyone. Thank you so much for, for attending our talk. We're really excited to be at the, uh, DevOps Enterprise Summit in 2023. Uh, my name is Steven Fisherman. I'm the Global Practice Lead for MuleSoft's Success Architecture, which is part of Salesforce. That's an integration platform as a service. Uh, Matt and I have been working on a book for, for It Revolution, uh, for the last year. And this is the first time we're here to give a little bit of a sneak preview about our subject. Uh, the subtitle of our book is a subject to today's Talk, API's, optionality, and the Science of Happy Accidents.


Yeah. So, as Steven said, so my name is Matt McClarty. I'm the Chief Technology Officer for Boomi. Um, but Steve and I have been in the industry for quite a while, and in the industry over the years, through the many eras that we've lived through, we've been observing the patterns of success in the digital economy, right? And that could be patterns based on web pioneers, right up to established enterprises. And that's why working together, we found that it was, we felt it was pretty relevant to bring those findings in the form of a book to the public. And as Steven said, this is our first time on stage doing that. So we're not gonna have a chance to go into the depths of the book, right? We're not gonna be able to plumb all the depths of what we found. But we do want to share with you this, what we're calling this science of happy accidents.


Um, so let's set sail. Okay? I'm, I know we're in the middle of the desert, so you know, em, embrace this flowing water here. Like in the digital seas, there are opportunities everywhere. We have, you know, probably everyone, everyone has hyped on generative ai, right? Like, I think, I think everyone came to this conference, DevOps conference, and it was, there's been a lot of discussion around ai. There's all this excitement that's out there, but there's, there's all sorts of digital opportunities that are out there. Everyone's trying to figure out how can I capitalize on that opportunity? How can I find digital treasure with these new things? So there's buried treasure all over our digital island, but maybe the most valuable treasure of all is the treasure we don't even know about today, right? The stuff where, you know, it, it may not even exist today because it's going to be built on the innovations of the future, bringing these innovations together, right?


So how can we find all this treasure that's out there? Well, pirates know how to find treasure, right? Here's black beard, black beard's, maybe one of the most famous pirates of all. If you took the black beard approach to finding treasure, what would you need? What's the first thing you need? Anyone? A map, right? And pirate maps, you know, very well articulated, very specific, maybe cryptic instructions there. But of course, X marks the spot. You would know exactly where the treasure was that you're looking for. And so once you had that map, you know where the, uh, where the treasure's buried, you get your crew, you go to the island, and you start digging in that spot. Now, maybe this approach would find treasure, but maybe it wouldn't find the treasure even that you're looking for. You might be digging and it could be 10 feet away, and you wouldn't even realize it. But what we do know for sure is that you would not find the treasure that you're not looking for. You wouldn't be able to find the treasure that isn't anticipated, isn't part of your map, isn't part of your plans. So Blackbeard and his pirate crew would need to


Get used to disappointment. So all that time, they invest in hoping for the luck and providence of the map, and that maybe they'd come up empty handed, but maybe there's a different way, a different way to find treasure. So we think that there's a new brand of pirate out there who might say, you know, I'm not so sure I need a map. And they might go even a little bit further to say, I don't want a map




So you might think about that. That's not possible, but let's play it out for a second. So, if you have a mission to find some treasure, and you set sail to find to, to the seas to find an island, what if you had a big enough crew that you could actually dig in every spot on the island at once? Wouldn't that be interesting that you wouldn't have to worry about finding which place to dig? 'cause by definition, you're digging everywhere. So what if your pirate crew, you know, had, was instead of humans, it was a set of three D printed drones that you could print cheaply on demand. And the more pirates you had digging across the entire island, the more treasure you might find. It might not be the treasure you set out to find, but there's unexpected treasures, like the ones that Matt is, is talking about that you might not know, have known it's existed.


So clearly distributed like drones, like in the thousands, would find more treasure than the old-fashioned way of following the map. And it turns out, this is actually an app metaphor for how a lot of leading companies are thriving in the new digital economy. The companies that try to predict the future with the top down genius who's got this strategy and says, this is where everything, how everything is gonna work. Uh, the, the phrase is, that's like a highway without exits, because everybody's focused on the plan and you're digging in one spot. But nimble corporations who plan with, with the idea that, Hey, I'm not necessarily sure what I'm gonna find, but I'm gonna commit to a different approach to allowing opportunities and treasure to find me. That's the ones who are, who are, who are, uh, succeeding in the new economy. Where the treasure is, is in a place where nothing marks the spot. But this begs the question, what about those robots and shovels? Not everybody's got a three D printed army <laugh> of robot drones. So let's go one step further.


Yeah. So in 2011, I don't know if anyone remembers this happening, there was was a Google engineer named Steve Yagi. I wonder if he's here. I think he's, anyway, um, he remember Google plus everyone, the social network that was around for a very short period of time, right? He was posting to Google Plus thinking he was posting internally to Google Plus to say, you know, go on this big rant about how, you know, Google needed to learn from Amazon and how to build platforms. Well, it went public and it went viral. And in that rant, he, he talked about what was now known as the famous Jeff Bezos mandate, or the API mandate. Anyone familiar with the API mandate? Yeah. Okay. Few people, right? So that's where it came from actually. It's not like somebody had the memo and published it, it was in the Yagi rent, and it was, it, it listed like five.


He listed five, uh, or so principles. I think the sixth one was a bit of a joke, but, uh, it was saying like, everything must be built behind a serve, uh, a an interface, a service interface. You know, it has to be built to be internalizable. That was an important point. Like we have to assume that people are gonna use it from outside Amazon. Um, teams were gonna communicate through the APIs that they had there, these service interfaces, not just machines. So it was this very explicit set of instructions that was sent out to the company, and by all accounts was absorbed and taken forward. And so you ended up with, uh, this whole new approach to, to building systems very modularized, very, uh, constrained, which might sound like it would weigh down on innovation and creativity. But if you look at the results since then, Amazon, you can look at this whole, you know, for that point of, around 2002 was when the mandate went out from that point forward, all these different dimensions of expansion from going into universal retail, personalization, payments, logistics, you know, reinventing what, what a book is getting into all these different areas.


And Amazon was able to quickly go into those spaces because they compartmentalize and built these, uh, API based services right now, those ones that I list there, you could say somebody in a, in a boardroom might have said, yes, this is the plan. We're gonna do personalization and payments and all that. So maybe they could have done that with a map. But the thing that they never would've found with a map or even written a map for, was AWS What happened with AWS was around that same time, Bezos had the mandate, he had, uh, uh, Tim O'Reilly was in his ear talking about you. This, this is where the API idea came from. Like, this is the future. You're gonna have Web 2.0, you're gonna have all these APIs connecting things, so when you build stuff, you should be ready to put it to the outside world. And Amazon had been dabbling with external APIs around product catalogs and other things. At the same time, they're building all the services down to the guts of the infrastructure using APIs. And so combining that work that was happening to externalize some APIs with these services that had built a provision infrastructure in a very rapid way, was the happy accident that led to AWS forming.


So if we're going a little bit further with the Amazon example here, they were able to find treasure in, in many places, thanks to their many robot pirates. Those robots that we're talking about, those are options in the form of digital business capabilities, software functionality and data all packaged in a, in a, in a standardized interface that anyone can mix, remix, and compose at will. And you could think of these APIs for capabilities as the shovels. 'cause they, the, it is only through API enablement. Could those capabilities be easily combined, mixed in remix and externalized to the outside world with a very low cost of coordination. That's when new business value and new business models emerge. So Amazon is not the only one who's been the successful with this approach. Not the only API right out there. So Best Buy, how did they survive? How did they thrive when every other retail organization was, was suffering in the wake of Amazon, whether it, whether it's, um, best Buy or Coca-Cola or Cox Automotive or Capital One. Were gonna get into all these examples a little bit later. They all focused on this idea of how to actually build composable infrastructures in the same way that we're, we're virtualizing and not having to care about the infrastructure. We're hoping that there's another way of being able to, to allow that sort of, uh, recomposition that will at the application layer, even if they weren't doing it consciously. It led to a bunch of happy accidents.


Yes. So happy accidents. We have to kind of accept, if we accept that the most valuable treasure that's out there is the treasure that we don't even know about or that isn't, doesn't exist yet, because it has to be invented, right? How do you aim for that? How do you build a strategy around that? Well, this is the focus of our book on muddling the enterprise that will be coming out later next year. Quick promo <laugh>. But what you need is, oops. So our science of happy accidents breaks down into these three, what we're calling, oops, number one, create optionality. You're probably hearing a lot about optionality. We'll go into details on that and how APIs relate to optionality. Number two is within this context, within this context of going after the stuff you, you don't know about yet, how do you identify the opportunities? And then number three, when you have the opportunities and when you've been able to, uh, you know, understand the landscape of opportunities, it's to optimize value. Those are the three. Oops. Now let's go into more detail.


So the first, oops, optionality, optionality may be easier to understand outside of the technical arena. Like as you approach your own lives, do you guys try to commit and, uh, to the first option that's available to you? Or do you wait and wait until the, the, the scene plays out and find and allow that that concept that gene calls ification allow more information to happen? Slow down your reaction time. Like as you approach your own life. If you're seeking a new job, or you're, you're looking for a, a, a date online, or you're helping your kids through the application process, do you commit early or do you tr create the options and then commit late? That's what happens when you slow down in the context of an API is, you're not planning and locking yourself in to a singular context of use. You're leaving yourself open for all the ways that, that people might, might actually compo consume it.


The, the, one of the greatest examples in the space is Google Maps. Google Maps was originally conceived not as an API, but instead as just a web app that would, uh, support their advertising business. But lo and behold, the happy accident happened. Google actually never even decided to charge for it. It was only as a response to what customers asked for the developers who were coming and actually pulling the, the maps API by themselves. They went to Google and said, we need to pay for this. We need to give you to please take our money because we want to build a business model on top of this to go search for our own treasure. So the idea that one of the ideas that we're, that we're gonna explain in detail in the book is the idea of choosing for a decomposed architecture of discreet capabilities is not specifically a technical choice.


It's actually a financial one where you can give yourself the option to consume this, that capability in a near infinite number of contexts. So to follow, in the spirit of DevOps, you know, when, when we talk about, uh, you know, unicorns and, and, and, uh, digi and, uh, heritage companies, that, that we're gonna mix a bunch of them. We're not just talking about the digital natives like Amazon and Google. We've got tons of examples from outside that universe, whether it's Cox Automotive, Cox Automotive, you may not be familiar with. That's Autotrader Kelley Blue Book, about 50 other brands and, and a, a fairly large amount of revenue. They've enabled cross-brand consumption of, of everything through having these decomposed capabilities. So if you were a car dealer and you went to a, to an automotive auction at Manheim, that's one of the world's largest automotive auctions, uh, set up in multiple locations around the country and internationally, that before the gavel even bangs on your, on your purchase of the particular used car that's in the line.


And before the car leaves the lane, you could already buy revenue generating services from across all 50 of those brands, whether it's transporting the car to your dealership or not even going to the dealership, because you can even start to sell the car, including all the imagery and all the description and all the other stuff about that car just through the click of a button on an app that is all API powered. So, uh, capital One, who is an, a frequent, uh, presenter here at, at, at, at does, they have long been committed to leveraging technology as a value driver rather than a cost saver. Um, this commitment to packaging business capabilities with APIs first emerge in 2016 with Cap One's Dev Exchange Cap one beat the EU by four years, but before any regulatory thing needed to be happening, CAP one actually made data transportability through the dev exchange to allow other people to build on the CAP one platform. And they even taken the next step, which is taking these capabilities inside that were once conceived as cost centers and actually rolling them out as SaaS opportunities, and they spun out to a full on SaaS company.


Thank you, Steven. I, I, I think that the optionality idea is definitely out there and we definitely, you know, probably people are familiar with the power of, of optionality in lots of different contexts. But I think to put it into, into business context, you know, one of the parts of the book for sure, we can't get into the depths of this, it's an area we call value dynamics. And value dynamics is about showing where these options and APIs fit in a business value context. So this is something if you wanna drive value in your organization, you want to be as close to the, uh, close to the value exchanges in your business model, the business model of your organization. And business models like everything else are fractal. You can kind of go down, down, but at the top level, value dynamics gives you a way of visually depicting business models.


So this is, this is actually like Alex Osterwalder is the creator of the, uh, business model canvas, and he defines a business model as the way an organization creates, captures and delivers value. So what this value dynamics does, and it's heavily influenced by, uh, two Dutch gentlemen, uh, Roel, Viga and Yap Gordine, who actually have, have a book coming out exclusively on this sort of value exchange mapping. But what this does is allows you to break down visually how business models work in very clean terms. And you can see the, uh, or maybe you can't read, but there, we essentially, there are the constituents in a value network, which can be depicted by objects, arrows showing where the value is flowing from deliver delivery to capture, and then what we're calling value currencies. And this is fundamental because, you know, you might think, obviously value is money, value is products and services, but also you've got, um, intangible types of value like reach, providing access to an audience or time savings is value, right?


Risk reduction is value. And of course, in a digital economy, data is extremely important as a, as a form of value. So just to show how this works with a couple of examples, because this is how you take all those, your landscape of options and capabilities and start to put them into a framework of where you can actually have a business model or augment your existing business model. So we, we, we mentioned a couple of examples off the top. Um, Coca-Cola actually has, you know, we, we have a, we had a great interview with, uh, our former CIO asat <inaudible>, where he went into depths about all the innovation that they were able to introduce by having this approach that was API heavy. But one particular example you might not realize is, is, uh, you know, those freestyle machines where you can select new flavors and create crazy undrinkable flavors of, of <laugh>, of Coke products.


That's all API powered, right? And so, in a sense, you could look at that, you might think about that and say, okay, well we have a new way of getting soda into these cups for our cons consumers, which would be at just a typical, okay, Coke provides the beverages to the retailers who, and here's the units that you use to dispense the sodas the way you go. It's just another product for money exchange. I guess an add-on to that, and you can see depicted here, is that there's this new service on top of that, which is beverage customization, right? That's a new value add on the top. But even that doesn't tell the whole story because through that whole framework, what Koch was able to do was create new points of data exchange. So they were able to collect data back from the machines, which would help tune the op and optimize the operations of the machines themselves.


But also in order to provide that value added service to consumers to say, Hey, customize your own beverages. They, they had like Bluetooth technology or have Bluetooth technology to help use a mobile app where you select the flavors. Well, now, once you've got the mobile app, now you've created the direct connect between the consumers back to Koch as the, uh, as the product company, which opens up a whole new channel for delivering more value around loyalty programs and so on. And it's a very simple diagram when you draw it out this way though, you can start to ideate very quickly on where new opportunities are to, uh, add more value to existing channels where you might want to, where you might be missing channels and want to add channels of value, and where you can even shut down channels that are, where the, where it's an imbalanced value exchange.


And so on another example here with Best Buy, um, they had a program when the mobile boom exploded, where, you know, they were already doing a lot of work. So they were doing the optionality work. They were, they created a common platform to have to API enable all these different services. But through that, and through the thinking, they were able to say their Geek Squad, uh, service, which is, you know, it was, it was massive business around electronic device repair was always in need of new inventory. At the same time, the retail outlets were wanting to sell all these new mobile phones. And of course, consumers were just dying to get their hands on mobile phones. So they set up a program which kind of connected all these value streams together where you could go into the store. When you buy a new phone, they would promise you a buyback price to say, Hey, we'll give you money back when you're out of your term so you can come in and get a new phone, right?


That's a win for the consumer. 'cause they're gonna gonna get some money back for their phone. It's a win for Best Buy because they're going to get a recurring revenue stream or a pretty reliable one. But the magic and all that was the, the devices that were bought back were fed back into the, uh, geek Squad business, which was able to then turn that into, you know, augmenting their parts inventory. So when, I mean, were, were these companies using exactly this approach when they were coming up with these innovative ideas? Probably not. But when you have these options and when you're able to, you know, almost create a game board for, for strategy around delivering value, it's amazing how creative you can be with this and come up with more and more ideas to either just do some tweaking or come up with whole new business models.


So just to, to follow on to something Matt said there, like, if anybody watched, uh, John Willis' talk of a couple days ago when, when he talked about serendipity as, as a, as a fundamental thing inside the, the, the process in Japan, that's what we're talking about, is being able to actually create an ecosystem that mass produces these serendipitous accidents that lead to, to large scale opportunities. The first, uh, uh, the third oops is optimization. So if you're a fan of Gene and, and, and, and the third wave of DevOps, you know, you're probably familiar with the OODA loop that's, that's up there. Another, um, golden treasure that came outta the military. Um, you're likely to be present to the path, to the value paving, the path to, uh, ever, ever accelerating insight that you can institutionalize for your own market advantage. Each of the three different oops tactics works together to lower the cost of running trials and experiments.


Now, we saw, we talked earlier about like that top-down idea that everybody's digging in one place, in that the only way to be able to dig in every place at once is to lower the cost of what it takes to dig a hole lower. That the, the lower coordination cost of APIs is one part. Being able to, to at least do some targeting towards people where you're likely to be able to find value is the other part. But the third key part in order to really lower that cost of experimentation is paving the feedback loops. It's not just enough to go and ask people things and get feedback in and then have meetings and figure out that stuff. But it's also important to have four key things. And if you're, if you were a, a, a watcher of Etsy over the last bunch of years, there's been, they've been masters at multivariate testing through feature flags.


Ramps be so be able to, to channel audiences in low risk environments with small percentages of, of, of audience being able to visualize the results of tests real time ev within every second. And, and at the same point, it's not just having all those tools. You need a staff that is capable of actually reading statistics and be, and having statistical literacy. 'cause if you can't actually, you know, discern what the the stats mean and what they don't, you're not gonna be able to, to do the things that you need to, like doubling down or knowing when to fold.


So when all three of the oops techniques are used in harmony, you set up this institutionalized way to get that accelerating path, the beneficial insight, knowing when to double down, knowing when to fold, and you accelerate the harvesting of these uncapped gains that come from systematizing innovation. Those are the happy accidents. Digital pioneers like Amazon and Google have, have a head start here and it's easy to see the path in retrospect. Um, so Amazon, which now earns some more like, uh, close to a hundred billion in annualized revenue from AWS, which they never started out as an intent that emerged from a system of experiments that utilized each of these three oops techniques, creating optionality via an explicit API strategy, understanding how their internal capabilities could be leveraged by a worldwide audience and capped off by being ruthless and automating the process of making the end-to-end process of experiments cheap.


It's an economic truism that when you lower the cost of running experiments, more experiments will be run. So that's how Amazon lived. That their day one philosophy where they catalog negative results by running lots of experiments in the hopes of finding the winner and ferreting out that winning option that allows them to double down, double down, double down via serial optionality. For those who remember back in 2004 when Amazon launched AWS, it only had three products, S three s, QSEC two, and it is only over the last 20 years of consistently doubling down on the winning option that they created this thing that we now see as like the, the, the backbone of all these application development opportunities out for the world. So Google, like we talked about earlier, they built the web app and it just ended up that people found it and used it to build other things.


So two things before we leave here. One, the three tactics, this is not specific to the digital landscape at all. The world is so, is full of all these accidents in digital land and in other lands as well, that whether it's, uh, Coca-Cola, the actual pro drink product, silly putty, microwave ovens, penicillin, ozempic, dynamite, all these things were discovered by accident. And then only in hindsight did they actually figure that out. The one counter example, I know some of the people from LaunchDarkly are here, here at, at the, uh, at at does, remember Etsy provided all that basic functionality. 10 years, 10 years before LaunchDarkly, Optimizely, ExactTarget came out with that capability that now are accruing millions if not hundreds of millions of dollars. That, and Etsy gave it away to the community, which is good thing, but did they pass up of an opportunity to actually strike gold with that unexpected treasure?


Very quickly on this, we're not up here saying, just go copy Amazon, right? Like, we're, that's why we deliberately went under the covers and distilled down the patterns that can be applied in any company's context. So that's gonna be the thrust of the book. This isn't just a case of, you know, go and copy the ceremony and the the surface value. We're going deep.


So you might be wondering what we're doing at a DevOps conference talking with this business strategy if talk. So let's consider these pirates again, there's a real alignment with another popular DevOps metaphor, which is the pets to cattle conversation in the same way that pets to cattle abstracted infrastructure and allowed for a new layer of agility in a new value to come out of, of internal capabilities and infrastructure. There's an even bigger treasure out there that, of being able to abstract and compose at the business logic layer of applications that, so we've seen this mindset, you know, take off in the DevOps community and we're hoping that we can help the help enterprises around the world see that there's that same level of value, but at a different exponential rate with the shift to APIs and optionality. There are cost and efficiency gains, but we act there, there's so much history out there of the gains actually being, uh, convertible in the top line.


So we've gone over at a surface level what the constitutes about a little bit around half of the book. The, uh, most of the book will take the science of happy accents as we've discussed here, and show how it can be applied in patterns of innovation for, for, for companies. We've listed the four areas that, uh, of our book here. Um, and what we're hoping is that people around the community can actually look at these things, whether it's exchange optimization, distributed innovation, or capitalization on in internal capabilities and aggregating value through different value networks and fi and, and look at the examples that are in their hindsight and bring them to us. So we'd love to, to to talk with you if you've seen any of these patterns in the wild.


Yeah, and to be fair, we'll we will, we will find digital ways of sharing those patterns 'cause we didn't get to even cover that part, which is the, the main thrust of the book. Uh, after we get through, you know, explaining happy accent. So big thanks. Remember you're, oops. Uh, as we leave today, this is the science of happy accidents. This is what we've seen empirically through examples we've shown and many more examples of organizations we've talked to, experiences that we've had personally in working with companies, right? Make sure you're driving optionality, ex exposing business capabilities in a modular way through APIs. Make sure that, you know, come up with this new way of looking at the opportunities created by those options. And then continuously optimizing the value exchanges through your automated feedback loops.


So take away one thing. Remember lots of small cheap betts Yes. Casinos, don't gamble casinos work the math. Yeah, that's what we're talking about. Thank you so


Much for your time. So thank your time. Thank you so much. Keep your eyes out for unbundling the enterprise, which will be coming out next year. We'll be sharing more information with more, more about what we talk today online and look forward to seeing the event and online. Thank


You. Thank you everyone.