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

Every time I am forced to do this, a little part of me dies.

A friend of mine holidaying in Byron Bay came back to their beach tent to find this little guy sleeping. It seems like all the rain lately has re-invigorated the iguana population.

A generation of Windows use has taught us that this is an acceptable user interface. #itsnot

joshondevelopment:

I’ve just started a new project.. well an old project that uses ruby 1.8.7 and rails 2.3.5.

If you get this error:

1.8/timeout.rb:60: [BUG] Segmentation fault

Its a problem with lion and ruby. Uninstall any version of 1.8.7 you have with

rvm remove 1.8.7

and then run

CC=/usr/bin/gcc-4.2 rvm install ruby-1.8.7 --force

This problem just cost me about 1.5 hours. The above solution works a treat. And this link:

Lion, RVM and Ruby 1.8.7 woes

Has some more details, including how to get the GCC 4.2 compiler installed if you’ve recently upgraded to the latest XCode.

(via dbreunig)

Some King Parrots on the verandah (just outside Mudgee, NSW, Australia). Photos taken by: @jennysinclair.

“Rabbit for dinner!” This photo was taken by my sister-in-law’s father at his home near Newcastle, NSW, Australia. It’s good to see the native wildlife striking back against introduced pests.

Why do we need to know an exact location, when it is really proximity that matters?

It is not a big leap to suggest that the use of location information in modern web and smartphone apps is a Pretty Big Thing. It should also be obvious to anyone paying attention that users give up significant personally identifying information (PII) when they participate in these services. In general, the payoff for users is that they are rewarded with utility, but there is always the risk of unintended consequences. How can a user be certain that their PII will not be used for purposes other than those originally intended? The simple fact is that you cannot. 

However, if you break down what happens in most location-based transactions you can see that it is actually proximity that is important, in the sense that the transaction typically compares two or more locations to see if they are near each other. If they are, then the service can make some inference such as recording the fact that two people have met, or that a person was near enough to a venue of some kind to recoup a reward. In many situations the actual underlying physical location is more information than is necessary to complete the transaction.

So if a service records the exact physical location of a person persistently, then there is a risk that this sensitive PII can leak and perhaps be used for purposes other than what the user intended or was aware of. But if the service just records evidence of proximity - and importantly, anonymises or throws away the underlying physical address information - then the risk of misuse of their physical location information is greatly reduced. For example, it would still be possible to know that two people met, but it would not be possible for some nefarious third party to know where they met.

I think that we are probably some way away from this distinction becoming mainstream, mainly because a lot of services making use of location today are doing so precisely so that they can exploit the underlying physical location data in other contexts, with or without the informed consent of the user. 

Sadly, until we see some high-profile misuse of end-user physical location data via a compromise or a change in terms and conditions, it may not be front of mind.

Just in case you need to waste 20 minutes watching old computer operating systems reboot.