From conception to consumption: The API delivery process (Part 1)
Once an organization has decided to expose its services and functions as an API product, special attention needs to be given to all the aspects of the API delivery process. This comprises clearly specifying the problem that the API will solve, the value provided by the API to solve that problem, the set of stakeholders involved in the process, the API’s MVP and time to market, and the API’s quality and security standards. This is the first in a series of posts aimed at covering all these aspects.
API value
The main reason behind any API is the value that it provides. Be it data (raw or processed), functions or services, or a combination of both, the value provided by the API is what guarantees its success or lack thereof. Therefore, it is of paramount importance that enough time and effort is invested in finding what makes an API product useful and unique in terms of the value provided to its consumers. One of the biggest mistakes companies make when offering their unique data and services is that they are exposed directly as APIs without taking into consideration the consumers' needs.
A great way to avoid this mistake is to formally verbalize the problem or problems that will be addressed by the APIs being offered. Note that this does not necessarily correlate to a single specific data or service provided by the company but rather to a combination of those in a very unique way that is totally consumer-centered.
Finally, once the problem has been completely identified, a specific solution must be proposed, designed and implemented. Once again, this is usually carried out by combining the services provided by the company in a way that is useful and specifically tailored for the API consumers.
Product’s stakeholders
The proposal of the solution provided by an API must take into account all the stakeholders involved in the process. These can be generally classified into management or decision-makers, developers building and consuming the API, and application users. In general terms, the decision-makers are the ones that are in charge of deciding whether an API should be adopted to improve or expand operations and services in their respective companies. Builders and consumers represent the technical staff that is in charge of building and consuming/interacting the API respectively. Finally, application users represent the users of the applications built on top of the API.
The solution proposal must explicitly and clearly present the problem the API is trying to solve and its solution in the form of value provided by the API. This should be done so that the people in charge of deciding whether to use, buy, or subscribe to the API can make a well-informed decision.
From a strictly technical point of view, an API lifecycle has software developers on both ends of the spectrum: the ones who build it and the ones who consume it. In particular, developers building the API need to have access to all the details involving its design, implementation, testing, and operation. This cannot be emphasized too much as the API builders need to capture the original API’s vision in every software artifact they create. Similarly, the API needs to be conceived, designed, and implemented with the developers consuming the API always in mind. Every decision made, major or not, needs to consider and assess how it is going to affect the way consumers interact with the final product.
Last but not least, the application users need to be given an important role within the design, implementation and testing processes. The main aspects that need to be considered for them are quality of service and security. No matter how usable and useful an API is for its consumers, an API is useless if it puts the security of the app users and their assets at risk or it does not comply with minimum quality standards.
Reduced Time To Market and Minimum Viable Product
The value of an API is also a function of its relevance. In other words, the sooner it can make it to the market, the more benefits the company can reap from being a pioneer. This translates into a bigger consumer base and therefore more revenue. However, this is easier said than done. More often than not, companies get lost in the intricacies of preliminary design, market analysis, monetization strategy, etc. All these aspects, although important, cannot and should not become roadblocks and isolated goals. In fact, they are just beautiful philosophy until real feedback from real consumers and users is acquired.
All of the above highlights the importance of reducing the API’s time to market and building a minimum viable product (MVP) as soon as possible. An MVP will serve as a baseline from which all the future features and services will be built. Also, an MVP is the best channel to get vital feedback which in turn can be used to evolve current features and services.
A special effort needs to be invested in order to reduce time to market. For this, all the company areas need to be involved in the API lifecycle in order to prevent any gaps in the final product. In addition, all the areas and the company as a unit need to set clear revenue goals related to the API product. This can become a great incentive to push all the teams within the company to collaborate and support the API lifecycle. Similarly, the API lifecycle needs to be supported by well-defined workflows and communication channels among all the areas in the company in order to prevent downtime and miscommunication.
Finally, the API lifecycle should also be supported by an automated development process. This process should facilitate the implementation of new features, the monitoring of existing ones, and the retrieval of user feedback. A great example of this is the set of API platforms offered by all the incumbents.
Conclusion
This post briefly covered the first three aspects of the API delivery process. The decision made by an organization to expose its services as an API product is only the beginning of a process in which establishing the value of the API and its ability to solve a specific user’s problem becomes the cornerstone of the entire API lifecycle. Once a problem has been identified and its API solution established, it is necessary to identify all the process stakeholders in order to have them guide the design and implementation of the final product. Finally, in order to materialize the solution offered by the API and to acquire user feedback, it is necessary to identify what is the API’s minimum viable product and to identify ways to reduce its time to market.
In the next post, the quality and security aspects of the API delivery process will be analyzed in order to identify their design, implementation, monitoring and the consequences of not having them be an essential part of the entire API delivery process.