Not Reinventing the Wheel: Tackling the Challenges in Banking Technology
By Alexey Utkin, Financial Services Practice Leader, DataArt
If you contrast today’s large banks with leading technology firms, the difference in culture, skill, and increasingly, talent, is huge and becoming even greater. The overwhelmingly complex technology landscape, heavily bureaucratic and time consuming manual processes, and legacy systems with accumulated technical debt, result in even the simplest change in technology sometimes taking weeks or even months to implement. Compare this to turn-around in mere hours in a sizable company that has implemented continuous delivery.
The technology landscape, including applications and data, is traditionally siloed and often reflects a bank's organizational structure, sliced and diced by business units, front-middle-back office, desks and instruments, which results in considerable duplication among IT systems. The scale of the challenge in banks is large and every source of P&L tends to separate itself from other project or program dependencies.
Given the lack of a culture of sustainability and the need for overarching technological leadership, many wheels are reinvented with every single project, in areas from infrastructure, configuration and controls, to visual/UX components.
Technologies are often selected for each of the projects, creating a disparate tech landscape and unsupportable maintenance costs. Often the reality is that the ability to support existing systems exists only on paper, since knowledge has been transferred many times over the last few years to address employee turnover and the last significant change to the system was made three years ago.
On the bank-wide level, it is common to see each piece of technology snapshotted in each live product to remove dependencies. This itself creates high maintenance costs that rise over time. To put this situation into perspective, you can look back how banks and other large financial institutions dealt with the Heartbleed problem last year, launching wide investigations into each of the hundreds and hundreds of live systems under critical time pressure.
Must it really to be this way in banks or is there potential to revolutionize banking technology? Conversations related to technology and business agility in the banking context often come down to the argument that legacy systems area major obstacle. But why then do most of the landscape diagrams in such banks have "legacy" systems built less than a year ago? The cultural challenge is to break the traditional approach of unsustainable, tactical or strategic systems with an accumulating technical debt and the accompanying expectation of reengineering in 5-7 years.
On the bank-wide level, it is common to see each piece of technology snapshotted in each live product to remove dependencies
Given the scale of this largely cultural problem in banking technology world, many banks are seeking ways to respond to business challenges such as demand for innovation, business agility and efficiency. Some of these attempts include a number of "outsourced innovation" arrangements, often happening in various fintech incubators and accelerators sponsored, supported and mentored by the banks. It's certainly beneficial for the fintech industry as a whole, but it doesn't look like a full blown transformation of banks into innovative companies. Consequently, all of these incubated innovations being brought into the bank environment will face tremendous challenges. Another observation is that an increasing number of banks are entering various managed services deals, in many cases transferring their IP to a service provider, to get the benefits of operational efficiency while reducing maintenance costs. It does look like a good tactical solution, but the question still stands - is there potential to dramatically decrease the complexity of the technology landscape and IP in the banking environment?
A growing number of people believe the answer is yes. These people are willing to facilitate a cultural shift and revolutionize banking technology with modern practices and methodologies from leading technology firms or large self-organized structures, such as an open-source community. We see today from time to time that there is management buy-in on various levels and we see transformation programs affecting sizable departments and lines of businesses, with people finding new ways of working, and new ways to sustainably engineer efficient and effective systems.
The challenge is hugely cultural and goes far beyond IT itself. In order to make such a change, the reality is that many bank departments need to seek new ways of working. To acquire technology talent, bank leadership needs to show an exception to the common understanding that technologies and processes are outdated in their environment. They must make it possible to utilize open source technologies and possibly open source contribution itself. Cooperation from the legal department is essential.
Costly heavyweight enterprise systems, lacking skills on the market, and slow in support, continuously milking money from outdated piece of technology is still a common place; but new alternatives, often well-known and much cheaper, sometimes open-source, are still not being used by banks due to the traditional enterprise technology selection process.
The other side of the story is not only technology itself, but also the user experience in most of the banking systems isn't what modern users want it to be. Some banks are starting to get it right, but most have a long way to go to master user-centered design. UX especially should be transformed at the bank-wide level rather than inventing it separately in each of the systems being developed.
Principles of a Composable Enterprise, formulated by Jonathan Murray et al., could become the basis for such a business transformation. The idea is in maximizing the adaptability by designing business functions, processes, organizations, products, services, and technology in general as reconfigurable building blocks. Component Operating Model of Composable Enterprise tackles the organizational structure and processes part of a challenge, whereas Component Architecture Model relates to the IT landscape.
These ideas are seen radical by many today. Implementation of these ideas is a major cultural change, requiring significant adoption of new ways of thinking and working, development of a new set of organizational and technical skills. This change goes far beyond the IT itself. To enable such a transformation and achieve composability, policies need to be adjusted to shift from some traditional heavyweight proprietary enterprise systems slow in support and learning to more open, often even open-source, standards based technologies, which are also often cheaper and more popular. Ability to contribute back to open-source community should also be considered seriously, not least as a mean of attracting wider tech talent to enable and scale up such transformation.
We currently observe some organizations starting to adopt the principles described above to achieve efficiency and competitiveness via constant innovation and seamless user-centered experience across all products and services, the ability to timely respond to the ever-changing regulatory requirements, long-term sustainability. It may be a still long way to go, but I sincerely wish them success.