Stephen Fishman, Field CTO at Boomi, asks an important question for enterprises today: When OpenAI introduced ChatGPT in November 2022, why is it that so many companies were able to build ChatGPT into their products within about a month? Why didn’t it take six months or a year? Why was the big news about ChatGPT the eye-popping speed of adoption, not the head-scratching challenge of re-engineering and integration?
The answer: Companies had been investing in application programming interfaces (APIs) for years, if not decades, and so they were ready for the surprise appearance — the happy accident, if you will — of ChatGPT. OpenAI released their amazing chatbot, companies scrambled, making use of the APIs they had already built, and voila! AI-powered products appeared in nearly every industry.
How can companies best prepare to take advantage of other happy accidents like the arrival of ChatGPT? The answer to that question is the topic of a new book by Stephen Fishman and Matt McLarty, Boomi’s CTO.
Here’s a quick explainer:
- Optionality means building for what might be useful later, rather than restricting IT development simply to short-term goals that yield immediate and predictable financial returns.
- Opportunity means seizing opportunities when they arise, and having an organizational structure ready to do so.
- Optimization means being able to experiment quickly and affordably, discovering what works, and being able to continuously optimize what you’ve built.
The OOOps methodology makes a few assumptions based on things that are obvious. The world of IT is changing so quickly that traditional long-term planning is of limited utility. Instead, companies should give themselves options. Instead of going all in on a few big, expensive IT initiatives, they should invest in being able to run lots of experiments quickly and affordably. Then, when opportunities arise — even game-changing ones like generative AI — companies can respond quickly and seize the day.
I sat down with Matt and Stephen to discuss their book and the importance of OOOps for companies of all sizes today.
How does OOOps relate to APIs? Let’s start with optionality.
Stephen Fishman: OOOps has three o’s, and the first one is optionality, which means keeping your options open. When it comes to IT design, I describe this as “decomposed by default.” Which means if you’re going to build something, don’t build one giant thing. Instead build small chunks of capability in packaged components that can talk to each other through a standardized interface, which in most but not necessarily all cases is going to be an API.
Most organizations don’t understand this. For them, the default is to get to market in the cheapest way possible, no matter what. If you’re going to do something different — if you’re going to build something that’s more open-ended and flexible — then the burden is on you to justify doing that. In many organizations, you actually have to be able to demonstrate what that extra investment is going to yield. What’s the ROI of doing anything other than what’s cheapest and fastest? If you don’t know, if you don’t have spreadsheets detailed and plausible enough to convince the finance department, you’re probably not going to get permission to proceed.
Matt and I are suggesting that companies turn that thinking on its head. We want to switch the default, because we believe that decomposition (that is, breaking big things down into chunk-able components) is the optimal path for developing just about anything. We’re not saying you always have to decompose things, but we do think it should be the default. And if you want to do something different and not break things down, then you should have to justify your decision. You should have to say, ‘OK, I’ve this specific use case where speed to market really matters more than it usually does’ or something along those lines. And that’s fine, sometimes that’s appropriate, but the burden of proof is on you. You have to be willing to say, ‘Hey, we know we’re scuttling options for the future, but it makes sense in this context because of these reasons.’”
Where does opportunity come in?
Matt McLarty: I think the key thing there is nobody’s measuring option value when they’re building things. Instead, when companies fund particular business cases, they’re making decisions about specific scenarios that they can see right in front of them. Nobody’s measuring option value — that is, the value of keeping their options open and what those options might yield. Yet we know that software has the potential for all this optionality. We saw that with the rapid adoption of ChatGPT, for example. So they’re just discarding optionality and saying we’re going to take the quickest, cheapest path and over again.
Of course, you don’t necessarily need to keep your options open and build an API for everything. The opportunity — that’s the second O in OOOps — is really about developing the intuition to know what the right options are and when to exercise those options. The value dynamics exercises we describe in the book came out of work that Stephen and I have done previously around exploring this idea at other companies.
Value dynamics, as we explain, means the exchange of values in a bounded economic system. Value dynamics looks at the way that value flows among constituents in that ecosystem. These constituents could be individual people or roles or even organizations. Who is getting what? There are several possible currencies of value available: money, products, content, time, reach, and so on. (We describe all of these in Chapter 4 of the book.)
When you map all those value exchanges for a specific part of your business, you get a better understanding of where potential opportunities lie. Then you can identify where it makes sense to decompose what you’re building into small, flexible components that you can recombine as necessary when new market opportunities arise. Those opportunities might be new markets or new technologies or new channels of communication, like mobile phones.
We also talk about the idea that in real life, no company really has a pirate treasure map where X marks the spot where future innovations are going to yield enormous returns. The world of IT today is so vast, complex, and dynamic that nobody really knows where the next buried treasure is going to be found. So instead of betting everything on being able to dig just once in a single location, we’re proposing that companies create a way to dig in lots of locations simultaneously. To do that, you need a way to experiment affordably at scale. Optionality helps you prepare for this kind of experimentation, and thinking strategically about opportunity helps you be ready to act quickly and with confidence when you suddenly find a new patch of sand.
How about optimization?
Stephen Fishman: What Matt was just saying about optionality points out something that goes way back to the beginning of the book, when we talk about being able to drop the cost of experimentation across the board and the misconception so many people have about MVPs (minimum viable products). For many people, an MVP is really just a bare-bones product that they can ship as early as possible. But the original idea of an MVP, which was developed by Frank Robinson back in 2001, is that an MVP should be tied to value metrics. That is, it should be an experiment that enables you to measure results, so that you can run other experiments and optimize what you’ve build. (Optimization, remember, is the third O in OOOps). Through that ongoing optimization, you can then refine and rebundle capabilities as necessary to achieve the eventual outcome you want.
To put it another way: an MVP is an experiment that takes advantage of decomposed components. You want to keep the cost of experimentation as low as possible so you can experiment quickly, discover the best way of delivering value, and seize whatever opportunities are presenting themselves. An MVP is not just something you build quickly and ship. Instead, it’s something that opens the door to lots of learning and the kind of experimentation that leads to long-term success.
Matt McLarty: I should point out that the Boomi Enterprise Platform is ideal for this kind of work. We have an AI-powered, low-code development platform that makes it easy to build connections and to build and manage API products, run code in any environment on-premises or in the cloud, and iterate quickly without having to spend weeks or months on development and testing. And with our federated API management, we give companies more visibility into and control over their APIs than they’ve ever had before. So, you can build APIs and run experiments without worrying about losing control over what you’re developing or new shadow APIs suddenly appear across your network. You get speed, scalability, and governance all in one platform. Simply put, we help you unbundle the enterprise at enterprise scale.
Buy “Unbundling the Enterprise” to learn how your organization can best prepare to take advantage of “happy accidents”