My last blog post explained how two of the most used API methods — SOAP and REST — affect an organization’s ability to derive business value from APIs. And, from the standpoint of delivering value, REST is becoming the de facto standard for the modern, connected business. With few exceptions, RESTful APIs deliver the agility and continuous customer success today’s leading organizations require, and can be thought of both as products and as business assets.
Join us on Wednesday, August 5 at 10am PT for a live webinar on APIM Implementation Best Practices to learn how to implement Boomi API Gateways. Save your seat.
The API Consumer
In the world of APIs, a consumer is simply anyone who utilizes a service accessible via an API or the underlying data residing in a resource. Consumers can be external or internal — inside or outside the walls of a business.
But in either case, creating an API for a consumer requires going through a product development process that includes these phases:
- Identifying business goals
- Establishing user requirements
- Defining technical requirements
- Getting feedback and iterating
Identifying Business Goals
There are several broad business goals that APIs can serve; increased revenue, greater customer adoption, and reduced cost are three of the most obvious. This business value can be derived via the consumption of APIs directly or the consumption of applications built with the help of combination of few APIs. For example, an organization may want to provide customer service through an application which fetches its supply chain data from an underlying API. Or a hospital might want to provide an application for nurses to enter and access patient data as they make their rounds, to bring increased efficiency in their daily work routine.
Any of these use cases carry with them technical requirements for the API, in terms of types of data, size of data payloads, access to other application data, speed, and security. So, the business must first know what it wants to do. Who is going to use the API? How should features in the application or data fields in the API be prioritized? That is the beginning of adopting a product mind set for building APIs.
Establishing User Requirements
It’s easy to get pulled into a technology-first view of APIs. But before you do, ask yourself a simple question: Who and where is the user in all of this? Let’s look at a hypothetical example — nurses in a hospital.
Taking a patient’s temperature is one of the most labor-intensive tasks facing nurses. Nurses are supposed to check temperature every four hours, but, under their typically enormous workloads, twice a day is more common. Even so, temperature taking consumes a lot of time, plus there’s the error-prone manual recording of temperature information on paper and re-keying it into a patient’s electronic health record (EHR).
Nurses are constantly on the move, so they need a way to connect a tablet to a patient’s EHR to record temperature once and have it automatically populate the EHR so it’s available to doctors and other medical staff. It would also be great if the API that made this connection could automatically alert a patient’s attending physician of an abnormal temperature reading.
Whatever the purpose of the API, how the API will be used, by whom, and under what circumstances must be considered. Defining these pain points and mapping the user journey are important steps that will govern the features of an API that a potential consumer-facing application would use.
For example, in the above case it is inefficient to build an API which is optimized for concurrent users since the nurses are logging in at discrete times of the day. What is more important in this use-case is the fast propagation of event data as in when they occur for quick updates and an API that does not go down in the critical working hours of the nurses. Evaluating such differences right in the beginning of development helps reduce cost in terms of both resources used in developing the API system and to keep it operational.
Did you know Boomi API Management supports JSON Web Token (JWT) Authentication? Learn more in our Community article.
Defining Technical Requirements
After the high-level evaluation of what the API system will look like, it is time to deep-dive and define the technical requirements. Reliability, maximum transactions per second (TPS), stability, authentication mechanism, payload sizes, and latency — represent the key technical factors to keep in mind in designing a scalable API-driven application system.
This makes the importance of treating APIs as a product even more evident, because as the application development leader or enterprise architect of your organization, you need to prioritize which requirement is best suited for your consumers. You need to think of tradeoffs such as sacrificing some performance for stability or payload size for latency, or concurrency for reliability.
We recently conducted some intensive testing of Boomi API Gateway performance. See the benchmark results here.
Think of Development in Iterative Terms
One of the biggest mental shifts in thinking of APIs with a product mindset is the idea of the minimum viable product (MVP) and what that means for the API or application addressing your particular use case. At the heart of the MVP lies user feedback, which allows you to quickly assess the efficacy of the solution and make changes wherever necessary to ensure customer success. The MVP should have enough features to satisfy early customers and functionality that warrants usage in order for you to gather feedback for future versions.
Remember the idea of tradeoffs introduced earlier? Designing your MVP will incorporate those ideas and discussions and prevent you from investing in a product (API) full of features without market or consumer validation resulting in less or even negative ROI for your team and eventually your business.
One way to accelerate MVP thinking in your organization is to have a design-first approach — an area where Boomi can help. With Boomi, you can design, map, and test your MVP without making significant upfront investments. You’re testing the assumptions you’ve made with your customers and discovering what you need to change. It’s an iterative process.
For example, say a business unit in your company wants an SMS API with which it can reach its customers. So, possibly they want this capability available 24×7, or perhaps it’s more important to be able to handle a certain volume of messages in a tight time window like two hours.
You can use Boomi to simulate your process model and show it to the business. This is one of the ways how Boomi API Management can help you shift into a product mindset for building and publishing APIs. You test your assumptions with the business stakeholders in quick iterations and slowly build towards the steady state product (API) that you want to document thoroughly and scale for broader consumption.