Making Composable Banking Work – FinTech Futures

When I started my career in banking technology in the 1980s, I initially worked with mainframes.

Composable banking requires broader organizational changes to work

At the time, we had teams of “headquarters business users” who specified our requirements. These were intermediaries who represented the actual users of the system. We had no direct contact with actual users.

A few years later, the bank wanted to test what today would be called agile, but back then it was rapid application development. The objective was to accelerate the delivery of our solutions. We were the first in computing to be equipped with laptops and even mobile phones. We were moved out of the IT office and given an office in one of the business units.

At the same time, we were allowed to work from home or wherever we felt we could be productive. My schedule was usually to wake up at 6am and code until 2pm, then break for lunch and an afternoon kip. I was back in my office around 6/7pm and usually coding until midnight. It worked for me.

Other than that, the biggest change was getting the end user requirements into the branches. It made a huge difference in getting the usability and functionality out of the solution.

Fast forward 30 years and it’s the norm now. Over the past 30 years, we have seen an increasing integration of business users and IT. Even software vendors have moved to a model where customers are deeply involved in new products.

However, usually for business-specific needs, an analyst documents them and a developer writes the code. This has been the pattern for decades.

There have been attempts to change this, to allow business users to write their own solutions using low-code or no-code solutions. Indeed, my latest company, edgeIPK, pioneered the creation of a no-code platform for web/mobile app development. Gartner calls users of such tools “citizen developers.” This reduced the separation of requirements and development, but I dare say that it generated a lot of solutions that were difficult to maintain and little reused. Therefore, these tools have not really been used at the enterprise level for mission-critical solutions.

However, that could change with composable banking, where the focus is on developing, publishing, and consuming building blocks from a marketplace, then allowing someone else to “compose » these blocks into a complete solution. But clearly it’s not as simple as that. Yefim Natis, Distinguished VP Analyst and Research Fellow at Gartner, defines the following five roles in composable banking:

  1. Enterprise Architect (EA): Someone who governs the overall solution at a high level, ensuring maximum reuse and consistency. The BIAN architecture is a good example of something an EA could create. BIAN provides an excellent model for applying composable “building blocks” for a complete banking architecture.
  2. Creators: Developers who create and publish the building blocks of individual business computes, features, or capabilities.
  3. Custodians: A role to manage the “library” or building block market. This library should also include any proprietary or third-party acquired solutions.
  4. Composers: Teams that compose a solution from building blocks, using application composition platforms and tools, but not necessarily.
  5. Consumers: the actual users of the application.

For more details, check out Yefim’s recent webinar, “The Core Principles of Composability: Thrive Through Business Change”.

I’m just saying that “composable banking” is not just an IT issue as it concerns business users. This isn’t just standard development with a reuse library, it’s an organizational change, and businesses will struggle to see any benefits without this change.

In the past, the role of an Enterprise Architect was extremely challenging as it required a solid knowledge of business and technology, to be able to sift through hundreds or even thousands of systems and deliver a plan for a better landscape. BIAN has made this immensely easier, although the task of mapping existing systems is still not that easy.

As I have pointed out in previous articles, composable banking can solve a number of problems for banks, but it will require organizational change and should be supported by a strategy of education and adoption in a new way. to work supported by new roles. As always, the tools and theory are readily available, the devil is in the details. There are good examples of organizations doing this work, and I hope to write about them soon.


About the Author

Dharmesh Mistry has been in the banking industry for over 30 years and has been at the forefront of banking technology and innovation. From the very first internet and mobile banking applications to artificial intelligence (AI) and virtual reality (VR).

He’s been on both sides of the fence and he’s not afraid to share his opinions.

He is CEO of AskHomeywho focuses on experience for households, and an investor and mentor in proptech and fintech.

Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.

Read all of his “I’m just saying” thoughts here.