OOOps: A Science of Happy Accidents

The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and the Science of Happy Accidents by Stephen Fishman and Matt McLarty.

Using the examples we’ve already walked through as well as several more we will study, we propose a science of happy accidents consisting of three methods. First, you need to create optionality by unbundling business capabilities through APIs. These API-enabled business capabilities are like your mechanical pirates digging for treasure. 

Second, you need to use value dynamics to identify the opportunities that represent the best starting point for your experiments. We will explore value dynamics in detail in subsequent chapters, but for now, you can think about it as a way of finding the right island for your pirates to excavate. 

Last, you need to establish the right feedback loops to help you optimize your innovation experiments. This helps your pirates know where to stop digging and where to double down. Collectively, we call these three methods—optionality, opportunity, optimization—OOOps.

• Create optionality through unbundled APIs.
• Identify opportunities through value dynamics.
• Drive optimization through feedback loops. 

Optionality Through Unbundling

As you approach your own life, do you make significant commitments as soon as possible or as late as possible? If you’re seeking a new job, working with your children through the college application process, or even using an online dating app, do you commit to the first possible choice that comes your way or do you try to slow the decision down until more information becomes available? Slowing down the process of making commitments conserves optionality.

Using APIs to expose business capabilities allows an enterprise and its partners to slow down the process of making a commitment for exactly how a capability will be used, allowing the business to pursue multiple options at once. Software systems built using APIs allow optionality beyond the intended scope of an individual solution without significant sacrifice. In the case of Google Maps, Google never intended to turn its API into a paid product. However, because they chose not to lock themselves into a single context of use, businesses around the world were able to leverage the API to seek their own treasure. Rather than Google choosing to put a price tag on the API product, it was the users of the API who asked to pay for it to ensure that they could depend upon it as they incorporated Maps into their business models.

Optionality can be created in any software system. Consider a bank that wants to provide a self-service account open option for its retail customers. The bank would want this process to be as streamlined as possible, but at minimum, it would involve collecting customer information, checking credit scores, providing and vetting legal forms, giving choices for account types, and creating the new account, as well as tracking and communicating the status of the whole application. Figure 2.5 shows one way to solve it: build a monolithic web app that provides a self-service user interface and integrates with existing backend systems. 

This solution meets the stated requirements and that’s it. But this same service could be delivered with a much higher degree of optionality. Figure 2.6 unbundles five capabilities from the web application and exposes them through APIs. The user experience remains the same, but now the bank has the option to take these capabilities out of the self-service account open context and use them in other ways. Customer information and retail account services can be leveraged at other customer service channels, such as in branches or at the call center. Document management and workflow tracking services can be used in numerous business processes. Credit scoring could conceivably be packaged and sold to third parties. Furthermore, the bank has more flexibility to make changes if this account open process needs to be augmented with new capabilities or if changes need to be made to its existing capabilities. The bank may not know what all the options are for the future, but it will be poised and ready through unbundling.

For decades, industry experts have advocated for modularity in software architecture, from early papers on information hiding through service-oriented architecture and microservices. However, choosing to make a decomposed architecture made up of discrete capabilities isn’t just a technical choice. There are real financial benefits to creating decontextualized digital capabilities. Once unbundled in this way, these APIs can be rebundled into countless new contexts.

Opportunism Through Value Dynamics

Ultimately, the value of digital systems can be measured by how well they align with an organization’s business model. Alexander Osterwalder, creator of the Business Model Canvas, defines business models as the way companies create, deliver, and capture value.⁵ We expand on that to define value dynamics as a visual method for mapping out business models by illustrating the flow of value in a digital ecosystem. These business model maps use a few simple elements:

• Shapes to depict constituents in the ecosystem, such as companies or consumers.
• Arrows to show the flow of value between constituents.
• Icons that indicate what type of value “currency” is being exchanged. There are some obvious value currencies and some that aren’t as intuitive.

Figure 2.7 shows a basic example of value dynamics using the relationship between a retailer’s business model with that of a wholesaler in the same customer ecosystem. Obviously, the retailer purchases products from the wholesaler, which it then sells to end customers. However, visualizing the business model allows for the articulation of the retailer’s unique role in the ecosystem. The retailer can buy products for a lower price from the wholesaler, since it is also providing reach to a targeted set of customers aligned with the wholesaler’s products. On the other side of the picture, the retailer can mark prices up to consumers, since it is providing time savings and convenience in the form of store locations, product curation, customer service, and more.

Value dynamics allows you to illustrate a simple view of the value exchanges happening in your current digital ecosystem, thus depicting your business model according to the Osterwalder definition. Understanding how your business model works today, you can overlay what new capabilities or “options” you have; consider what value those capabilities capture, deliver, or create; and then see how that can flow between constituents in the ecosystem. From there, you can look for opportunities to add, augment, or eliminate value exchanges and even think through what new value can be captured on existing links. By using such a constrained set of items, the whole process can be gamified.

Optimization Through Feedback Loops

A common theme across the first two OOOps methods is lowering the cost of experimentation. Unbundling and optionality provide a faster and cheaper path to running experiments by providing digital building blocks. Value dynamics points the way to starting points that have a higher probability of yielding useful results. The third OOOps method—optimization—is about setting up feedback loops that help continuously decrease the cost of experiments and time to value.

Software movements such as Agile methodologies and DevOps stress the criticality of paving the path to learned insight. The notion of feedback loops and situational awareness are prevalent in any management methodology focused on dynamic environments. Back to the treasure hunt analogy, once those pirates start digging on the selected island, how do they determine when to stop digging or when to bring in more shovels? There are four main themes (see Figure 2.8) that emerge for how enterprises can ruthlessly lower the cost and time required for teams to create and test bundled and unbundled packages of value and deliver consumer-facing experimentation at scale.

Feature flags provide the ability to make targeted changes in API-enabled capabilities to controlled sets of audiences. From the color of a screen element to a change in the flow of screens for any user task to an alternate execution route via different APIs, feature flags can not only aid in optimizing the ­experiences of your developers and users but also help to control the risks and costs of your experiments.

Making it easy to segment traffic is the second tool to control the size of audience members receiving experimental changes. Ramps enable your experimentation teams to funnel a controllable percentage of all application traffic, again with simple configurations controlled via automation.

Just like a DevOps professional might use a waterfall chart to understand performance bottlenecks, your experiment teams will need robust visualization tools to make the efficacy of experiments self-revealing.

Finally, both statistical literacy and tooling are required to interpret the measurements derived from feedback loops. While the tooling capabilities are critical to making this approach work, it’s equally critical to have a team of qualified humans to interpret the results. Both your business and technical teams need to be deeply familiar with the language and tools of statistics. Mature teams know that data beats math, and elite teams know that statistics tools can be misleading and cause speed-killing friction when you don’t have the expertise to discern what the results mean and what they don’t.

In addition to these techniques, APIs create their own feedback loops. People commonly think of APIs as sources of data, a place where information can be retrieved or services can be requested. However, every API interaction creates contextual metadata that can be leveraged for other sources of value. Look at the example set by Google Maps. Maps consumers were happy to pay Google to get geolocation data in real time. But in so doing, those consumers were also providing information about their own locations and signaling intent by the requests they made. When the mobile boom happened, Google was able to profit from this geolocation context by using it in ad targeting, a strategy we will explore more deeply in Chapter 9. We will see many other examples where APIs have been used to drive useful strategic and operational feedback loops. 

Feedback loops provide the instrumentation in your digital ecosystem. These four feedback mechanisms, and even APIs themselves, allow you to continuously measure value exchange and value impact in your ecosystem. Doing this will help you drive down the cost of creating new options and drive up the return on investment of exercising those options.

The three OOOps methods work most effectively together. If you just created APIs out of every software function in your environment, you might have a lot of options, but they could be rife with duplication and misaligned with the value-generating areas of your business. Value dynamics on its own could provide some useful starting points for digital innovation, but those opportunities would be difficult to explore without options and be merely speculative without feedback mechanisms. Last, feedback without a strategic direction would just provide a more accurate means of demonstrating stagnation. Combining the three OOOps methods, however, yields remarkable results.

OOOps for Digital Settlers

The OOOps methods haven’t only been proven by digital pirates. Progressive Insurance is one digital settler who has utilized API-enabled unbundling to drive innovation. True to its name, Progressive has a history of disrupting the consumer insurance industry. 

In the early 2000s, at the same time Amazon and Google were first introducing their web APIs, Progressive was already experimenting with APIs of its own. In its Claims group, Progressive launched an application called “total loss concierge” that helped drivers obtain financing if their vehicles had to be written off following a claim. To power the application, “[Progressive] used SOAP (Simple Object Access Protocol) to connect directly with banks to get financing options,” recalls Geoff McCormack, one of Progressive’s enterprise architects who remains with the company today.⁶ This early move turned the company onto the value of unbundling through APIs, as well as the opportunism of digital ecosystems.

In the late 2000s, Progressive introduced Snapshot, a pluggable device that collected driving data used to assess drive safety. Customers could opt in to use this device to gain discounts on their auto insurance premiums. In the data-driven insurance industry, Progressive was able to disrupt the standard approach of pricing primarily on variables and instead utilize dynamic data. The company used an approach akin to the second OOOps method—opportunism through value dynamics—implicitly in this innovation. Furthermore, they were basing the innovation by optimizing through feedback loops (OOOps method #3) of driver information.

Progressive has also employed the first OOOps method: optionality through unbundling using APIs. For the last few years, Progressive has adopted an API-first approach to building its software systems that is paying dividends. Analyzing this unbundled landscape of business capabilities, Progressive recently launched a product targeted at small business customers that bundled its own APIs with a third-party, API-based insurtech provider of underwriting services. This brought the product to market in a matter of months, well ahead of expectations. “Our mindset is all around innovation, and we see the value in partnerships,” McCormack states.⁷ This ecosystem mentality is well-aligned with value dynamics.

Down to the Depths

Progressive Insurance is just one example of a company established prior to the web—a digital settler—figuring out the right approach to thriving in the digital economy. Although they weren’t using a playbook for digital innovation, they adopted principles and practices used by the digital pirates to good effect. The next few chapters provide a playbook to leverage the learnings of digital success stories. We will go into each of the OOOps methods, illustrating how they work in action and how they combine to define a science of happy accidents.

- About The Authors

Matt McLarty

Matt McLarty is the Chief Technology Officer for Boomi. He works with organizations around the world to help them digitally transform using a composable approach. He is an active member of the global API community, has led global technical teams at Salesforce, IBM, and CA Technologies, and started his career in financial technology. Matt is an internationally known expert on APIs, microservices, and integration. He is co-author of the O'Reilly books Microservice Architecture and Securing Microservice APIs, and co-host of the API Experience podcast. He lives with his wife and two sons in Vancouver, BC.

Follow Matt on Social Media

• 

Stephen Fishman

Stephen Fishman (Fish) is the NA Field CTO for Boomi. He is a practicing technologist who brings creativity, rigor, and a human-centric lens to problem-solving. Known as an expert in aligning technology and business strategy, Stephen places a premium on pushing business and technology leaders to embrace iteration and the critical need to collaborate across disciplines. Throughout his career, Stephen has consulted with organizations desiring to transform their technology-based offerings to better meet the needs of organizations and the people they serve. In addition to consulting with large organizations, Stephen is an in-demand speaker and advisor. Stephen has led multidisciplinary teams to deliver amazing results at Salesforce, MuleSoft, Cox Automotive, Sapient, Macy's, and multiple public sector institutions including the US Federal Reserve and the CDC. He lives in Atlanta with his family and when he's not working can be found biking on the many trails in Georgia.

Follow Stephen on Social Media

•