How Financial Services Firms Can Turn Technical Debt into a Data Surplus

Today, banks, credit unions and other financial services firms must cross many data chasms to keep customer information secure, accessible and functional for modern service application development and risk detection. Yet, the intertwined nature of aging data architectures and tangled data lineages make rapid application development difficult to accomplish—and buries organizations in technical debt.

What is Technical Debt?

Technical debt refers to the financial, time and risk costs of running services and applications from outdated system design or IT infrastructure.

Within financial services firms, IT architecture is built upon multiple databases and software systems in varying stages of their lifecycle. DevOps teams at financial firms are likely running multiple instances of Windows, Linux and numerous desktops connected across physical hardware and networks. Customer data is spread across Oracle, SQL, Hadoop and Hive databases and accessed via insecure mobile devices, mobile applications, online banking systems, lending platforms, banking centers and more. As individual platforms reach their usage limits, the code on which they were built can become outdated, cause latency issues and expose areas of risk in older systems.

On top of the costs of running, maintaining and deploying those systems, many institutions are stuck servicing old HR, CRM or other databases with monthly retainers to software vendors just to host and access data hosted within redundant systems. Often, there isn’t an easy way to offload this data into a useable format without tremendous cost and effort.

The result? Financial institutions want to upgrade and innovate but are stuck paying thousands in service and maintenance fees for data infrastructures that are too inflexible, outdated and risk-prone to modify.

This technical debt builds and builds until a company is stuck with an inert, messy platform that makes decommissioning legacy applications extremely complex; implementing new applications, like mobile banking, within the current data topology expensive; and detecting fraud and performing risk assessment like finding a needle in a haystack.

How Multi-Model and Graph Databases Cut These Costs and Cut Through the Data

Instead of trying to mine disconnected data within limited relational databases, multi-model graph databases reduce technical debt by correlating relationships between many different data types.

Deploying a multi-model graph database enables DevOps teams to start running different functions within the same platform, not multiple platforms, service layers and data centers that all need to be maintained.

On-demand visualization models show how application changes will affect the entire IT ecosystem, providing a better snapshot of the financial impact of application development and deployment for new tech-based customer services.

This structure increases the “plugability” of new SaaS, cloud solutions and integrated customer applications. With multi-model graph solutions automatically connecting new nodes and data formats, financial services firms can quickly innovate on top of their existing network and service layers without outdated code and data getting in the way.

In short, multi-model graph databases can turn DevOps from a cost center to an innovation center. The cost efficiency of having accessible data can be used to build and drive even more cost savings through:

Once technical debt has been transformed into a surplus of accessible data, data lineage becomes more much manageable and a strong strategic asset for financial services DevOps teams servicing business units that want to modernize their operations.

Gerard (Jerry) Grassi, P.E.
Senior Vice President, OrientDB, an SAP Company