A playbook for API-first transformation at scale- The key building blocks
The Age of APIs
These days, the competition is so intense. The differences between a big established company with decades of experience in an area vs a new age start-up in the same area is blurring every day. The start-ups are coming up with very matured and innovative products that solve business problems more efficiently, available omnichannel, across all types of devices that people at all ages use, right from the very first product release. These start-ups are disrupting in every area, challenging established players, drawing away the users into their platforms, driving away the revenues and establishing themselves as the new leaders in that industry segment very quickly. Business leaders these days are under tremendous amount of pressure to ensure that the developers at their companies are innovating and delivering differentiating product features at speed to delight the customers (Note- Delight, not just meet. The days of MVP products seem to be over). So, whether you are a very well-established company or a late-stage start-up, breaking the monolith to microservices is the new mantra to ensure focus and creation of independent teams to innovate and deliver at speed. APIs are how a microservice exposes its features to its clients.
That’s not the only thing. In this new era, with the explosion of apps, consumers are spoiled with choices and are demanding more, for example, consumer behavior is shifting more towards using apps that can help them do many things to take care of their everyday needs- the age of super apps. Companies partner with many service providers to provide all these value-added services (that are not their core competencies) to drive more user engagement (which in turn translates to revenues), APIs have become the default integration mode between the service provider and the platform provider. Not having an API is a competitive disadvantage and a blocker.
Finally, many companies are trying to digitize their software assets. Whether to digitize the wealth of customer data and behavior a company has learned/accumulated over years by virtue of doing business or to unlock the value of its core assets that are key differentiators, APIs have become the default medium for digitization. With the recent pandemic (which is not yet over), the need for digitization has further accelerated by 5 years (if not more)- being digital is not a good-to-have feature anymore, it’s a requirement for survival. This is the era of digital platforms and APIs are fundamental and key to the success of digital platforms.
Every company needs to have a clear API strategy even to survive. And to remain competitive, every company should adopt an API-first approach. It is now become such a non-trivial thing.
API-first transformation, the key building blocks
So how do you enable or facilitate API-first transformation in a company. The chances that you succeed or probably the only way to succeed is by treating the transformation itself as a product for your company’s internal stakeholders.
The following can be used as a blueprint for a driving API-first transformation in an organization. Your API platform that drives the API-first transformation, would have the following key building blocks
The business capability model that describes the entire suite of business capabilities composing your business. The business capability model defines the problem space for every API an organization would build (each API is essentially an implementation of a business capability aka a business capability interface). When done well, it drives everything in your transformation product. For example, it enables customer centric discoverability of APIs via the business capabilities. It can be used to discuss solutions with all types of stakeholders (executives, business owners, product owners, engineers etc), in the organization. It decreases time to market (via reusability of capabilities, helps tracking investments (detect duplication/overlapping), lay out clear ownership for teams, and measure success via the common set of business KPIs across all teams.
The business domain vocabulary- a definition of all the entities in a business domain. The vocabulary should be defined for all the business domains. A well-defined vocabulary drives consistency (and uniformity) across APIs and removes subjectivity.
Both the business capability model and the business domain vocabulary should be well managed (mostly by a domain product owner together with the domain architect) and discoverable via the API discovery tool. Both are fundamental to the success of an API-first transformation. Over the time, they become very stable and require very little incremental changes.
The API architectural standards- The standards that define every aspect of API design, styling, API protocol semantics, API versioning, various communication patterns and API security. Check PayPal’s API standards for reference if you are unsure about how to define this.
The API product development lifecycle (aka API PDLC)- A well-defined API Product development Lifecycle that describes how you take an API product from concept to launch, and then operate, with clear definition of various lifecycle phases, stakeholders for each phase and the required contributions/artifacts from them. The API PDLC also defines an API maturity model that outlines the entry/exit criteria for each lifecycle phase and measures the API quality that stakeholders use to track their overall API portfolio health/investments, for the business capabilities they own.
The API Infrastructure and Tooling (The most ignored item of all)- The tooling ecosystem that enables self-service of the API platform for different API stakeholders. Organizations usually develop the API developer portal and ignore all other critical pieces of tooling that are required at each phase of the API PDLC. Every guideline, pattern in your API standards MUST have the equivalent tooling to help towards adoption. There MUST also be sensible tooling defaults for everything. When done well, they significantly reduce overhead, increase developer productivity and time to market. You can even treat the API infrastructure tooling as a developer productivity platform product. With sensible tooling defaults for every API standards item (and in most used language stacks in your company), you could also reduce any drag caused by microservices teams implementing on their own (as most teams would like to instead use available tools than developing of their own). More about this exhaustive developer tooling blueprint in a separate post.
Developer Advocacy, schema design consulting, training & education-All these areas require special focus. A central team of experts providing schema design consulting on demand (almost all teams require schema design guidance during an API PDLC). A dedicated evangelist (or a team of evangelists) engaging with the API platform customers and collecting their experience/feedback around the usage of the platform and using the information to evolve the platform, creating training and education content at each stakeholder level (note: at each level) that is appropriate for each type of audience, and continuously evangelizing every API platform feature with all the customers.
In conclusion, driving API-first transformation in an organization requires a clear strategy, product thinking and continuous investment. Leadership should be committed and provide right incentives and levers to encourage this behavioral adoption. API-first transformation is a journey, not a one-off project, when it gets embedded in an organization’s culture, it helps the organization to innovate, stay ahead of competition and deliver differentiated product features day after day.
This article is the first of seven that explores the API-first transformation playbook in detail. In the next article, we’ll explore on how to build an API platform team that would drive the successful API-first transformation, the various stakeholders and their roles and responsibilities.