– Emil Eifrem, co-founder and CEO of Neo4j,
Data expert Emil Eifrem explains how graph databases helped one of the world’s largest investment management companies overhaul their old systems
Numerous banking systems in use today date from the 1970s. And while many of these workhorses are functional, it’s getting more and more problematic to update or modify them.
In the worst cases, an upgrade means compromising a bank’s operations while an important upgrade is being implemented. After all, technology underpins every major banking process and requires the best infrastructure to serve today’s digital customers.
Ageing systems not only drive banks’ day-to-day operations, but also serve as the core IT enabler for new capabilities and growth. Yet many financial service institutions – even tier one, global operations – are saddled with outdated systems and architecture. At a time when banks face competition from standard and digital competitors, this presents a substantial challenge.
In an ideal world, full replacement is the best way to reduce complexity and better support business growth. However, such plans rarely leave the drawing board given the high costs and risks associated with such a course of action.
As a result, incremental change through upgrading and improving the underlying code is emerging as the pragmatic best practice. It’s an approach that is working well for investment management firm Vanguard.
Digital Transformation at a Large Investment Management Firm
Vanguard is one of the world’s largest investment management companies with more than $3.5 trillion in assets. It’s also the largest provider of mutual funds and the second largest provider of exchange-traded funds.With 17,600 employees, Vanguard serves more than 20 million investors in about 170 countries. Its founder, John Bogle, actually invented the concept of index funds.
Vanguard was able to move to a modern, microservices-based infrastructure by improving the management and quality of its legacy Java code base. Managers deemed a digital transformation was necessary, but some of those legacy Java archives had 4 million lines of code, much of which was redundant and needed to be pruned.
“Managing code is critical,” says John Lavin, Software Architect at Vanguard. Lavin points out that while companies like Vanguard focus on feature delivery, time to market and getting things out the door, “if you don’t make it easy to manage code, none of that gets done.”
Moving Java archives into microservices, however, requires managing a lot of moving parts, he adds. To tackle this, the team had started by managing services in a spreadsheet, compiled over the course of a year.
“We had a lot of different services in a lot of different states,” he said. “We tried to group things and document dependencies as best we could in the spreadsheet. But it really just wasn’t going to work.We realised that the management of our modules and services was really a ‘graph problem’.”
Graph databases are used to model complex problems more easily than other database approaches, in particular standard relational technology. Modeling this complexity using relational databases results in lengthy queries which are technically tricky to build and expensive to run, with performance faltering as the dataset size increases.
A Better Future?
Lavin and his team started with a simple graph data model, which allowed them to model the logic and connections inside their computer code, a productive way of managing, reading and visualising all this information. Even better, by using graph analytics, the team was able to measure their code against current software engineering best practices to see what needed to be improved to bring it in line with today’s standards.
In a very short time, the team was able to visualise relationships and reduce risk by simplifying and clearing up the code’s internal workings. Through the use of graph database technology, Vanguard’s IT team was able to gain full visibility into its heritage application, enabling it to perform impact analyses and fully modernise these older systems in a safe, phased way.
Internal stakeholders are also able to track progress, as graphical tools present, in a simple but highly accurate way.
“Our managers go right to the dashboards to see whether their metrics are trending up or down,” Lavin said. “Graph technology gives us a great way of pulling these metrics up, and keeping our code clean, because we’re all looking at it.”
And now, it’s not just about modernising old code. Graph database technology is now powering the future of application development at the company.
“When a project team goes into their planning sprint, we provide information about which services to use, where those services are being used, what’s partially built out and where developers may add their logic so that it makes sense in our overall architectural scheme,” Lavin confirms.
A low-risk, phased approach to modernisation using the modelling and analytical power of graphs may well prove to be the safest way of bringing 20th century banking systems safely into the modern era.
