Making composable banking work
When I first started my career in banking technology in the 80s, I was initially working with mainframes.
Composable banking requires broader organisational changes to work
Back in those days, we had teams of “head office business users” that specified our requirements. These were middlemen that represented the actual users of the system. We had no direct contact with the actual users.
A few years later, the bank wanted to trial what today would be called agile, but back then was Rapid Application Development. The goal was to accelerate how we delivered our solutions. We were the first in IT to be armed with laptops and even mobile 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 felt we could be productive. My schedule was typically wake up at 6am and code till 2pm, then break to have lunch and an afternoon kip. I was back at my desk from around 6/7pm and would typically code till midnight. This worked for me.
Aside from this, the biggest change was actually getting requirements from end users in branches. This made a huge difference to getting the usability and functions of the solution right.
Fast forward 30 years and this is the norm now. Over the past 30 years, we have seen increasing integration of business users and IT. Even software providers have moved towards a model whereby customers are deeply involved in new products.
However, generally for business-specific requirements, an analyst documents them and a developer writes the code. This has been the model for decades.
There have been attempts to change this, to empower business users to write their own solutions using low-code or no-code solutions. Indeed, my last company, edgeIPK, was a pioneer in creating a no-code platform for the development of web/mobile apps. Gartner calls users of such tools “citizen developers”. This reduced the separation of requirements and development, but I dare say it generated a lot of solutions that were difficult to maintain and fostered little re-use. Hence, such tools haven’t really been used at an enterprise level for mission-critical solutions.
However, this might change with composable banking, where the emphasis is to develop, publish and consume building blocks from a marketplace, and then allow 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:
- Enterprise architect (EA): someone that governs the overall solution at a high level, ensuring maximum re-use and consistency. The BIAN architecture is a good example of something that an EA could create. BIAN provides a great model for the application of composable “building blocks” for a complete bank architecture.
- Creators: developers that create and publish the building blocks of individual computation, functionality or business capability.
- Curators: a role to manage the “library” or marketplace of building blocks. This library should include any proprietary or third-party acquired solutions too.
- Composers: teams that compose a solution from building blocks, using application composition 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” is not just an IT issue as it involves the business users. It is not just standard development with a re-use library, it is an organisational change, and firms will struggle to see the full benefits without this shift.
In the past, the role of an enterprise architect was extremely difficult as it required strong 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 made this immensely easier, though the task of mapping existing systems is still not so easy.
As I have highlighted in previous posts, composable banking can solve a number of issues for banks, but it will require an organisational change and should be supported by a strategy to educate 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 detail. There are strong examples of organisations making this work, and I hope to write about them soon.
About the author
Dharmesh Mistry has been in banking for more than 30 years and has been 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 has been on both sides of the fence and he’s not afraid to share his opinions.
He is CEO of AskHomey, which focuses on the experience for households, and an investor and mentor in proptech and fintech.
Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.
Read all his “I’m just saying” musings here.
