Editor's Note: In December 2018, ProgrammableWeb published a case study involving Intuit's Quickbooks ecosystem. It demonstrated the importance of putting end-to-end customer experiences and holistic platform thinking way ahead of the premature question "What should our API strategy be?" In the course of interviewing the head of the company's developer group Alex Barnett, we learned about the subtleties that make successful ecosystems tick. Believing that Intuit's journey could be truly instructional to other organizations hoping to join the API economy (and as can be seen from the illustrations in that article), we were inspired to artfully diagram the Quickbooks ecosystem in a way that accurately captured those subtleties.
After our initial attempt, we realized how these visualizations could not only serve as a valuable tool, we imagined that we could set a standard for how any organization's ecosystem could be captured, visualized and explained. Especially for the benefit of those hoping to learn from the successes of others. In this follow up, we're revisiting Intuit as our test case and taking that visualization standard to a new level (version 2.0?) where we get into the details of what a successful API ecosystem looks like and how you should go about building yours.
Contrary to popular belief, succeeding in the API economy is not as simple as creating an API, tying it to a business model (eg: $10 for 1000 API calls), making the API publicly available on the Internet, and waiting for the money to roll in. Unfortunately, unlike the mythical baseball diamond in the middle of an Iowa cornfield, if you just go ahead and build it, they (the consumers of your API) are not likely to come. At least not in the droves that you were hoping for.
Instead of putting the proverbial cart before the horse, the companies that have done best in the API economy are the ones that save the API details for later. They start by first establishing business objectives and priorities, conceptualizing the end-to-end customer experiences and business moments needed to support those objectives, and then they organize the necessary ecosystem — including the APIs — to launch the vision.
Most people don't know what an ecosystem is, much less how to design one. The purpose of this paper is to use a real-world ecosystem example to demonstrate the subtle complexities of ecosystem design as well as to demonstrate how APIs (with the right ecosystem) are like opportunity multiplexers for businesses. In other words, how, with the right ecosystem design, a single API fabric can simultaneously enable multiple business opportunities involving new operational models, multiple channels, multiple business models, and new product/service offerings.
Instead of leading off with a primer on ecosystem concepts and then using a real-world example to demonstrate those concepts in action, let's just dig right into a real-world example and identify the ecosystem concepts it exemplifies.
The real-world example we'll be using for this article is Intuit; provider of the globally popular small business accounting brand Quickbooks. Although 99% of the API-specific thinking should come later in the journey, there is one critical architectural decision that organizations should commit to early in the process the way Quickbooks did.
A critical key to Intuit's ecosystem success — as well as that other organizations' ecosystems — is how Intuit envisioned its entire business as a single unified platform; a business-as-a-platform (BaaP). In other words, it started out knowing that once it got around to exposing APIs, that it didn't matter whether those APIs would be exposed to internal developers, external developers, or both (or for what reasons). No matter the use case, there would be a single platform to serve all constituencies within its ecosystem. Speaking directly to that commitment in an interview with ProgrammableWeb, Alex Barnett, head of Intuit's Developer Group said "Platform thinking is central to the way we work. We believe we're going to be a platform-as-a-business."
To demonstrate that central platform's role in Intuit's ecosystem, and to assist with the visualization of ecosystem assembly, ProgrammableWeb has created a standard graphical template (see above) for mapping the layered features of API-driven ecosystems — one that visualizes not just the various entities within them, but also some extent to which they interact with one another to co-create different forms of value, different business models, and different channels for reaching customers. One caveat; this template abstractly represents the concepts of an ecosystem as opposed to demonstrating with technical precision the specific interactions between layers (or their order). It is intended as a visual for both technical and business people who should be collaborating on how an ecosystem can drive overarching business objectives.
While this ecosystem walkthrough breaks things down as though you're moving from the ecosystem host's (Intuit) core capabilities and competencies out to the eventual delivery of those capabilities to customers, keep in mind that you should actually strategize in the reverse direction; in other words, strategizing with "outside-in" thinking. For example, according to our blueprint for API economy success, put yourself in your eventual customer or consumer's shoes and imagine the end-to-end customer experience that would be most pleasing and pleasantly surprising to them. Then, work your way back to your core competencies and capabilities, inserting the necessary entities and relationships in between to ensure provision of that end-to-end experience.
Our map of the Intuit ecosystem starts with a wireframe showing how customers occupy the outer edge; the people and organizations to whom Intuit is looking to offer an amazing experience.
The reason different groupings of customers are scattered around the outer edge of the wireframe is because there are different customer personas, each of whom may have different needs and who are likely engage Intuit through the different channels supported by the ecosystem. What do those customers want? At bare minimum, they need access to the core competencies and capabilities of Intuit's Quickbooks Online offering, viewable at the core of the ecosystem map.
The main idea here is for your organization to start thinking about all of its core capabilities and competencies as digital offerings that taken together, will form the basis of a central, singular platform, as described earlier by Intuit's Barnett; a business-as-a-platform.
One question we get at ProgrammableWeb is, "What if our core capabilities are not digital by their very nature? In other words, they are analog. How then do you convert an analog offering into something that is digital; something that eventually becomes a platform?"
This question is one of the biggest stumbling blocks for many organizations looking to hatch a winning digital strategy. The answer often lies in another question; how can you make the offering so that it is engaged digitally? In the old days, a ride in a taxi or limousine was a very analog experience. Today, thanks to Uber and Lyft, the entire experience of those rides — everything from hiring them to waiting at the curb to rating them — is engaged through digital means. Although not entirely necessary to the fundamental act of hiring a driver, the highly digital in-app customer experience is also a part of the end-to-end customer journey.
Again, going back to the idea of letting the end-to-end customer experience drive your thinking, consider how Uber and Lyft completely rethought the entire customer experience of frictionlessly hiring a driver and then arrived at the platforms necessary to deliver those experiences.
Internal Use Cases vs. the API Economy: Two sides of the same coin
When Intuit decided to view its business as a platform (as opposed to an end-user software offering) it also made the strategic choice for that platform to simultaneously serve both internal and external use cases. Great BaaP strategies succeed when internal platform use cases such as integration, legacy modernization, and organization-delivered (vs. third party) web and mobile apps are on one side of a coin. The other side of that coin are the so-called API economy use cases involving external developers, partners, and new business models and channels of business. The white stripe across the middle of the ecosystem map is essentially the edge of that coin. The internal use cases covering new operational models are below the coin while external use cases are above it. When Intuit's core capabilities and competencies are exposed with private APIs for internal use, those private APIs are reflected on the bottom side of the coin as follows.
Since they are private APIs, they can only be consumed by applications and integrations that are developed by Intuit's internal developers. Again, these applications might involve legacy modernizations, integrations or web or mobile apps developed by Intuit. As consumers of the functionality exposed by those internal APIs, these various internally developed applications appear one layer out from the core on the bottom (internal) side of the Intuit's platform as shown below.
And, it is Intuit's internal developers that create those Intuit applications for both internal consumption (ie: legacy modernization or behind-the-firewall integrations) and external consumption by customers (web or mobile apps). This layer is shown below in lavender. Alternatively, this layer could have appeared directly against the API layer to reflect that developers instead of the applications are direct consumers of the APIs. But our template is more of an abstraction of the ecosystem to spotlight the various constituencies and technologies and how a single, central platform — a unified business as a platform — sets the stage for multiple business models and ways for customers to engage an organization's core competencies.
As you will see shortly, our arrangement makes it easy to see not only how the template graphically supports the idea of a business as a platform (BaaP), it also captures the collection of entities that comprise an organization's network of applications (and their enabling APIs) aka an application network.
Note that this map only shows ecosystem structure. Were you to start mapping your own ecosystem, you might show this evolutionary step in your structure early in the process. But it should lack specificity about APIs (the required APIs and their design) until the applications and integrations area is clearly defined. For example, if mobile apps are necessary, the experience of those mobile apps should be conceived from the outside in; what are the customer's expectations and needs and what sort of mobile app can pleasantly and surprisingly serve them? Once those requirements are established, you can begin to fashion and choose the APIs needed to efficiently support those experiences. Later in this paper, we'll discuss the idea of API-first design (sometimes called "contract-first" design).
In Intuit's case, its internally developed applications rely primarily on internally exposed APIs. But Intuit could just as easily rely on third-party provided external APIs as well (the way Uber's ride-sharing application relies on APIs to incorporate the capabilities of Google Maps into its final customer experience).
When customer experiences require an organization's internally developed applications and integrations to rely on third-party provided APIs, the resulting ecosystem structure might look something like this where the internally developed applications and integrations depend on those third party APIs as though they are extensions of the organization's native capabilities.
However, based on the content of our interview with Intuit's Barnett, third party APIs were not a primary factor in Intuit's ecosystem or its business as a platform. So, for the remainder of this ecosystem build-out, we will exclude the third party API slice.
As mentioned earlier, when organizations commit to a unified platform to serve the interests of both external (if required) and internal developers, those two developer constituencies represent two sides of the same coin; internal developers on one side of the coin (the bottom) and external on the other (the top). The white stripe across the middle of the template is the edge of the coin. When the same central platform serves all developer constituencies, it makes it possible for some of the APIs to be re-used across both groups.
To demonstrate this concept — where internal and external developers share some of the same APIs — let's impose a layer of public APIs that appears both above and below the edge of the coin as follows.
In this representation, what were once just private APIs (light blue, on the bottom) are now a mixture of private and public APIs. In other words, some (if not all) of the APIs that were once private and intended for internal consumption (on the bottom) are now public and consumed both internally and externally (dark blue).
In order for API providers like Intuit to successfully attract external developers to their ecosystems, it's imperative for those API providers to make it as easy as possible for developers to join the ecosystem and start developing. The more frictionless the "developer experience" is, the greater the likelihood that external developers will succeed at their objectives.
One common approach to improving developer productivity is to offer software development kits (SDKs) that make it easier for developers to build software using your APIs on their favorite platforms. For example, Intuit offers SDKs to developers working with some of the most popular server-side development platforms; .NET, Java, PHP, NodeJS, Ruby, and Python. Whereas SDKs will help in courting external developers, they are typically less useful for the purpose of attracting internal developers since internal developers already have their remit to use the APIs. Internal developers are also more likely to work directly with APIs as opposed to going through SDKs. For this reason, we are showing how SDKs,and other developer tooling would appear in the ecosystem where they are most likely consumed by third party applications and the developers who build them.
As you can see, the Intuit ecosystem and Barnett's idea of the Quickbooks business-as-a-platform (BaaP) is beginning to take shape. Here, in the next figure, you can visualize how the concept of a BaaP groups public and private APIs with Intuit's core capabilities and competencies in a way that shows the business as a platform as a part of the larger ecosystem.
The point of the previous figure is to demonstrate where the concept of the business as a platform fits in with the bird's-eye view of an organization's ecosystem. Later in this ecosystem teardown, you'll see where the concept of an application network also fits into that bird's-eye view.
Moving on to the external part of the ecosystem (the upper hemisphere), it's time to reveal the external consumers of the platform (the APIs, SDKs, and any other developer tooling).
When looking to map an ecosystem the way we have in these diagrams, it's important to note that no two ecosystems are the same. Whereas the upper hemisphere of Intuit's ecosystem is divided into three primary pie slices, your ecosystem may involve only one. Or two. Or five. Much the same way the lower hemisphere of the ecosystem is exposed to a constituency involving developers (internal developers to be exact), the upper hemisphere of our model involves the exposure of the platform to one or more external developer constituencies. Each of these external constituencies was deliberately selected by the ecosystem host for their unique potential to co-create value for the organization and its customers.
According to the IT research firm Gartner, API's "enable new digital products and business models for services, and create new business channels. APIs make digital business work." As you will soon see, the ultimate value that each constituency drives can be underpinned by a different business models; further evidence of how a single, central BaaP that simultaneously drives multiple constituencies holds the potential for manifold business models, channels of revenue, and ultimately offerings to customers.
In the case of Intuit, one of it's three external constituencies involves a special set of external partners like Google that are courted and cared for by Intuit's business development team. These are special partners with whom the business development team negotiates exclusive business terms in a way that the co-creation of value is mutually beneficial to all parties; Intuit, the partners, and the customers. Regardless of the constituency, this kind of mutual beneficialism is absolutely critical for any ecosystem to succeed. There must be substantial upside (or at least the potential for upside) in your various business models in order to attract vibrant and productive developer constituencies.
Another constituency that has access to the external side of Intuit's BaaP (on very different business terms than the first) are third party developers, ISVs, and the organizations themselves who build bespoke turnkey applications based on Intuit's APIs. For example, the ability to automatically journal certain credit card charges as business expenses. Those charges could be part of a custom automated workflow that ties into an organization's procurement process, but that ends with the journaling of the expense as a Quickbook entry. Such a workflow could be very specific to the organization and so the organization will look to its own internal developers to build that process — consuming whatever APIs (Intuit's included) in the process — or it might engage a third-party custom software development consultancy to code the workflow.
In either case, this middle slice of the upper hemisphere to Intuit's ecosystem was established to cater to developers and projects that apply to a very limited set of customers. In other words, these are organization-specific integrations that are unlikely to appeal to the broader market. Whether the customer organization is engaging Intuit's API's directly or through a third-party as a proxy for the organization, this is a very unique channel and business model when compared to the other channels through which value is co-created.
The third slice of the upper hemisphere of Intuit's ecosystem is still yet another business channel involving an entirely different business model that includes a marketplace.
When it comes to the API economy and an API-driven ecosystem, there's no single definition for the phrase "marketplace." While we won't be delving into all the different types of API marketplaces in this article, we can use the Intuit example to discuss the app store style marketplace (which is the type of marketplace that Intuit employs as part of its ecosystem).
The most basic version of an app store-style marketplace involves a showcase of turnkey applications, services, and other "bolt-ons" that the API provider's customers can browse and acquire to enhance and extend their implementations of the API provider's core offering (eg: Quickbooks). Such showcases are usually low-touch. In other words, for an app developer to have their application featured in the showcase involves minimal interaction with the API provider (other than to have their application listed) and the API provider's customers deal directly with the developers of the listed applications.
One of the most sophisticated versions of an app store is a much higher-touch marketplace that involves an ecommerce model whereby applications are literally purchased through the app store (just like with the Apple App Store). In this version, the API provider takes and processes orders, accepts payment, and then, based on whatever business model or terms the "tenants" agreed to, passes some or all of the collected funds to the application developer. As can be imagined, this sort of marketplace involves significantly more effort than a basic showcase.
Intuit's marketplace — a feature of the third slice of the upper hemisphere of the Quickbooks ecosystem — falls in the middle of the two aforementioned extremes. Unlike with a basic showcase, applications go through an Intuit-led review process before they can be listed. According to Barnett, applications must pass Intuit's security and quality requirements before qualifying for promotion in the marketplace.
Compared to the center slice of the upper hemisphere where some third party software developers operate with far less scrutiny because of the bespoke nature of their work, the marketplace involves a significantly higher bar that involves independent software vendors (ISVs) and packaged, turnkey apps with broader market appeal. In order to attract these marketplace ISVs to the Quickbooks ecosystem, Intuit business model choice was to not take a percentage of the proceeds when ISVs transact directly with Intuit's customers.
In Intuit's case, the marketplace is available as a tab through the Quickbooks user interface (as shown below) and also through an independent domain — apps.com — that Inuit operates independently of the Quickbooks.com domain.
The importance of this marketplace is not to be underestimated in terms of how it amounts to a separate business channel that drives additional bottom line value for Intuit. Two examples of how this works are as follows:
- A potential customer that doesn't yet use Quickbooks sees promise in the core offering but requires functionality that's not offered by Intuit. Knowing that there's a marketplace chock-full of add-on solutions at apps.com, the customer not only discovers how that functionality can be bolted-on through a third party offering, it also notices some unexpected alignment between some of the marketplace offerings and its existing IT estate. That customer moves forward with its deployment of Quickbooks because of the breadth of ISVs that Intuit attracted to its ecosystem and the confidence that its needs will be met. Without these marketplace elements, the prospect might not have moved forward with the deployment, representing a lost opportunity (and revenue) to Intuit.
- As Intuit customers engage with a marketplace ISV to extend their Quickbooks deployments, the likelihood of their attrition is greatly reduced. According to Barnett, QuickBooks customers using one or more third party add-ons are 14% more likely to renew their subscription than customers that don't use any add-ons. This in turn improved the long term value (LTV) of those customers; a closely watched metric at Intuit.
There is one exception to the rule whereby Intuit does not get a cut of the transaction between its customers and marketplace ISVs; when an authorized reseller is involved in the deployment. Because of the financial nature of Quickbooks, these resellers are invariably accountants that have amassed significant Quickbook expertise.
In our ecosystem visualization below, these accountants occupy the "wedge" sitting on the right edge of the ecosystem (shown below).
The size of the wedge — stretching from the upper to lower hemisphere of the ecosystem — is very deliberate. It demonstrates how, as solution consultants and resellers, accountants might on one hand recommend a deployment that's based only on Intuit developed applications (the dark purple stripe in the lower hemisphere) or, on the other hand, a deployment that also involves bolt-on solutions found in the marketplace.
When accountants are involved as resellers in the deployment, the business model shifts to one based on revenue sharing. "Accountants have the ability to resell third party apps that are integrated into the platform and present a single bill to the customer" said Barnett. "In this case, we do a revenue share with the accountant and the developer."
Now that we've documented all of the ecosystem's primary constituencies and their role (the applications) in co-creating new and exciting end-to-end customer experiences, we can visualize where the idea of the application network fits in. As shown below in the two-tone blue area, it's essentially inclusive of API-led business-as-a-platform, the tooling that goes with it (the SDKs, etc.), any marketplace technologies that aid in procurement of specific customer experiences, and of course, the applications themselves (the ones that are enabled by the underlying platform, APIs, and marketplace).
Up until this point of the article, we've been using ProgrammableWeb's approach to ecosystem visualization to help you understand how the various entities within an ecosystem can logically and organizationally hang together. While our visualizations include some elements that should appear in every ecosystem (ie: a central platform of core capabilities and competencies and the private and/or public APIs that go with them, the application layer, the developer layer, and the customers), it's important to realize that the internal layout of your ecosystem is likely to be different. You should take whatever liberties are necessary should you decide to adapt our template to create your own visualizations. More importantly, we've been saving the best part for last.
Throughout this ecosystem teardown, this article has commented on how the different slices of an ecosystem pie amount to different channels through which customers reach the API provider's core offerings (driven by their core competencies and capabilities). In Intuit's case for example, some customers may only engage Intuit directly through the Quickbooks-developed user experience to meet their basic accounting needs. Other customers may have engaged a third party developer for a bespoke application (or may have relied on their own developers) that takes advantage of Intuit's publicly available APIs. Still other developers might be leveraging an accountant that's certified by Intuit to resell Quickbooks as a solution.
Each of these "approaches" to the Quickbooks capabilities, shown in the last "build" of our ecosystem visualization below, represents a different channel that was ultimately enabled by Intuit's central API-led business-as-a-platform.
These channels demonstrate how a central, reusable API-led platform can yield incremental business and revenue opportunities without significant change to the underlying cost basis. Each of these channels can involve different customers, different co-creators of value, different business models (eg: the accountant-based channel vs. the non accountant-based channel) and ultimately different customer experiences in ways that expand both the organization's target market and the organization's overall revenue potential.