API Program Growing Pains: Three Best Practices

In over half a decade working with customers on their APIs programs, I’ve observed a number of patterns when enterprises attempt to scale up their efforts.

Most API programs scale through federation; the program builds APIs in order to create a technology platform that makes the business’s proprietary data and functionality easier for application developers to consume and leverage. As new teams connect to and contribute to the program, it grows.

In contrast to legacy application models in which large development teams work on complex projects in slow-moving groups, API programs generally assume numerous, fast-moving teams whose efforts can be cross-functionally leveraged via common interfaces and programs — that is, via APIs.

Traditionally, an enterprise with siloed development teams might have needlessly duplicated APIs, such as those for connecting to a customer database, through bespoke projects that lacked visibility into one another — and even if there was some degree of visibility, APIs developed by one team might not be easy for developers on another team to use. Today’s successful API programs offer solutions to these challenges by making APIs consistent and easy to access via a technology platform that lets the enterprise maintain and manage APIs and underlying assets. Elements of such a platform range from resources that let developers discover, access and learn about APIs to the processes that govern creation of APIs and the systems and functionality they expose.

These governance and API creation processes can be particularly complex. Whereas some aspects of an API program, such as launching a developer portal to facilitate managed API access, may be relatively straightforward, the organisational, operational, and cultural challenges that allow a program to scale can be numerous and daunting.

As an organisation moves from a small initial team producing APIs to dozens, or if the organisation is looking to federate at scale from the start, it’s important, as this article will explore, to have a lightweight governance structure in place. The group shaping and applying this governance has been called many things — Centre of Excellence (CoE), Community of Practice (CoP), Guild, Tribe — but whatever it’s named, it typically plays an important role in the application of common rules and processes across the API program.

In my experience, the following three principles — scalable growth, funding, and simplicity — have helped businesses around the globe scale their API programs.

Scalable Growth

Rules and processes can’t take a back seat to enthusiasm for growth. Growth is great and something every API program strives for as it seeks to maximise the value of the enterprise’s digital estate. But growth can be disruptive to the status quo. In many organisations, the API program’s success may rely on changing incentives and operating models with which much of the workforce is already comfortable. Without some explicit guidelines, advocates, and enforcers, it can be messy — which is why a cross-functional API CoE (or whatever an organisation decides to call it) is often so important. I’ve found it useful to think about filling CoE roles in terms of “police,” “teachers,” and “referees.”

“Police”: leadership, enforcement, and automation

Rules should take the form of a small common set of standards that all teams producing APIs abide by, such as a consistent approach to security, logging, and customer journey tracking. Though leaders in the organisation will have to establish rules and standards, API management platforms can shoulder much of the enforcement duties by letting businesses implement these common standards by, for example, enabling a policy or group of policies to be automatically applied to all APIs.

This kind of automation is key to keeping the overhead manageable. It’s also important for API CoE leaders to pick their battles; if everything becomes an enforcement or standards conversation, the cost of governing the platform, in terms of both time and money, may limit feature velocity. The goal should be governance with a small “g,” not to stunt enthusiasm by locking down systems or mandating laborious or arbitrary standards. It is important to make APIs accessible and to encourage developers to experiment with them and leverage them, but it is also important to control who is accessing APIs and what they’re allowed to do with them, and to monitor and analyse API traffic for insights or signs of abuse.

“Teach”: best practices and community

The core of an API program is a technology platform — the collection of APIs and related infrastructure that can be accessed and consumed in a reliable, consistent, user-friendly way. To scale such a platform, a business needs to enable new teams to use it. In addition to the policy enforcement efforts described above, successful API programs typically define best practices and principles to guide new teams and help them to share learnings.

Principles differ from standards; whereas the latter is a rule to be enforced, the former provides a guiding framework. Many organisations, for example, make it a standard that all APIs are deployed using a CI/CD pipeline but allow different tools to be used according to individual teams’ preferences.

It may also be important for the API program to dedicate resources to an API evangelist who helps teams understand and leverage the API platform’s value.

“Referee”: mediating disagreements

Not everyone is going to agree. Technologists can have deeply held views on certain topics — if you thought the “tabs versus spaces” bit from Silicon Valley was intense, just wait until you hear an argument about API versioning. To be successful, API governance should involve representatives across different teams that create or rely on APIs, with the goal of driving decisions even when there are differing views. Getting buy-in from stakeholders is important if the API program is to be seen as an effective decision-making body, rather than an ivory tower. In many successful API programs, consistency and a bias toward action help to iron out disagreements. If the C-suite understands the value of the API program and mandates participation, it can powerfully stimulate adoption and growth, including by helping to align IT stakeholders and business stakeholders.

Funding

A technology platform is not a project that gets approved and completed — it’s a living and evolving set of technical infrastructure and resources that needs to be continually nurtured, improved, and managed.

API programs need financial backing to achieve this state of perpetual improvement. The technology platform on which the program relies will struggle to grow if it is constantly constrained by funding cycles or by churn as contributors, and their knowledge, jump on and off projects. Successful API platform funding models eschew project-based thinking and instead generally focus on annual or multi-year funding cycles to promote longer-term planning.

It can be extremely challenging to align stakeholders around these longer cycles, so the API program’s governance body may need to develop new metrics and incentives to drive cohesion among teams and establish a shared definition of the value the API program provides. Rather than focusing on the number of APIs produced, for example, an organisation might align teams around the API program and the funding it requires by focusing on which APIs are generating the highest adoption and reuse from developers. Likewise, rather than focusing on whether a newly introduced API is immediately producing revenue, an organisation might focus on how the API is being leveraged for new use cases that may introduce the business to new customers. That new metrics may need to be established and adopted reinforces the importance of a diverse group of stakeholders within the API CoE, including both business and technical leaders.

In my experience, a “maintain, grow, react” framework is useful for assessing the various needs the API program’s funding will need to serve and aligning stakeholders around them.

Maintain

What is the minimum required to keep the lights on? Starting points include the costs of the licencing for the technology platform or, if the organisation is adopting a homegrown solution rather than software-as-a-service, the cost of the infrastructure underlying the API program. Support for developers creating and consuming APIs is another core factor.

Grow

Maintaining a program is a starting point, but to really understand the total cost and opportunity of an API program, an organisation has to factor in growth. As mentioned, the ability of the API program to add new teams is critical — and if the funding model does not anticipate as much, the program is likely to stall. For example, is there funding and operational flexibility to insert someone from the API program into a new team for a month as that team gets started? Have standards and principles been established to enable manageable growth and help the company get the most from its investments? Other factors include funding for evangelists who can help the program spread to new participants.

React

Launching an API program is in many ways an exercise in evolving business models; APIs let developers leverage important data and functionality for new use cases, which can sometimes insert the organisation into new contexts or make its services accessible to more customers. A service that once was used for mapping may become the backbone of a ridesharing service, for example, or a service that once required a dedicated mobile application, such as sending money to a friend, might become accessible within a messaging or social media experience. These new growth opportunities may open unexpectedly — which reinforces both that API programs need metrics oriented around API traffic, which can indicate which APIs are taking off in new areas, and that API programs need the funding flexibility to allocate resources as opportunities arise.

Simplicity

Keeping the enterprise’s approach to APIs transparent and easy to understand is key. If an API consumer or developer can’t see the forest for the trees, they’re unlikely to help the organisation create value.

It is important that the teams creating APIs understand the needs and goals of the developers who will consume those APIs — that is, APIs should be produced and managed as products. API developers should adopt an outside-in perspective that uses traffic patterns and direct feedback from API consumers to inform product roadmaps and iterative improvements.

Even so, not all APIs will be equally valuable. All APIs express a part of the business and thus represent strategic optionality that should be managed — but APIs for API developers might be managed differently than APIs for API consumers, and APIs intended for a broad audience might be managed differently than those developed for a specific partner. I’ve observed many organisations find it helpful to use the following categorisations:

Domain APIs

Domain APIs typically sit atop systems of record and are focused on exposing data from those systems for API developers to consume. These APIs are not intended for application developers building experiences for end users but are often a starting point in the process of building APIs for those developers. For example, an enterprise might expose a SOAP service as a pass-through proxy to enable other APIs to consume it. Such APIs are often made accessible through a developer portal, just as APIs for application developers would be — but the portal restricts access to only an API developer audience.

Strategic APIs

These are the gold-standard APIs that follow all the API program’s standards and best practices and serve as exemplars for teams building APIs. Strategic APIs are generally front and centre on an enterprise’s developer portal and present the business’s value proposition to application developers, whether internal or external.

Experience APIs

Experience APIs are required for niche use cases, such as if an important partner requires an API that conforms to specific standards. Like domain APIs, access to these APIs is typically tightly managed. Experience APIs generally orchestrate a number of strategic APIs or may be a fork from an existing strategic API. It’s important that these kind of bespoke APIs don’t proliferate. The teams that produce APIs should possess a strong sense of product ownership in order to effectively assess whether a use case truly requires an experience API or would be better served by a strategic API.

Remember: Scalable Growth, Funding, and Simplicity

There’s a lot to consider when either starting off on an API program or scaling up an existing program, but focusing on three key areas can help drive growth:

• A clearly defined set of core standards and values backed up by a cross-functional governance body and robust, value-based prioritisation by API product owners
• Funding that is not tied to business cases or funding cycles, but that instead frees up the API program’s participants to make value-based decisions, react to new opportunities, and develop best practices
• A simple, well-understood approach to APIs as products and how different developers interact with them

[Looking to learn more about managing and deriving value from APIs? Check out our ebook series “Inside the API Product Mindset.”]