Subtleties of becoming API-First
With years of investing in API development, many enterprises have become effective in delivering APIs across their IT landscape. APIs are built to partner with third-parties, power mobile applications, simplify architecture and facilitate internal interoperability. When is it safe for an enterprise to declare itself API-First? Let's look at some of the fine prints of what it means to be API-First in today's world and where we stand as a bank.
What is API-First?
The term API-First is popular but does not always refer to the exact same idea. A widely adopted understanding of API-First is to develop applications around an API right from the beginning, rather than adding an API-layer later. This means defining and designing your API schema before writing any code. Development should then always lead to application interaction and API consumption.
Next is the approach to regard APIs as fully-fledged products. APIs are then no longer a means to an end; they are the actual delivery. Many large payment processing and communication platforms in the market take this proposition, often with a commercial intention. Rabobank's Banking-as-a-Service portfolio is a notable example. Many PSD2- and other commercial APIs are listed and offered as a product on the public developer portal. In both above perspectives, APIs are treated as first-class-citizens of the business. At Rabobank, we advocate to treat the services with which applications expose their functionality as prime subject.
Another non-product-centric and much simpler view on API-First is to simply treat APIs with priority. It is to promote, facilitate and propel API production and consumption throughout and beyond the enterprise. This perspective on API-First is currently most applicable to Rabobank.
Underlining extremes such as API-Last and API-Only
But how do enterprises relate to extremes in this spectrum such as API-Last and API-Only? There is generally no presence of API-Last in today's market. You will not find large commercial enterprises that have not digitized at least a subset of their key customer journeys through APIs. Most mid- to- large scales have some API programme in place, leverage the use of API technologies and experience some benefits. Although it is evident that some use APIs with a purely tactical motive rather than strategic.
Nor will you find companies publicly claim they follow an API-Only approach. Rabobank encourages the use and development of APIs. We regard synchronous APIs (typically REST) and asynchronous APIs (typically events) as predominant and strongly preferred over File Transfers. In case the integration requires mapping, business rules and transformation, then usage of an application platform such as Azure Logic Apps, AWS AppFlow or Pivotal Cloud Foundry (PCF) are recommended. So, although we favour APIs, we never take an API-Only stance.
What the API-First mindset looks like
The real potency of an API-First approach is expressed when various levels of organizations adopt an API-First mindset. Leadership, Architecture and DevOps community each have a role to play.
IT Leadership
It starts with a belief that APIs will help achieve your business goals and APIs are generators of new business models. An enterprise-wide API strategy should focus on establishing an API ecosystem and bridge API ideation into sustained growth and business agility. Growth of partner acquisition, API-expertise and interoperability of your applications. Business agility to make tomorrow’s business better. Rabobank’s IT Leadership recognizes such organizational objectives can most effectively be realized through acquiring modern, state-of-the-art API Management platforms.
Architecture
Architecture should promote a unified and coherent way of developing APIs. This includes defining (security) guidelines and validations thereof. A focus on API discoverability and reuse will help avoid duplication. Our architecture stimulates a high quality of API's being deployed, increase the speed of product development, and make the engineering journey as smooth as possible. Like a knife through butter. Standardization and automation are cornerstones in this process. A well-defined operating model our fundament.
DevOps Community
DevOps teams should be completely familiar with API development, its governance, and ways of exposure. Rabobank’s central API Platform Teams help and allow our wider DevOps community to apply guardianship on their API lifecycles, being confident with available observability stacks and diverse types of testing (e.g., load, performance). We are currently investigating which enterprise API client- and design tool best suits our DevOps community. We do so because we understand API Design-First is contained within the API-First philosophy. Finally, we continue to build our Rabobank API-Community to create a stronger support base for the choices we make.
So, where do we stand as a bank?
Rabobank is categorically API-First. It embraces an API-First strategy. Surely, not every Rabobank DevOps team develops an application around an API from the outstart. Nor are the majority of APIs on our catalogue regarded as discrete products. But we are API-First because we classify API development as principal. We have an API-First sympathetic mindset, work with modern API Platforms and apply appropriate governance. These are essential ingredients for creating a thriving API ecosystem.
Lastly...
The future is shaped by APIs, with internal and external API integration paramount for any large business. Although we see the API-First approach becoming more prevalent around us, there is no clear end-state when it comes to being API-First. There is no finishing-line, nor is there a resting-place. Therefore, declaring oneself API-First may perhaps not be the most important thing. Rather, it is about the marginal progress on this journey that can give an enterprise a true competitive edge.