In a shift that seems to be accelerating for scaled enterprises, developer portals and public API programs are becoming more commonplace these days. In our day-to-day work with customers around the globe, public API programs, and developer portals are rapidly becoming the norm rather than the exception. While this shift in posture is becoming more frequent, we still see a few common pitfalls that not every organization understands.
5 public API program mistakes
As business and IT teams collaborate to stand up a public API initiative, a set of all-to-common gotchas can inject friction into your organization’s API ecosystem journey. The good news here is that these pitfalls can be avoided with a few small course corrections. The even-better news is that the best practice tips below will also serve to significantly accelerate your initiative and the ultimate time-to-value for your enterprise.
1. We’re not ready for external access
A fairly frequent refrain from both IT and business teams when asked about their plans for a public API program or a monetization initiative is along the lines of “We’re not ready for that”. As you dig a bit deeper, a frame of mind is revealed where people believe that a level of maturity must be obtained before considering the possibility of a public API offering.
While it’s clearly true that enabling external parties to interact with you over an API channel requires a level of maturity (especially in the governance and security spaces), what’s not spoken about here is where that level of maturity will come from. The problem with the “we’re not ready” mindset is that it fails to acknowledge a fundamental truth of enterprise business readiness. Rather than “revenue follows maturity”, enterprise teams need to understand that “maturity follows revenue”.
Ask any enterprise team member anywhere in the world about how well their internal teams adopt and utilize proven methodologies and technologies for internal optimization. You’re likely to hear them launch into a tirade about the cobbler’s children having no shoes or not having the commitment to eat their own dog food. What’s going on behind these aphorisms and corporate jargon is the labyrinthian process of weighing opportunity costs and then prioritizing where to commit resources.
The catch-22 of the “we’re not ready” mindset is that “readiness” is much more a function of necessity and not as much about choice. An easy way to see how this plays out is to ask yourself what factors in your organization drive investment in maturity or readiness. Does investment and support come from planned improvement strategies, or does investment and support come from initiatives that involve revenue and customer impact?
The best practice to adhere to isn’t “Open up everything right away!” Instead what we’re advocating for is to leverage business objectives (like customer impact and revenue generation) as a means to drive the maturity of your capabilities and organization. Rather than shutting down the possibilities of a public API offering out of hand by saying “we’re not ready yet,” enterprises should take the opportunities for investment and support that come along with the initiatives that drive business outcomes; i.e., if they’re coming, you should build it.
2. Launching public APIs without any governance
One specific pitfall that we see organizations fall into comes when technology teams build a sample developer portal devoid of any usage constraints or governance controls. The rationale we hear from teams who follow this path is that business teams need to see working examples of what a portal could look like in order to provide any substantive input. For enterprises that are still feeling their way through the implementation of digital transformation, getting business and technology alignment on a public API initiative can be a chicken-egg problem.
The business teams aren’t fluent enough in either the business possibilities or the potential issues to have any constructive input and the IT teams don’t have a way of educating their counterparts without making an offering on their own. What IT teams often miss in planning a proof-of-concept (PoC) initiative to help business teams gauge the potential value of a public API initiative is that launching public APIs without any governance can introduce several new risks that span both the business and technology lanes.
The two most notable of these risks are that your external consumers may:
- Build their own product or service offerings on top of your infrastructure without providing you any value in exchange for your service (or quite possibly cannibalizing the value and audience of your offerings)
- Become accustomed to getting full and unfettered access to your offering as a free service that they should never have to pay for.
There are several options, that don’t require an extensive amount of business team guidance, for how to protect your organization from unwarranted risk here. When looking at the options below, please note that they’re meant to be independent options that can be combined to help your organization manage the risks based upon your context:
- Identify and audit the access of ALL of your public APIs (and if you think you don’t have any public APIs, think again)
- Start an initiative to adopt a zero-trust model for APIs with specific goals to move away from allowing anonymous access to APIs
- Apply rate limits and throttling to all of your public APIs
- Start to educate your business teams via examples of other enterprises who have API based offerings and look to use “freemium” offerings (which by definition include basic usage constraints and governance) as a means to establish proof of demand.
3. Confusing public APIs with open APIs
Separate from the dilemma where an organization is in the dark on the existence of a public API offering that powers their web and mobile applications, another issue we’ve seen is the tendency to conflate a public API offering with an open API offering. Most organizations – and even most published content online – equate public and open with each other and don’t see any difference between them.
The biggest difference between public and open API offerings is the level of access control you require, which can range from private APIs that are restricted to consumers from inside the organization to open APIs that can be used by anyone and don’t have any authentication requirements at all. Public APIs sit in the middle of these two models as shown below:
Despite the simple continuum diagram above, there is some degree of overlap between public and open APIs. In short, all open APIs are public APIs but not all public APIs are open.
When teams don’t see any distinction between open and public, an unfortunate consequence is likely to come about where teams default to the lowest common denominator and don’t require any authentication for API consumers. Open APIs have their purposes, and we’re not claiming that these goals are bad. The things to understand regarding an open API program are:
- Open APIs are much more susceptible to DOS and DDOS attacks than public APIs.
- Open APIs dramatically limit future attempts to monetize your API offerings given that it can be difficult to get people to pay for something they’re accustomed to getting for free.
4. Lack of business ownership
An all too often mistake we see in public API initiatives is a lack of business engagement and ownership. This issue often stems from a lack of familiarity and comfort with API product concepts. Most business and design team members have never directly engaged with an API and the only frame of reference they might have is using an application that invisibly consumes APIs.
This lack of contextual grounding, combined with an already full plate of existing business concerns, often drives an attitude of “let the IT team manage the IT stuff; I’m not sure what the relevancy is, and I’m not sure I have much to contribute here anyway.”
A lack of engaged ownership can show up in a variety of ways:
- Limited engagement in concept ideation: Without thoughtful business input, public API offerings are likely to be poor fits to customer needs or even harmful to the interests of the enterprise (e.g. cannibalistic offerings, ungoverned free-for-alls that limit future revenue opportunities, etc.)
- Limited engagement in product marketing collaboration: Without engagement from marketing teams, a public API offering can be akin to the sound of one hand clapping. IT teams may know basic SEO concepts and the motivations of developers, but they’re not experts in developer marketing, paid media, how to package offerings for adoption, or how to influence buyers with budget.
- Limited engagement in service design and product operations: Without representation from operational leadership, the capacity to solve even the most trivial customer issues (e.g. onboarding, credential management, billing questions, SLA questions, etc.) will almost certainly fall onto the shoulders of IT.
Aside from not being versed in customer service best practices, asking your product development team to carry the operational weight of a public API program will ultimately come at the expense of future product development and other revenue opportunities.
A tactic that API leaders can use to address this concern is to make sure the business teams understand the scope of questions they need to answer. To avoid this pitfall, technical teams must extract the technical complexity from the conversation and ensure the business teams understand the importance of defining product characteristics like product value propositions, SLA policies, marketing plans, and customer service processes.
5. Rolling your own portal/infrastructure
Have you ever seen or heard of a retail store or enterprise building their own point of sale (POS) or pin pad for swiping credit cards? Of course not. Yet repeatedly, scaled enterprises of all types default to building software rather than leveraging commercial off-the-shelf software (COTS) to address the basic needs of running a value stream. One might think that an organization that is fluent enough in APIs to consider a public API offering would be aware of concepts like hyperspecialization and undifferentiated heavy lifting, but the “default to build” reflex of delivery teams is hard to break.
Of course, it might be simple to spin up a few web pages and call it done, but this type of approach doesn’t set the stage for real value generation. Would it be advisable for a scaled enterprise to take this approach for its e-commerce business?
If an enterprise attempted to roll its own e-commerce platform most anyone from IT or business domains would rightly point out that it would take years if not decades to catch up to what is considered basic, required functionality to attract, convert and retain online customers, not to mention the opportunity cost that would be incurred by dedicating your precious IT capacity to building something of questionable value.
This type of approach emerges from the attitudes and behaviors mentioned above in mistakes one and five. Aside from following the best practices advised in each of the above sections, enterprises would be wise to adopt a “default to buy” approach for all solutions that don’t specifically contribute to their differentiation strategy. A key aspect to be aware of here is that “default to buy” doesn’t mean “always buy” or “never build”. “Default to buy” means that teams must look to packaged solutions first and should be required to justify decisions that involve custom software implementations with long-term operational expenses – and often fail to meet user expectations.
Being forewarned is being forearmed
As enterprises around the world lean into composability, hyperautomation, and monetizing API ecosystems, more organizations are working on digitally enabling their offerings via a public API initiative. If this type of initiative is underway or on the horizon for you, consider MuleSoft to help you drive success. We’ll keep your team on the path and out of the ditches and ruts that inexperienced travelers often fall into. While learning from your own mistakes is good, what’s better is learning from the mistakes of others.
