Monolithic technology – a monumental problem for financial services

By Tim Hood, Vice President – EMEA and APAC of Hyland. www.hyland.com

The pandemic highlighted the need for connected platforms to allow content to be accessible from where it was needed. Since then, as memories of lockdowns recede, organisations have begun the process of untangling workarounds, aiming to create more coherent technology platforms.

But there are prominent exceptions, with some banks and other financial institutions still saddled with legacy solutions. That’s left them trying to nurse along monolithic platforms that just can’t deliver the levels of customer experience, productivity and profitable growth that are required or expected.

And let’s be clear here, we’re not necessarily talking mainframe systems from the mid-1980s. If you have been running the same enterprise content management platform for the last eight to ten years, it is likely to be hampering the growth and progress of your organisation.

Even if you have introduced new standalone apps to provide support in specific business areas, this will do little to improve your organisation’s overall performance. This is akin to fitting new windscreen wipers on an old wreck. They may stop you from crashing, but they won’t make the car go faster. In fact, a patchwork of fixes – in the corporate world, is likely to make it even more difficult for a business to work cohesively.

Too rigid to work

Persist with this monolith — let’s call it Legacy Systems 2.0 — and you will be increasingly faced with a mix of disparate and overlapping technologies that result in data sprawl, inadequate functionality, sub-par security and greater risk of non-compliance.

The only real solution is the progressive replacement of rigid monolithic architecture and its tightly coupled functions, with smaller, independent microservices that reside in the cloud and have the capacity to connect to each other through well-defined Application Programming Interfaces (APIs).

Unlike monolithic applications, it is possible to develop, deploy, operate and scale each component in a microservices environment independently, creating much greater technological freedom, meaning the best tool can be chosen for each specific problem, compared with the constraints of working within a rigid monolithic platform.

Moving away from the monolith

If that sounds like an attractive proposition, here is a tried and tested route for making the transition.

Start by auditing your current content across departments to identify gaps and inadequacies. This will also allow you to reassess your priorities and to draw up a ‘requirements list’ that will guide and inform your search for potential partners to deliver content services.

Next, using historic metrics as a baseline, assemble a set of appropriate KPIs against which you can measure the impact of any solution you implement. Include ‘softer’ measures, such as whether a new tool helps an employee better perform a particular aspect of their role.

Shortlist potential solutions (a good content services partner will help you make the best choice) and have users test them. Their input will help to highlight critical issues and processes that need addressing before any wider rollout.

At this point, you also need to think about how to migrate away from your legacy systems with the least disruption to either workflows or customer experience. This should form part of a detailed action plan for rolling out your chosen solution, and help you refine future iterations along the way. Again, a good partner will be able to advise on how best to do this.

With the new solution in place, you can begin monitoring its performance against your chosen targets. This will give you an idea of what’s working well and what could be working better.

You are now ready to elicit feedback from stakeholders who haven’t been involved in the new system’s implementation. Never having been associated with the project, they should be better placed to give an unbiased assessment.

If things have reached this stage, you can consider scaling up by taking the new solution to other teams and locations, tweaking and refining as you progress.

Tomorrow’s solution

While this core roadmap gives a broad sense of process, you will clearly need to adapt this to your own organisation, paying particular attention to issues of compliance.

Using this approach, you are on the way to creating a content services platform that has the ability to adapt to the rapidly changing demands of both marketplace and internal stakeholders, while also giving you the high levels of governance and security you need.

Better still, you could devolve technological development further by giving non-technical staff the opportunity to use low- or no-code tools to create their own applications — analysts are predicting that in just a couple of years almost three-quarters of new enterprise-developed applications are going to be built this way.

For firms in the financial services sector, the volume of content they need to handle has never been greater.

And this cannot be managed by merely updating what you were previously doing in an attempt to make centralised, expensive and unwieldy content repositories fit for a digital age. It just will not work.

Persisting along the road of yesterday’s solutions, rather than being the catalyst that accelerates innovation and brings new flexibility and resilience, your technology will be constraining content provision and process delivery. There is no choice but to introduce new technology that has the capacity to support your ambitions.

We have entered a new era of cloud-enabled content and shared repositories connected by common APIs. The reign of the technology monolith is over.