In the space of a decade in the mid-1800s, long-distance stagecoach lines were wiped out by a steely disruptive competitor: the railroad.
Hitching up eight horses instead of the usual four to each stagecoach, or painting the coaches in bright colours, would not have preserved them from their inevitable decline. Surprisingly though, this is exactly what many banks today are doing in their misguided attempts to "go digital".
Indeed, as things change so fast all the time, the temptation of piling new digital interfaces and peripheral systems on to legacy IT infrastructure is irresistible. However, true digitization requires more profound change than this, not only in the way banks do business but in the way their IT infrastructure supports that.
The main problem with banks' infrastructure is not so much that their underlying business systems are outdated, but rather that these business systems are too far withdrawn from the external winds of change. The origin of the problem is that banking business systems were conceived with an overwhelming focus on processing transactions as efficiently as possible. These transactions were mostly initiated by bank employees who were, by the way, the only way customers could interact with the bank. So, these systems were very much inward-looking and viewed the world as an accounting ledger rather than a complex ecosystem of whimsical human beings.
The thing is, digital banking requires the bank as a whole, not only its digital customer interfaces, to be open to the world and to evolve at the speed of human whim. And because customers care about aesthetics, banks must be able to deliver innovation in digital interfaces faster than in underlying business systems. In other words, digital banking requires the bank's business systems and interfaces to be open, evolvable, integrated in real-time, yet loosely coupled to allow multi-speed evolution.
Now here's the catch: all of this architectural modernization needs to be achieved at the lowest cost possible. To a bank CEO busy tackling anemic margins, short-termist shareholder pressures and cut-throat competition, undertaking architectural modernization may appear unattractive or even unrealistic. Moreover, considering the size and complexity of the challenge, bank leaders may also doubt that any one vendor can solve the challenge with proprietary packaged solutions.
While banks are wrong in believing that architectural modernization is unrealistic, they are right in believing that no single vendor can help the bank address the challenge with a proprietary packaged solution. The reason is, simply, that the bank as a whole must open up to a world that is so complex and fast-changing (the world of human whims) that no single systems vendor can possibly address the pace and breadth of change with its own products. Nor, of course, can the bank on its own.
Really, the way systems vendors can help banks succeed in the big wide world of human whims is... to tap the creativity and productivity of the outside world. More precisely, vendors must enable banks to continuously tap the creativity and productivity of the outside world without having to rely on vendors. This may sound like asking vendors to shoot themselves in the foot, yet it is exactly what banks need most today.
There are two approaches in systems architecture which, used in combination, enable banks to continuously tap the outside world beautifully well: platforms and frameworks. As both words are chronically used and abused in the IT industry, let's be clear about what they mean in this context.
Platforms are a place where: producers can use intuitive tools to create "things of value" and sell them to consumers; and where both parties can exchange information to continuously increase the value of the things. In our context, the consumers are the banks and the producers are innovation partners, systems integrators, independent developers, banks themselves (their IT departments "giving back" to the community)... essentially, whoever can best address any given business need. The "things of value" are any piece of software that enables the bank to improve the way in which it addresses a business requirement – an app, a report, a piece of functionality, an interface, an API, a widget, whatever.
However, these "things" are of no value to a bank if they cannot be readily installed and used, "plug-and-played", by banks in their existing systems infrastructure. This is where frameworks come in. A framework is a way of setting-up the bank's infrastructure to enable the bank to readily exploit things made by other people.
The bank should have a framework for each one of the key aspects of digital banking. For instance, an interaction framework should enable a bank to pick, plug & play any API or user-interface (UI) available on an interaction platform. This framework should also enable the bank to easily tailor the API or UI to its specific context via an intuitive design-time tool and DevOps processes.
Similarly, an integration framework should enable a bank to pick, plug & play any package of real-time integration event messages and transforms, and to use them to connect to any service provider, be it the legacy bank, another bank or a non-bank service provider ("own labelling"). Conversely, it would also allow a bank that makes products or provides service to offer them to another ("white labelling").
An issue for banks that want to modernize their architecture and offer outstanding digital banking services is that very few vendors offer tried-and-tested frameworks. But the biggest question of all is, where is the marketplace where "things of value" for digital banking can be exchanged? Someone has to create this marketplace and then entice a critical mass of banks and producers to join it. The people who manage to do this will become the Amazon or Alibaba of banking, a place where producers and customers cluster to innovate and propel digital banking to higher planes.