APIs Are Products

By Bernardo Perez de Lara/CEO Near BPO

APIs (Application Programming Interface) enable a software program to use the services of another software program, serving as a systems interconnection technology. According to the responses of a Google Cloud survey in 2018, 57% of business leaders characterize APIs as systems integration technology, but in reality APIs are much more.

APIs are the software facade for an enterprise. It is how developers can make use of data, services and business applications to create new products and services, allowing them to become part of new solutions in addition to providing new services to their customers in a fast way.

When viewed as products, APIs are the foundation that enables the creation of relevant user experiences, expanding what in the beginning was perceived as a TI technical detail into an enterprise asset for an ecosystem that is the key to sustained growth in today’s and tomorrow’s economy.

Given that APIs are products, they have to be designed and created to provide value in the long term. From their blueprint to their implementation, API teams have to take into consideration that their use can grow exponentially and that they will have to evolve over time to adapt to the changing customer’s needs. Once API designers operate with the mindset that they are creating products, they prioritize the ease of consumption without sacrificing security, with the intent for these APIs to provide strategic value and extensibility in the future.

Designing APIs as products creates a challenge for organizations that are used to deploy APIs within projects. The main issues that arise are:

• The creator typically does not give due importance to the documentation
• There is no consistency following business design standards
• Lack of version management
• Enforcing corporate wide security protocols
• No self-service developer portal

These and other relevant factors inhibit the future use and extensibility of APIs when not developed with a product mindset.

For example, within a “payroll” project, a developer can place an undocumented data element in the payload of an API called “date” which is actually the day the employee was hired. It is possible that this naming convention has made sense within the project environment, but given the lack of documentation and lack of adoption of data field naming conventions, it is very likely that an outsider who wants to use this API in the future will be confused and will make a mistake when using it.

The tendency of organizations to create APIs within projects is usually a vestige of the way they worked on monolithic “legacy” applications, when the emphasis was on tying up all aspects of design from the initial phase. The recipe for success in modern companies is agile adaptation of decoupled architectures that grow in scale. This by design allows even the largest companies to respond quickly to the needs of internal and external developers.

Think of how architects design buildings so that it’s easy to identify parking lots, the main entrance, the security modules, and adapt the corridors and elevators to the expected flow of visitors and residents. In the same way, API products have to be designed consistently so that developers can consume them easily. In order to start your digital transformation on the best path:

• Creation, modification, deployment and debugging of your APIs should be very simple
• Your API team has to clearly understand how to address security concerns, such as OAuth protection
• They have to consider how to dynamically and economically scale functionality
• Provide high availability and reliability of the APIs, enabling multi-cloud deployments
• The documentation aspects and the availability of a testing environment.

Your API management platform has to easily support these features.

Re-use is the focus for both SOA (Service-Oriented Architecture) services and APIs that are replacing them. SOA applications tried to anticipate the future and became very large and complex. For this reason, for APIs to be successful they must be simple, clear and easy to evolve in versions more suitable for the customer’s needs.

Since APIs are products, they have to be handled by a Product Manager, who is the owner of the product, understands the requirements of their customers and is responsible for translating them into product requirements and fast delivery iterations, starting with the MVP (Minimum Viable Product) and plotting the way forward to have a complete product given the customers’ current needs. It is important to differentiate between the Product Manager who is aligned with the business leaders and technical leaders in the API program objectives, and the Project Manager, whose responsibility is to deliver results based on a list of requirements.

In order to base the API’s evolution on real data, it is very important to define the Key Performance Indicators (KPIs) of the business impact of these APIs and to have an API management tool that can tell you who is using your data and how this data is being used. Thanks to this knowledge, it is going to be easier to comply with Service Level Agreements (SLAs), and also, derive perceptive knowledge (insights) so that the next version of the product is better suited to the needs of the clients or guides us to generate new products and assure us that the product is meeting the needs of customers.