EA is the cornerstone of initiating any change because you can only do the change when you know what you are starting with.
Compared to business in other industries, the digital transformation challenges of banks are compounded: they have legacy and monolithic architectures to transform, and they’re highly regulated. The path to transformation is to provide access to the legacy systems via open APIs, allowing banks to develop modern applications independently or through partnerships with Fintech companies. RTInsights recently spoke to Christian Richter, SVP Customer Success at LeanIX, to sort through the complexities of such transformations and better understand the role of open APIs.
Open APIs are crucial to the innovation and quality of service of banks
RTInsights: How does the lack of open APIs impact banks’ ability to effectively manage their enterprise architecture?
Richter: We see that a growing number of, if not all, banks are relying on open APIs. If you look at European legislation, you find, for example, PSD [the EU’s second Payment Services Directive (PSD2)] requires banks to provide open APIs to third parties. This is the basis to foster external collaboration.
When I’m speaking about APIs and banking, I would say that there are three types.
One is the internal and system APIs. Core banking systems are monolith architectures. They are still based on mainframes and COBOL [programming language]. They are legacy technologies and not necessarily coming out of the box with open APIs. Having internal and system APIs helps to speed up the development of new microservices-based on these legacy systems or services that use legacies as back-ends.
The second category of APIs is public APIs. These are APIs that connect a bank’s back-end systems and services. They are a service layer, which is necessary for external services. For example, they might be used to obtain a credit rating or address validation. You don’t want to do these validations for yourself when the validity of a customer record is checked. Take the confirmation of postal codes in the U.S. In the process of creating a customer record, you use an API from your own system to link to an external express address validation system. That system will let you know if the postal code is valid or not. You don’t need to have their own internal resources to do that. And the same applies, obviously, to credit rating, which is information that you can’t have as a bank.
The third type of API, and probably the most interesting one, is the public APIs that are more on the service and front-end layers. They are used to connect to third parties. Using them, a traditional bank can offer services to Fintech companies, which then develop their own customer applications or who aggregate data. This is enabling new experiences and new business models, even things like B2B2C services and applications.
By exposing customer data and transactions in this manner, an insurance broker would, for example, be able to create a custom offering for a customer based on the account transactions by deriving the current insurance types and contracts. The broker could point out which insurances the customer is paying too much for and where the broker can make a better offer. That’s an example of a B2B2C business model enabled by an open API.
As I said in the beginning, open APIs are something that came to be in 2016 based on the EU PSD. Enterprise architecture (EA) as a discipline within a financial institution, especially for traditional banks, needs to be the enabler. EA needs to show how data flows from the back-ends over the services to the front-end.
Enterprise architects typically take the lead in screening new technologies and are promoting and enabling an “API-first” approach. What does that mean? We’re an API-first company. Our own application runs on the same APIs internally as it does for external connections. Other parties (customers, partners) can connect to our system, and they can develop their own kind of applications on our system.
The same thing can be applied to banks. Take a traditional bank and a mobile banking app I have on my smartphone. The mobile apps should use the same APIs (the ones provided to Fintech companies) because then you know they are stable, safe, secure, and scalable. This is where I see the enterprise architects playing a role in bringing this shift for financial institutions.
Monolith IT architectures impede the ability to create a modern EA strategy
RTInsights: Most retail and commercial banks operate using legacy monolith IT architectures in their core banking systems. How does this impede their ability to create a modern EA strategy?
Richter: Core banking systems have been running for decades using technologies like COBOL and mainframes on the hardware infrastructure side. And there is a shortage of programmers with COBOL skills. It would sound so simplistic to just retire the mainframes and COBOL. But there are a lot of dependencies to that, which makes it difficult.
There is an example here in Germany. There is a public pharmacy bank that tried to change their core banking system. Most pharmacists and doctors use this bank because they offer special services that are related to running a pharmacy or a doctor’s office. The bank has about 400,000 customers, which is not a lot for a bank. They were really challenged as a result of the change to their core banking system, leading to a high number of customer complaints.
In a migration, you can’t afford downtime. The steps in a migration must be well thought-through, dependencies must be analyzed, and possible scenarios need to be planned out. As a bank, trust and stability are key assets, and you don’t want to destroy these because you did not consider the dependencies. Also, online users of a bank are more risk averse and do not consider it as a value to see a new front-end every month.
Fintechs don’t have the challenge of legacy architectures. Their advantage is that they started building their infrastructures in the last decade, not three or four decades ago or even longer, as is the case with some banks.
Another factor to consider is that banks are regulated and very much under institutional observation. They need to abide by data security and data protection regulations. They need to document technology risks in their landscape, and they need to show a plan on how and when to mitigate them. These are things required for the finance industry.
EAs help banks in their transformation process
RTInsights: How can incorporating EA as a transforming initiative affect a bank’s business model or customer experience?
Richter: An enterprise architecture initiative helps you to see your current state of the IT architecture. They can show where the dependencies are. How does the data flow? What are the APIs? EA is the cornerstone of initiating any change because you can only do the change when you know what you are starting with. Then you can take the technology trends and change drivers into consideration and plan and execute the changes.
Cloud computing is one of the main drivers changing the IT architectures of businesses, but obviously, not all parts of a business, especially in a bank, are equally well suited to run in the cloud. For me, the enterprise architect is the moderator and enabler to show what’s pragmatic and what are the next logical steps. What are the things that we should avoid? What standards should we adopt? In collaboration with Cloud Architects and a Cloud Center of Excellence (CCoE), standards and best practices are defined – most likely starting with an evaluation of the current landscape and a way forward (e.g., based on 6R strategies) for each application.
Another value-add of EAs becomes clear when you look at the project landscape. Organizations have multiple projects running at the same time. Often, these projects build on each other. If you start every project from scratch to capture the current landscape, then it can become super complex, and there is no single source of truth. Why not take the skills of an enterprise architect and drive this process? Say, “This is the landscape as we are looking at it, and every project should look at the same landscape and take the plans of other projects into consideration.”
Then, the project that starts in two years knows how the landscape evolved from today and what decisions were made in that process. Given that they were probably taken for good reason, properly documenting those decisions lets others understand them.
EA brings digital transformation in an order
RTInsights: What are the key steps banks should take to support their digital transformation with an effective EA strategy?
Richter: It all starts with business capabilities. That’s how a journey begins. This covers more than just the core banking systems, which I’ve talked about as being monoliths. Digital transformation can be applied to a bank’s CRM side, its HR processes, and its own finances. These are not necessarily related to the core banking operations. Taking the bank’s business strategy into account, this all makes up a lot of business capabilities that a bank needs to develop.
As a next step, the application portfolio related to business capabilities needs to be collected and evaluated. What applications are we already using? Where are we mature in terms of capabilities? What are the critical capabilities we need to invest in? If we have omnichannel or digital banking capabilities, do we have the right systems behind them?
This is where, in an EA process, you find out gaps between the as-is and to-be maturity. Another point could be your bank that operates in multiple business units or countries, and you’re figuring out how this impacts your internal IT department. Am I doing customer relationship management (CRM) in Country A with Salesforce and in Country B with Microsoft Dynamics? How does that make sense? Why don’t we use the same provider for better negotiation levers and to build internal skill pools? Understanding these issues will have a positive cost effect on a bank.
Also, APIs need to play a very integral role in an EA strategy. You want to know what kind of internal APIs you enable your developers to use. You want to know what kind of external APIs you have. You want to have them documented and make sure that that you always use the same ones. For example, in retail and commercial banking, you do not want to check customer addresses using different APIs/services with different vendors on the other side.
Finally, you need to look at the APIs that you expose externally to Fintechs and others. What are their life cycles? When do you bring out a new version of that API? What are the requirements for compliance and performance?
The core steps are to build out your capability map, lay out your application portfolio, evaluate the dependencies, and the way forward. On the API side, make use of automation to document and publish the API catalog.
Read the other article in this series:
