[Webinar] APIs – Paving the way for a digital economy

A joint webinar by IBM, Finologee & Paperjam Club. Georges Berscheid (GB), Finologee‘s co-founder & CTO, Stéphane Chmielewski (SC), Finologee’s CISO & Head of  Operations & Emmanuel Treny (ET), IBM‘s Director of Application Modernisation & Integration, as speakers. 

As we head into 2021, digital transformation is no longer an option — businesses that do not transform will simply not survive. In addition, organisations are increasingly feeling the need to accelerate their digital transformation journeys as a result of the hard-hitting COVID-19 pandemic and the incessant regulatory pressure.

In order for businesses to transform, they need application programming interfaces (APIs), which have become a key enabler for this evolution to take place. APIs are igniting a cultural shift within many organisations, enabling the integration of diverse IT systems and building more collaborative and self-service IT environments. Playing a defining role in creating new digital services, APIs can connect partner and customer ecosystems and increase the value of underutilized data, as well as unlock new revenue streams.

Be that as it may, the real business value arises only if the API governance and API security are put up front and are trustworthy enough to let users consume yours APIs.

As digital transformation becomes commonplace, in this webinar IBM and Finologee shared their view on how to deploy an API management solution that helps organisations in various industries, but specifically financial institutions, move towards a more digital economy.

Read some insights from the Q&A session:

ET

Identify the first use case.

Do you want to change your business altogether or do you want to increase the speed at which you deliver applications? Do you want to interact with business partners and let them access your system?

We have identified a ton of use cases over the years and we submit them to our clients and then brainstorm different scenarios to identify where to start.

We have identified 4 key API industry use cases

• Speed application development and ongoing app evolution via a library of reusable APIs
• Securely expose systems of record apps and data to Mobile, IoT & cloud apps
• Publish APIs to expand the brand reach and tap into broad developer & partner ecosystems to drive innovation
• Enable new business channels by monetising data and algorithms

Usually, we start with internal facing applications, but sometimes there are surprises. There’s no defined form, but beginning with these 4 categories is usually a good start

GB

I agree that you start with a few key questions when you want to an expose API. Even before exposing APIs, integrating APIs can be cumbersome. From my experience, many of our customers primarily in the finance industry are already struggling with consuming APIs.

It often has to do with regulatory requirements when integrating APIs that improve the user experience. They tend to rely on external products and services to improve that flow, but with regulations, onboarding of an external supplier becomes quite complicated. A lot of administrative tasks have to be completed before an application or an external API can be used. Do due diligence of the supplier, security analysis, make sure that wherever the data is stored is compliant with your own regulations.

What we experience with our clients is that they want to have some kind of an intermediary screen in this case it would be Finologee. We integrate those APIs, combine them to make a unified customer experience and provide the entire API management for our clients for all the integrations secure and compliant. It is easier for them to consume APIs which come out of a single combined portal rather than to go to dozens of supplies and integrate them one by one.

SC

I think the compliance aspect is really important for clients and the backend integration. We interact with our clients continuously and monitor the APIs we provide to make sure they are and remain completely secure and compliant with the ISO standards.

GB

The integration process depends on whether you want to consume or expose APIs and the complexity does depend on the existing infrastructure that the client has. What we saw is that many of our customers, especially in private banking and asset management are working with APIs for the first time and that they are completely out of their element. APIs were not a priority for them and their infrastructure was not built for expose APIs or to work with APIs very easily.

This is where we come in and build this entire API layer between the external wall and “legacy” applications. There’s a huge gap between what exists from the client’s side and what is expected by the end user. Whatever your systems are, you can use APIs to create a bridge between the “legacy” and the modern. Probably the main use case of APIs is to simplify the communication between “legacy” infrastructure and consumer applications using expose APIs.

ET

Some organisations have very old infrastructure. When we started to want to open up to the cloud and to the outside world, the infrastructure made it impossible to do in a secure and controlled way, so APIs were very often used at the beginning to expose the data in a modern, governed and controlled fashion.

APIs can be ultra-simple; Two pieces of data, you expose it, secure it, its available and can be reused, while others can require a lot of transformation with many different sources in various locations. That’s the beauty of it. You compose an API and you expose only what you need while minimising the size of the package.

SC

APIs can also decrease your time to market. They improve flexibility and the user experience to meet expectations.

ET

Iterations, iterations, iterations. You’re not going to be successful immediately. When you build an API you must be able to rapidly publish iterations, lifecycle govern, and monitor and analyse usage to ensure business outcomes.

To make sure you have the best product you need to

• Put it out on the market;
• Market it;
• Make sure it is well explained and used;
• And then see what people are doing with it;
• Adapt based on the usage.

Like any product, it needs to be marketed which means:

• Easily discoverable
• Easy to use
• Well documented
• Make sure developers want to use it; A great development portal is key

When you create 3 APIs, you may find that the one you thought was the best one is struggling and a forgotten simple API which is exposing just a small piece of data is suddenly spreading like wild fire.

Monitoring will allow you to learn whether an API is successful and reiterate what is needed. The developer portal will have a number of tools to let developers interact and rate APIs. There are discussion forums to assess which APIs will work for what they need.

SC

Our customers expect the performance of the APIs to be on par with their “legacy” systems and what they provide to their customers today. The customers in the financial sector also want a choice of infrastructure. A place with all the requirements and security implemented correctly, because they want to remain compliant. So, if you want them to use the API, you need to have the same level of compliance and offer the right service levels. While APIs facilitate access to an internal and/or external ecosystem, the strategic challenge lies in the identification of business opportunities in a logic of “sourcing” to meet the current or future needs of customers and to manage the API lifecycle in terms of governance, security and compliance.

ET

The “legacy” systems do work well and fast, and are here to stay. However, we want to do more with this data want to do more with the systems than expected before and APIs are often used to modernise these systems.

When it comes to regulation, PSD2 actually pushes for more openness. Backend will probably still use APIs to expose data and that’s what the regulator is asking us to do in order to promote more competition and open business.

GB

Those “legacy” systems are not going to be replaced by API based systems anytime soon. The effort is too big.

Many of these applications predate the internet becoming mainstream, so the architecture of these applications was not designed with a focus on communicating. The main interaction you’d have with these systems is through a dedicated console and you would interact with information directly on the mainframe. In order to get them to communicate with systems outside the wall and with other applications, you add additional applications on top.

New applications which are being built today are designed to expose the APIs and s easier for them. Perhaps one day the “legacy” systems will get phased out but APIs will not be a trigger for them to get replaced.