Robert Prince is a principal engineer with Just Eat Takeaway. In this article, he discusses API as a product.
Let us discuss the future and think about where your platform could be. You’ve got many extensible products across thousands of partner businesses, and you’re constantly delighting customers. So, you’re providing everything that your customer needs across multiple countries. You are building that software once and releasing it across multiple regions. It is available to all constantly, and there is no downtime. So, this is a great place to be for your platform.
So, today, in your platform, let us consider nine user journeys: customer orders, tracks, reviews, gets a partner, the partner gets an order, fulfills it, gets a courier, the courier receives the package, and delivers the package. These are standard journeys for an e-commerce platform. You may have iOS Android applications, POS integrations, etc. This is great for your internal business.
To go towards the future we imagined earlier, we want multiple integrations to take it everywhere. To do this, we need to do three things –
- Identify the right and right-size microservices.
- Identify API products.
- Build an API-as-a-product website.
According to Wiki, microservices are owned by a small team, independently deployable, loosely coupled, and organized around business capabilities. Teams can develop and deploy their services independently. There’s a reduction of dependencies on other teams and reduces the time to market. The most important part is that the microservices should be organized around business capabilities. We think of technology, but we must concentrate on the business needs.
If we pick something that’s too big for our microservice boundaries, then it doesn’t solve the purpose. It will be a macro-service instead of a microservice. This will take away the nimbleness of the enterprise.
If we go too small, we may have nano-services, which may be too small. The right size is where you have services that serve one capability and have rich, related, and useful features. It has less coupling, has related functionality together, is easier to reason about, is less complex, and is more intuitive about how the system works.
Let us now consider the features of the micro-service. A good start is a business process model. This allows the tech team to be aligned with business processes and capabilities where the size is just right. As a business, you want to present an organized, understandable view of your platform for Product, Engineering, and Delivery to align on and continually reference, use, or adapt.
So, you take a collection of your processes across the business. You might give them different names, which are more palatable, and then you can start putting the tech into those business process boxes. So, now, you have thousands of tech components put into fifty business process boxes. You may also come across duplication, which can then be eliminated. This gives you an organized, understandable view of your platform for your product, engineering, delivery, and departments to align on and continually refer to, use, and adapt it. Even if teams change ownership changes, the model map is available as a reference.
So, we have API as a product. So, returning to our example, customer order delivery is a set of APIs. And this is your API product. Each user workflow has a list of APIs. Any user experience can be “plugged” into the API product. Catalog your APIs. Produce APIs with one voice and give a consistent experience. Produce consistent documentation. Include guidelines, standards, and other relevant details to make adapting easier.
So then, finally, once you’ve got all this, you embrace the fact that you need an API-as-a-product website. It is a real product that is a great opportunity for your business. You can use automation to drive out user flows defined in your products and then drive them to the next level of detailing. You can have a team to provide, maintain, and operate the website. Each decentralized team is responsible for its API. The website can have a sophisticated UX and design. You can have a product management team and spot opportunities to grow your product further.
So, to conclude, to get to the future you envisage, identify your right and right-sized microservices. Design APIs for external use with API governance. Identify API products and invest in them. Build the best API-as-a-product website.
