Share this post
The drive for ISO 20022 and the instant everything push is putting more and more pressure on legacy core and ancillary systems such as fraud, reconciliation & investigations by not only introducing larger, richer data sets (that will bring key customer insights for hyper-personalisation more on this another time) but increasing volume which in turn puts legacy core and key ancillary applications in a position to try and drink from a firehose.
Challenges of legacy systems in a modern world
The challenge, though, is not purely down to technology; with a rising number of regulatory-driven events, just trying to keep pace with this change demands resources focus here (regulations are not a choice after all), and the complex nature that systems have found themselves from small change and highly customised nature of existing systems has resulted in non-standard approaches needing to be adopted. These rarely lend themselves to being agile or quick. The competition for the capacity to drive regulatory change, modernisation, and innovation simultaneously is a classic race condition that leaves modernisation and innovation losing each time.
Combined, we all know that these make the case for change quite evident, but there is still a reluctance by many based on the risks presented by the fact these applications often sit at the very heart of the architecture and are woven into the fabric of the institution and how they operate. Throw in the age-old preconceived notion that they must embark on an expensive, lengthy and complicated journey that might not deliver what they wanted, resulting in impact downtime and increased risk; this task can seem daunting and unappealing.
That is not to say that it’s all doom and gloom. With the changes in architecture, how applications are constructed, and a wealth of modern approaches, these are no longer all-or-nothing changes. The key is knowing what you want to achieve, and then where do you start?
Outcome-focused modernisation strategies
One simple but powerful option for establishing what your modernisation programme or approach could look like is to be outcome-focused; if we don’t know what the outcome we want to achieve is, how will we know what we need to do, to get there, what path to take and what is important to us. This is summed up aptly in two quotes, one from Lewis Carroll
“If you don’t know where you are going, any road will get you there”
and the second from Yogi Berra:
“If you don’t know where you are going, you might wind up someplace else.”
As simple, obvious and light-hearted as they may seem, they are powerful reminders of the importance of having a clear sense of direction. If, as an organisation, the work from the business, technology, and operations teams has not been done to understand and set a strategy, any amount of expensive technology won’t be able to solve the problem; the risk is an expensive, frustrating, and time-consuming programme what was doomed from the inception to fail, based on a lack of clarity and direction. That is not to say that the age of years-long transformation programmes will make a return (we all know those are in the rear-view mirror), but by understanding where we want to be, we can break the larger and more complex problems into smaller, more manageable, deliverable, and achievable goals.
Ones that everyone is brought into and supporting, able to understand the value that this will bring across all facets of the organisation. Adopting this sort of thinking addresses both the vertical of the what (including the why and why now) but also the horizontal that includes the wider stakeholders, thinking about processes and the impact of adopting new applications and ways of working (redesign, risk & policy reviews, data strategy, operating model and operating procedures), after all, it will be people that benefit and help to drive bottom-line.
An often overlooked benefit of modernisation is the efficiency gains and standardised approach resulting from adopting a common architecture that lends itself to modular and regular change. Resources will be able to more rapidly assess change and provide impact analysis on regulatory or, more importantly, wanted change. With a quicker time to assess and deliver required change, the ability to implement something new from feature and product teams rewards those resources by allowing them to focus on value-adding work and responding to customer demand with new ideas and propositions.
Once there is agreement on the destination, there are several roads that can be taken: the move to digital, whereby something is built in parallel and then a switch over to the new system, often with the legacy applications running some services until they reach the end of life or are discontinued. Build out a new system that will start connecting to and offering new products and services, with a phased migration away from existing systems, allowing targeted systems and applications to be migrated first. Replace, identify those priority applications, products, and services and implement new solutions that will take these on and be able to offer new services and harness the power of new technology, There’s no right or wrong way to do it (as long as there is agreement on the destination).
For example, there are choices to move from complex heavy-lifting mainframe application stacks to a “hollow out” approach, where the mainframe is left to carry out its complex heavy lifting, and we introduce an interoperable lightweight set of cloud-native applications controlled by orchestration layers. Creating solid foundations for the “sexy” overlay and value-added services can be built.
Leveraging cloud and fintech for innovation
This method allows focus on the key priority areas and gets them running in production quickly, proving the method and generating new revenue, which will unlock additional funding to move to the next product/application, all while protecting existing and relied-upon revenue streams. By treating complex applications as outcomes, the ability to prioritise the high-value outcomes and treat them as products accelerates the process and allows for the decommissioning of legacy tech (yes, this can happen!). The ongoing maintenance shifts from complicated customisation and change requests (CRs) for enhancements to configuration and self-service.
Building further onto the “hollow out” approach is moving infrastructure and applications piece by piece into the cloud and potentially into an “as a service” model. The key remains breaking down the problem, but the move of the applications, processes and products is a migration to cloud services or even to managed services such as payments as a service (PaaS), banking as a service (BaaS), and even to elements such as guaranteed reconciliation services (business process as a service – BPaaS).
These moves to an elastic scalable and quickly implementable base allow for the avoidance of a “double hop” whereby a cloud migration was inevitable but has been pushed down the line, meaning it still needs to be done, just that the jump is now less as the “current” technology lends itself to the move. Understandably, cloud migration remains a challenge (many perceptions of why). These modernisation journeys are a step in that direction by enabling modern cores and applications, which are better suited by design to migration.
Many organisations will look to modernisation as a necessity but are faced with the competition for resources to maintain regulatory compliance Vs. innovation, migrations, and collaboration with FinTechs can help reduce some of this pressure. By institutions collaborating with fintech to use innovation of services and offerings, there should always remain competitive collaboration that will continue to drive innovation, or the risk of stagnation returns and the comfort of sitting back on what has always worked creeps back in.