What are the most common API-related pitfalls that businesses/FSIs make?
There are 2 common pitfalls that businesses make when they consider APIs.
The first is that they don't consider APIs holistically. The CEO of Stripe John Collison once said that an API shouldn't be slathered on a product like you do to butter on toast. Even though slapping an API in front of what you're doing today hides the back-end complexity and orchestration, it doesn't help address those problems. So, you're actually not getting to the heart of the problem, and that's going to hold back your experience at the end of the day.
Since connectivity is a multi-faceted problem across data access, orchestration of processes, and across presentation layout, the right solution needs to consider that holistically. If you're only thinking of an API as something you can slap in front of what you're doing today, from a connectivity perspective, that won't work very well in the long run.
The second pitfall is that organisations don't think through their API strategy; they just think about managing APIs. APIs should be viewed as any other products used in/for your business — you need to think about it from the end user's perspective. Organisations thus need to think about how to design, manage, market and effectively retire a particular API when it has come to the end of its life.
What are the building blocks of a successful API strategy?
There are a number of key building blocks. Firstly, as mentioned earlier, you really have to consider your API as a product, so you have to support APIs and the development lifecycle of APIs like a product — all the way from the conception of design through to building, testing, putting it into production, management, socialising it and then retiring it. This is crucial to the success of your API strategy.
The second thing is a layered holistic approach. This starts from the outside in. Start by thinking about the consumer or audience experiences you want to provide for your customers, partners and employees. Then, build the applications to achieve those digital experiences and support them with APIs. The next layer is what we call the process layer. What you're building here is the key business processes in the organisation, and hopefully you can get some fairly significant reuse out of those processes. This ensures that an order process can work similarly whether it comes from a website or through an API. The third layer is exposing your legacy applications as much more fine-grained micro-services to promote reuse. So there is a layered approach, which is about having just enough connectivity to support the needs of the API, and the product approach to the strategy itself.
Sign up for CIO Asia eNewsletters.