API-First : Not just a buzzword

Overview

Building with API-first principles is no longer nice to have, it is absolutely essential to compete and thrive today. APIs have also evolved beyond just exposing bits of functionality; it has become an important strategy for companies who want to position for growth and scale.

Gone are the days when Product teams would say "We have this feature or capability...umm... but we haven't exposed it as an API yet".

But before we go further, let's get the definitions out of the way...

API is an abbreviation for Application Programming Interface. Basically "big English for" defining specifications for how different software components can or should interact. A popular example is the Google Maps API; which other 3rd party systems like Bolt, Uber have been able to leverage to create new apps, a new value propositions; servicing a different set of users.

There! Now...

So, why is API-First a fascinating concept in software development circles...?

Well, for starters, it's an approach for developing APIs that are consistent and reusable; using an API description language that establishes a contract on how the API is supposed to behave and interact. Establishing a contract involves more time in thinking about the design of the API. It often involves serious planning and collaboration with the stakeholders to get and channel feedback on the design of the API before the code is actually written.

So that means:

•  Your API is the actual first user interface and interaction for your application, not the User Interface(UI) the end-users typically interact with.
• You should be thinking of an API as the most important user of an application. Sound strange I know.
• Design Thinking around your API should come first, before righting any piece of code or the implementation. 

The advantage of this is that you are building for the widest possible range of Users to adopt and consume your API, for Developers to easily use your API to integrate your app or service into their projects, and for your API to integrate with any app, System, device, etc...

 Business value

But what does this means to organizations in terms of value and outcomes?

The API-first culture and mindset opens the door to innovation by making it easier for your developers to add new functionalities and easier for outside applications to embed your services. 

a. No Waste of "Waiting"

This means that App development can be 'leaned up' or can happen in parallel. Once contracts between services are established, developers don't have to wait anymore for the API to be released before actually integrating with it. A team can mock APIs and test out all the dependencies just based on the agreed API contract

b. Reduces the cost of App Development:

Since APIs implement functionality in a modularized manner, they can be reused by multiple apps/projects, without writing every piece of code from scratch. This definitely saves time and cost. And if your team has the culture of ensuring that most of their business logic is modularized into APIs... the cost of writing apps just keeps dropping. I like to see it as an investment that has a multiplier effect and it just gets better like wine aging well over time. It kind of reminds me of the Network effect principles. The APIs are the supply side, the API consumers/Apps form the demand side. For every usable piece of code that joins the platform as an API, there are potentially more Apps that are attracted to consume more APIs. The more Apps we find, the more use cases we can see; which triggers more API supply. Hmmm...sorta...but you get?

c. Improves the Time to Market:

Whether it's the fact that the API-first approach allows for developers not to build from scratch or re-architect entire systems or that there are now tools that allow for automating work around APIs(importing API Definitions, Mocking, etc...), we know that Automation has significantly improved API development and that leveraging existing Software assets is a whole lot easier, faster and possible!

 d. Helps with Good Developer Experience (DX):

Consumers of APIs are mostly API developers and not Business personas. Yeah.. believe that! And developer’s experience can make or break the success of an API Program. So part of the benefits in thinking API first, is that it edges you on to thinking around how the developers will interact and consumer your API easily. So you have no choice but to put the developer persona front and center...But this has to be a deliberate practice...

e. Reduces the Risk of failure:

So think about it, with tools now that allow Developers or API Managers to design or mock APIs, the barest minimum can be done without any 'serious' business logic behind it, or heavy development investment. This way usability, feasibility, viability tests can be done much more quickly and iteratively. That feedback loop is just delicious!

Let's look at some real-life cases.

Case 1: Creating New Business Models

Interswitch connected the Banks via its Switch platform to facilitate Bill payment, Interbank transfers, and Cash withdrawals initiated by one Bank's customer on another Bank's ATM terminal. And this was groundbreaking for a while...But then it took things a step further by layering APIs around this Payment Processing functionality to unlock more value for e-commerce use cases...Suddenly Merchants who wanted to receive payments for goods and services they were providing to their own customers; had more reach and could grow their businesses faster than ever before. Customers could pay Merchants online using their Cards and other digital tokens. This birthed products like WebPAY (now Quickteller Business). Even sweeter, those APIs were directly offered as 'API Products' to empower Partners and Innovators in the Industry to create new use-cases, businesses, and solutions on top of them. In fact, these Partners could decide not to offer a Product; just resell those APIs and focus on the aggregation of demand...I love it!

Case 2: Positioning for Scale

Another company I find interesting is Amazon. Amazon ensures that any piece of functionality whether built for internal or external use were provided as APIs first. This became known as the Bezos API Mandate. Essentially, teams were mandated to expose their data and functionality via interfaces. Teams had to communicate with each other through interfaces. There was to be no other form of interprocess communication, no direct linking, no direct reads of the team's data store, no back door at all... Interestingly all service interfaces would be designed with the mindset that they could be externalized. If you didn't do it, you were fired!

I believe this is one of the things that allowed Amazon to scale quickly and diversify quickly from their 'original' Core business. That my friend is how you achieve scale!

Closing

So my submission is that to position your organization for scale and future growth, don't make APIs an afterthought. Think APIs-First because when done right, it provides the unit/modules of functionality that can be combined in several different ways and for several different use cases whenever future needs arise. This is how companies can achieve efficiency in their internal processes and scale for the Business.

Are you writing that new piece of functionality that can not be reused, recombined with other services on-demand without 'touching something' ??? Fear God!

References

• https://nordicapis.com/the-bezos-api-mandate-amazons-manifesto-for-externalization/
• https://blog.dreamfactory.com/api-first-the-advantages-of-an-api-first-approach-to-app-development/
• https://auth0.com/blog/the-business-value-of-api-first-design/
• https://hackernoon.com/is-api-first-development-approach-right-for-your-business-0lr2b58