When I started my career in banking technology in the 80’s, I initially worked with mainframes.
Composable banking requires broader organizational changes to work
Back then, we had teams of “headquarters business users” who specified our requirements. These were middlemen who represented the actual users of the system. We didn’t have direct contact with the actual users.
A few years later, the bank wanted to try what would be called agile today, but then rapid application development. The goal was to accelerate the delivery of our solutions. We were the first in IT to be equipped with laptops and even cell phones. We were taken 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 thought we could be productive. My schedule was usually to wake up at 6am and program until 2pm, then a lunch break and an afternoon nap. I was back at my desk around 6/7pm and usually coded until midnight. This worked for me.
Aside from that, the biggest change was actually getting requests from end users in the stores. This made a huge difference in getting the solution’s usability and features right.
Fast forward 30 years and this is the norm now. Over the last 30 years we have seen increasing integration of business users and IT. Even software vendors have evolved into a model where customers are deeply involved in new products.
However, for business-specific requirements, these are generally documented by an analyst and a developer writes the code. This has been the model for decades.
There have been attempts to change this to allow business users to write their own solutions using low-code or no-code. In fact, my last company, edgeIPK, was a pioneer in creating 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 dare I say it spawned many solutions that were difficult to maintain and encouraged little reuse. Therefore, such enterprise-level tools have not really been used for mission-critical solutions.
However, that could change with composable banking, which focuses on developing, publishing and consuming building blocks from a marketplace and then allowing someone else to “compose” those building blocks into a complete solution “. But it’s not that simple. Yefim Natis, Distinguished VP Analyst and Research Fellow at Gartner, defines the following five roles in composable banking:
- Enterprise Architect (EA): Someone who manages the overall solution at a high level, ensuring maximum reuse and consistency. The BIAN architecture is a good example of something an EA could build. BIAN offers a great model for applying composable “building blocks” for a complete bank architecture.
- Creators: Developers who create and publish the building blocks of custom calculations, functions, or business capabilities.
- Curators: a role to manage the “library” or marketplace of building blocks. This library should also contain any proprietary or third-party purchased solutions.
- Composer: Teams that assemble a solution from building blocks, using application creation platforms and tools, but not necessarily.
- Consumers: the actual users of the application.
For more details, see Yefim’s recent webinar, The Core Principles of Composability: Thrive Through Business Change.
I’m just saying that composable banking isn’t just an IT issue, it involves the business users. It’s not just a standard development with a reusable library, it’s an organizational change and companies will struggle to see the full benefits without that change.
In the past, the role of an Enterprise Architect was extremely challenging, as it required in-depth knowledge of the business and technology to be able to sift through hundreds, if not thousands, of systems and provide a blueprint for a better landscape. BIAN has simplified this immensely, although the task of mapping existing systems is still not that easy.
As I have highlighted in previous posts, Composable Banking can solve a number of problems for banks, but requires organizational change and should be supported by a strategy to train and adopt a new way of working, supported by new roles. As always, the tools and theory are readily available, the devil is in the details. There are compelling examples of organizations doing this work and I hope to be able to write about them soon.
About the author
Dharmesh Mistry has been in banking for over 30 years and is at the forefront of banking technology and innovation. From the very first internet and mobile banking apps to artificial intelligence (AI) and virtual reality (VR).
He’s been on both sides of the fence and isn’t afraid to share his opinions.
He is CEO of AskHomey, which focuses on the household experience, and investor and mentor in proptech and fintech.
Follow Dharmesh on Twitter @darmeshmistry and LinkedIn.
Read all of his “I’m just saying” thoughts here.
