As anyone who works inside a large, modern retail bank will attest, many technology systems are out-dated, poorly architected, littered with unfortunate and opportunistic compromises and generally sclerotic in a way that has a material effect on the activities of the businesses they allegedly support. The level of technical debt has crippled technology operations in the much same way that financial debt has crippled their owning organisation’s financial operations.

For example, core-banking systems are often 20 years old or more, run on large mainframes that whilst being generally performant today, can be costly to maintain and extend. Some have already reached or exceeded their performance limits. Supporting systems may run on more modern infrastructure, but even if they are built with good intentions, very quickly fall victim to the quarterly bonus cycle that favours the short-term fix and attendant accrual of further technical debt. 

There are many suggested remedies for these problems, but for the purposes of this question, we can categorise them into:

• Incrementalism - overlaying changes onto existing systems and processes
• Reboot - trying something completely different

The perceived risks of incrementalism are lower, but technical debt piles up in the medium term in the form of ever-increasing complexity. Reboots are difficult to initiate because they appear too ambitious to management fatigued by previous failures, with the irony that previous failures are due in no small part to layers of unmanageable complexity built up by successive incremental changes and short-term fixes. At the centre of these problems is a profound mismatch between the short-term incentives of management and the much longer lifetime over which mission critical business systems operate. 

But even though this mismatch is relatively easy to characterise, there is no evidence the situation is likely to change any time soon. The result is that for the majority of systems, businesses make incremental changes for as long as they possibly can. Businesses argue this is economically sound, technologists argue that it has hidden costs. Both are probably correct, depending on their context. However, there comes a time when a reboot of some form is simply unavoidable. 

For example, three of the four big Australian retail banks have attempted massive core system replacement projects of one form or another over the last five years, with a view to replacing 15-20 year old production systems. In the online banking domain, some of our large banks have production systems first rolled out during the initial wave of online banking deployments in the late 1990s, and are now in the process of re-platforming.

Leaving aside the degree to which these programs have been or will be successful, there is no doubt that we exist in an environment where banks are making very big decisions about changes to their mission critical systems. Systems that have been incrementally updated to the point where it is no longer economically or technically viable to make changes to them at an appropriate level of risk. 

Which brings us to the inevitable technology reboot: when presented with the chance to start from scratch, what should an enterprise architect do? What are the foundational pieces of a technology stack required to support a retail bank? How would the decisions made today be different from those made in the past? Is it possible to simplify the environment? Is batch relevant in 2012, or would it be possible to use technology to move to a completely real-time orientation? What is the role of next generation transaction switching systems such as Distra or Transacumen? How should the online platform interact with the back-end, should there even be a difference? Can a bank realistically deploy into cloud-based infrastructure, and what about the rise and rise of mobile?

We are already seeing new retail entrants such as Movenbank in Europe and BankSimple in the USA make very bold moves with their technology stacks. We are also seeing multiple potentially disruptive moves in the payments space with players such as Square, Dwolla and Stripe. As start-ups, these organisations have the advantage of zero technical legacy to work with, but they do have to operate within the confines of the banking environment.

So, as an enterprise architect, what would you do if you had the opportunity to rebuild the technology stack of a retail bank completely from scratch? 

Comments on HackerNews