Matthew McLarty

My name is Matt McLarty. I'm the CTO of Boomi. Stephen Fishman is here. He is a field CTO for Boomi.

The presentation is not about Boomi, but Boomi, we're sponsoring the event. So if you want to learn more about how we help with AI orchestration, automation, integration, we have booth number 104 in the expo hall, and we're going to be giving a demo tomorrow at around lunchtime.

But this is not a talk about Boomi. This is actually not a talk about AI, at least explicitly, so hope that's okay. We've had a few of those. They were great. I would say this is kind of foundational to AI, but this is really a talk about our new book.

Like Steve, I think we have some technical problems. We don't have access to notes, so we're going to have to wing it.

Stephen Fishman

It's all good. I'm good with that.

All right. We're really excited to be here. As Matt said, we're here to talk about our book, Unbundling the Enterprise: APIs, Optionality, and the Science of Happy Accidents. We're really excited to be with you today, and we'd love to get feedback. We're doing a signing later. We'd love people to hear what they think.

Matthew McLarty

Awesome.

How many people were at the event last year when it was the last DevOps Enterprise Summit? Even if you were there, just by virtue of the size of the theater we were in, I'm not sure how many people would have seen our talk. We did one for the EMEA event, so we're kind of blending it.

We've been working on this book for a while. It's actually very harmonious with what Gregor was just talking about around platform strategy. We're not going to be maybe using the term “platform” as much, but a lot of what he was talking about, especially around options, you're going to hear a lot about optionality in here, really is the essence of what we're doing in the book.

But we're going to take a little bit of a different tack here to begin with. So we want you to imagine, we don't have any seagull sound effects or anything, but imagine that we're sailing on the oceans out there.

I think that, and maybe this is a bit apropos with where we are on the AI front, where it's all experimentation and excitement, but maybe we're not there on the business value front yet. At the end of the day, when we're working on our stuff, we should be thinking about business value out there. Treasure. There's a lot of treasure out there that we're going after, right?

There's new innovations that are happening. We've got generative AI, obviously, as the big headline. But in every industry, there's all sorts of new digital opportunities that are out there. I think a lot of companies are just figuring out, how do we exploit these opportunities? How do we digitally transform? How do we come up with a plan that's going to get us to being a digitally native enterprise?

But I think what a lot of people miss when it comes to this crazy hyper-change environment that we're in, in the technology industry, is that a lot of times the most valuable treasure you're going to find is the treasure you have no idea what it is today.

When you heard Gregor talking, if you were here for Gregor's talk, not everyone was, but it was really good. He's talking about how you build platforms in order for people to surprise you. Well, this really goes for our industry. A lot of times the biggest treasure you get are the surprise things that come out, even today.

We're so excited about all these generative AI developments that are happening, but the reality is we don't know everything they're going to enable. Even the stuff that's bending our minds today, five years from now, we may look back and say, “Wasn't that cute, right? That was so old-fashioned, that GenAI stuff that came in.”

So we have to understand that when you're looking for treasure, the most valuable treasure you may find out there is not the treasure you even know about today.

But how do you find that kind of treasure? Well, pirates know how to find treasure, right? Pirates are good at this stuff. We've all grown up with stories. So imagine Blackbeard. This is an artist interpretation of Blackbeard, one of the most famous pirates of all time.

How would Blackbeard go about finding treasure? Well, it would start with a map, right? A very detailed, well-articulated map that would say, “Here's the island and these many paces.” And of course, X marks the spot where you're going to find the treasure that you're looking for.

And in order to find that treasure, in order to go on that quest, you probably spend a couple years recruiting a crew of highly specialized pirates who are going to have their jobs. You need a cook. You need somebody to sail the ship. You need somebody who's good at digging. And they would go through this whole process and have the treasure map and do the digging, and then hopefully find treasure.

You can imagine that you might get that treasure map, but if your measurements were just slightly off, if it was 12 paces instead of 10, you could be digging and find nothing. So if you're a pirate taking that approach, you have to get used to disappointment.

What if there's another way? How do you find treasure without a map? How do you know, if you go to the island, how do you even know what treasure's there? You could go with the treasure map. You might even find the treasure you're looking for, and you might find your 10,000 pieces of eight, or whatever currency you're working with. But there could be treasure chests all over that island. You don't know.

So what if there's a different approach? What if there is a way to actually search for treasure without a map? Inconceivable, you might say.

But what if you had, instead of your highly specialized, grumpy crew of pirates who might mutiny on you halfway through the adventure, what if you had some cheap drones that you could quickly build that would do the digging for you, that you could replicate these things, cover the island, and dig up every spot and find every potential treasure that's on that island? A much more effective way of finding treasure when you don't have a map.

So how have people done this? Well, we have a pirate here that we can study.

When we were doing the book, we really started with this philosophy of saying, okay, rather than go in with a fully formed hypothesis, Steven and I have been working in the industry for a while, working with companies that have been either digitally native companies, big tech companies like Amazon who are on the forefront of technological innovation. We call those the digital pirates.

But we also wanted to look at other companies who were, we'll call them the digital settlers, companies that had been in their industries for a while and were looking to become more digitally native.

But we started with these big tech companies. What is it that made them so successful in this highly dynamic industry? We started with Amazon because there was a great insight into the sort of DNA of Amazon's strategy, platform strategy, that mistakenly was published to the world in 2011: Steve Yegge's platform rant.

He's here, I think, in the room. You might have even used the term “Dread Pirate Bezos,” if I'm not mistaken. So it's so awesome that you're here in the room.

In there, you talked about what the difference was between the way platforms were being built at Amazon versus where you were at Google there. A lot of it came back to this idea of taking the capabilities that were available, putting them behind an API, very much like what Gregor's talk was just about, around finding the abstractions.

And the mandate, as published in the rant, didn't explicitly say APIs, but it was like network-based interface, multilanguage support, designed for developers to use. Essentially, it's become known as the Jeff Bezos platform or API mandate, which said, if you're at Amazon, you're going to build everything behind an API, and if you don't do this, you'll be fired. Have a nice day. That was kind of the short form of it.

We can see, and that took hold in Amazon. I think Bezos had some of the top executives enforcing this idea that teams are going to build things behind APIs. Teams are going to communicate via APIs to get maximum decoupling, to really drive more independence and autonomy for teams to go and build functions and build on top of things. That was the way to scale functionality out.

We do go into a lot of detail in this in the book, referencing back some of the literature that's out there. But you can kind of see how this paid off for Amazon. If you were to draw, maybe there could have been a map, a treasure map, that Bezos designed before he started the company. If you read, I think, Brad Stone's book, The Everything Store, it talks about how Bezos's original vision for Amazon was to be this everything store, to just dominate retail, start small in books, and expand from there.

And there's a path there that you can see, getting beyond books into universal retail, driving more personalization, reviews, ratings, payments, logistics, all that stuff. But the thing that was a surprise, the thing that nobody anticipated, was AWS. That really grew out of this whole API-fication of Amazon, right? The fact that you could say, “Hey, you know what? We're building all this infrastructure. We put these core capabilities behind APIs. What if we turn that into a business model? What if we turn that into a big business?”

So great, templated story. If we dig into that a little bit, you can kind of see essentially what Amazon did. The patterns that we're seeing out there are companies are taking their digitally packaged business capabilities, these core competencies that are software-delivered, and putting them behind APIs. You can kind of think of it as the robot pirate is the capability where they've got the API shovel.

Amazon isn't the only example of that. We won't have time to go into these stories in detail, but we surveyed the Google Maps story, which is a great one about how Maps became such a core, again, surprising business model opportunity for Google.

Best Buy, and their transition from being paper flyers in the mail, big-box stores, to being a powerful online retailer and really finding the blend between online and bricks and mortar.

Coca-Cola, the story about how they've used digital technologies and APIs to really inject innovation with new technologies and even come up with their own new business models.

Capital One as a banking platform, bank-as-a-platform kind of model.

And Cox Automotive, which we talk about that story a lot, and I think we have some people from Cox Automotive here. Great story about taking a number of different lines of business and combining them into a real digital business engine in the automotive industry.

When we look through all of these examples, we kind of found what we're calling in the book this science of happy accidents. In other words, if you want to find the treasure that you didn't know about when you started digging, then you need to have this methodology for creating, engineering these, what we're calling, happy accidents, like AWS, like Google Maps.

But how do you design for something when you don't know what it is? Well, there's our rowboat with happy accidents coming in. We thought about putting on the pirate costumes and the Bob Ross wigs, and we spared you from all that, so hopefully it's not disappointing.

When we looked at the patterns, we kind of distilled this down, again, empirically from looking at all these case studies, both in the high tech as well as in these established industries. We distilled them down into these three methods that we call OOPS.

So the book is very much about the OOPS of happy accidents. The reason it's called OOPS is we have a little bit of alliteration going on with these concepts.

Number one is this idea of creating optionality. How many people have been hearing about optionality the last couple of days? It's come up a couple times. I think Gene's been, if you listen to the Idealcast that Gene was doing not too long ago, a lot of the themes were around optionality.

For today's talk, this is what we're going to really dive into, this idea of optionality, because it's something that probably for anyone who's been in the DevOps space, or in the software engineering space, or who has worked on API-first architectures, service-oriented architectures, or microservice architectures, the idea of optionality and modularity, I think, comes pretty naturally to people building software.

But there's a real economic business side to optionality that we're going to get into, which I think is profoundly part of engineering these happy accidents that we talk about.

Our book is called Unbundling the Enterprise because this is the essence of how you can actually unbundle these complex composite systems, solutions, products even, into the components that make up a platform, make up something that helps you build new things with those different components. That's really what we're going to dive into today.

What we won't have time to dive into as deeply today, but obviously we're doing a book signing later on, and hopefully you get a chance to read the book, are these other areas.

It's not enough to just create a whole bunch of options and hope that they pay off. There are ways, without having a prescriptive five-year plan that's trying to get to that one X that marks the spot and missing all the other treasure, of surveying the landscape to see, at least make sure you're going to the right island.

We call this value dynamics, which is a way of looking at all the different components and opportunities within your business. Looking from an outside-in, more of a jobs-to-be-done perspective, kind of a Clayton Christensen value network view of the world, that will allow you to start to map out how you can build a business model, essentially as a composite of how you create value, capture value, and deliver value.

That's a whole other methodology we call value dynamics, which we encourage you to study in the book.

And then lastly is this idea of bringing it all together and optimizing through feedback loops in that type of value network setting. This is something that is very achievable in the digital world in a much more powerful way than perhaps in the analog world, creating feedback loops, utilizing these digital channels to not just look at APIs as a way of delivering data and delivering value to the world, but as a point of engagement with channel partners, customers, where you can actually bring back data and measure and drive feedback loops. It's a huge part of it as well.

But for this talk, we're going to really dive into optionality. I'm going to hand it over to Steven.

Stephen Fishman

Thank you, Matt.

So I don't know how many people in the room know who Carliss Baldwin is.

Awesome. Tell my mom. Awesome. Whoa. Okay. You've got to be careful now.

I refer to Carliss Baldwin as the godmother of optionality.

Yes, yes. I was taking screenshots then. I'm going to relay them back. Awesome. I need a chair. I need a chair here.

Carliss Baldwin is just an amazing professor emeritus at Harvard. You could probably tell a lot more about that.

For people who are interested, one of the things that comes out of her work is this key quote: option value is high when consumer tastes are heterogeneous and unpredictable, which kind of defines the universe we live in.

People like different things. People are fickle. People keep changing what they want, especially as new technology comes in and it changes the constraints around what they want to do, what they can do.

When these things are true, option value is high and skyrockets through the roof.

Now, there are two different ways to describe optionality, and we're kind of pivoting here between the work of Carliss Baldwin and the work of Nassim Nicholas Taleb.

Does anyone know who Nassim Nicholas Taleb is? That would be amazing.

He's known for some big book works called The Black Swan, Fooled by Randomness, Antifragile: Things That Gain from Disorder. He describes and breaks down the world of options into two different types: concave on the left, convex on the right. Don't get too intimidated by the math curves because we're going to make all this easy for you.

The concave options are ones that have a high amount of pain, meaning the cost to deal with them, and the gain that you might get from them is fairly small.

Convex options on the other side are cheap to create and conserve, but the value that they create is uncapped. That's what he refers to as asymmetric value.

So for the people who have a phobia of math, we make this really simple in the frame of our two pirates.

Graybeard on the left. Graybeard believes that the future is predictable. That's his map that he believes, that he'd dig in one place. That's the three years' worth of effort that Graybeard puts into building his ship, recruiting his crew, finding an island, going and digging it up. Maybe he'll find it. Maybe he won't.

Bob on the right. Bob believes the future is inherently unpredictable. The happy face that he gets when he finds his accidental treasure is amazing for him.

So you can actually manufacture your own luck. You can manufacture systemic innovation. It can be done.

Now, on the left, when Graybeard doesn't find his treasure in the one place because he's committed everything to that one idea, that's the five-year plan. Taleb refers to it as a highway without exits. When he and his crew don't necessarily find the treasure where they predicted, they're likely to make him walk the plank.

Now, on the other side, there's what's called serial optionality. It's doubling down based upon the feedback loop's information. When you find the winning option, it's not that you will win more often than you will lose. Some options might not be that great, but the winning one has asymmetric value proportion because option value is high when consumer tastes are heterogeneous and unpredictable.

And I do want to hear what your mom would have to say about this.

I do think the converse of Baldwin's statement is also true: if value is high when consumer tastes are heterogeneous and unpredictable, rigidity is dangerous when consumer tastes are heterogeneous and unpredictable. Because as consumers switch, you won't be able to.

Now, for any of the DevOps professionals in the room, you would know this because when organizations build up technical debt over time through cost-cutting or through corner-cutting, by default that shortcutting creates that debt. Then over several years that debt accumulates, and then you have a balloon payment that comes due.

Finance teams will never accept the idea of, “Hey, I want to spend two years building an automated testing suite for all of our apps that we should have been doing the last 10 years.”

I don't know if anybody's seen that problem. I personally have. It's just not really a solvable problem. There are ways to get around it, but the one that we're talking about is finding the small ways to actually make incremental costs.

Not build APIs everywhere, not for everything, but if you're already going to build the solution, decompose it. Because the amount of effort and cost that you have to put in to do that is relatively small. It's minutiae to be able to do that. And going the other way kills all the options of what your solution might be able to be repositioned into and deliver.

There's a specific reason why this works, especially in digital product. This is not just for the digital giants.

I don't know how many people in the room know what rival product versus non-rival product is. If I pulled out my phone, my phone is a rival product. It has a specific cost of goods sold for Apple, and every one that somebody buys is one left in supply. And the margin that you get from selling the 30th one or the 30,000th one is effectively the same. Does that make sense? Because the cost of goods sold is fixed.

Digital products are not that. Digital products have a fixed cost and variable costs are reversed. Once you actually pass over that break-even point, everything after that point is 100% margin, or fairly close. And I know I'm oversimplifying black and white, but it actually rings true. It actually holds true.

Now, this is the exact reason why SaaS companies are valued higher than non-SaaS companies, because they have this asymmetric potential to actually allow for uncapped margin once they pass the break-even point.

Now, just as an example, and what Matt told you before is right, we didn't write the book with this idea at the beginning. We only figured it out after talking to directors and VPs and CIOs from various different companies, including Asac Azar at Coca-Cola. Every single one of them, without fail, said, “Oh, we didn't plan for this. It just kind of happened.”

I don't know who knows about this: Google Maps did not intend to sell their API as a product. That was never a goal. That goal only happened when people found the platform. The engineers reverse-engineered it. They found the API through looking at the source, and then used it for themselves to build their own business models on, and then went back to Google and said, “Can we pay for this?” It actually happened exactly that way.

And they said, “All right, I guess we'll let you pay for it.”

Now, the same is true for Slack. The same is true for Coca-Cola. The same is true for Best Buy, over and over and over again. And we said, “I think we found something interesting,” and it was a happy accident for ourselves.

Matthew McLarty

Just a little bit on Coke, if that's okay.

I think it's fair to say, the idea of the rival versus non-rival that Steven was talking about, this is another one of those things that maybe in our frame of reference, working in the technology space, we're not necessarily thinking that way. It's sort of implicit knowledge. Software is just different than physical products.

Physical products have those unit costs. They have shipping costs. They have all this cost baked into it. Whereas software, we've always known this, right? You create it once and replicate it everywhere, and it just completely blows the economic model out of the water. That's where this serial optionality idea comes in.

I think it may be more obvious for startups or digitally native companies, but for a company like Coca-Cola, they did some really interesting stuff in the tech space. We go into this in the book with Asac, where he's talking about coming in as a new CIO, having to prove himself as old-school IT off the top to get the credibility, but then very much getting a seat at the table with the business.

They were really intentionally looking at new technologies and finding a way to do new technology introduction. Image recognition was one. Augmented reality.

And they went in, to Gregor's point, saying, “We know we don't know all the use cases for this, but if we partner with the business, we can find the use cases for this. We can put it behind APIs. We can allow these multiple lines of business to build things.”

They were able to go from maybe thinking that they were going to have an inventory management advantage through image recognition, as an example, to actually coming up with ways of going into stores and empowering a whole fleet to go out into stores and do image recognition to count inventory in the stores and retailers, even counting some of their competitors' inventory.

Stephen Fishman

And they built it on top of what they already did.

They already had the image recognition API for their inventory system, and then they turned it into a way to actually help the retailers debug coolers. They turned the exact same technology and they used it for both.

They combined the image recognition and the AR to do something even wilder. They actually used it and they gave it out to their consumers.

I don't know how many people remember this, that time when Coke did Coke Rewards. They would encourage consumers to go out and take pictures of the coolers at the retailer.

Now, there were a number of different goals inside this. A big goal was the retailers weren't following Coke standards for what they had in there. You might go to Home Depot or wherever and you'd see, well, there's Coke product in there, Pepsi, water, who knows? Whatever's in there is what they put in there that day.

And when they actually gave it to consumers, consumers actually took the pictures, got Coke Rewards points. They were able to actually drive compliance at the retailers without sending anybody out there. They just made the Coke drinkers their actual compliance staff. And the Coke drinkers actually bought more Coke.

Through serial optionality, by doubling down on that feedback loop and reusing things they already built: low cost, big return, unpredictable return, but they never had an idea when they started.

So to really dive down, there are tons of case studies in this book of every time people finding happy accident after happy accident, doubling down, doubling down, and becoming like mega-billionaires in what they're able to do.

These three OOPS methods, API-based optionality, value dynamics for finding the right opportunities, and accelerating that feedback loop so they could do lots of experimentation. That means being able to dig everywhere at once. That's the land of a thousand shovels for the pirates.

We've seen it in both digital giants, or the digital pirates, and the digital settlers. The ones who actually prepare early and decide late, those are the ones who continuously win over and over again.

The book has tons of illustrations and patterns for actually how to do this and how this has worked inside of all these different companies. There are like 15 or some amount of case studies in there. The patterns are illustrated so you can mix and match and do the patterns as you want.

There's a whole section for the actual nerds who actually have to build it, for tips and practices, for pitfalls to avoid, and how to make it work.

Matthew McLarty

All right. We're on time.

Stephen Fishman

We are. We're on time.

Matthew McLarty

Thanks very much for staying with us. Like I said, we'll be part of the book signing. That's later on. I know we've got lightning talks between now and then.

Stephen Fishman

And we do have one thing to ask for help from the room.

A lot of the reason we wrote it, because it's not written for coders. Coders will like it, but that's not who we wrote it for. What we wrote it for is to close the gap between technologists and architects and the people who are running the business, people who are running the product, people who are running finance, to help them actually see together.

One place we would like your help: we need more connection and feedback from those leaders outside of the technology domain to help us not only improve our work, but help them see what will actually help close the gap.

Because we care. We care that technologists can actually create that big moment. People who work in this domain, they like to make great things and make great things work and have great impact. We believe that if you can create more alignment and harmonization between those two groups of people, we think that companies can succeed in ways they never imagined by finding their own happy accidents.

So thank you, everybody. We look forward to seeing you at the signing.