HSBC moves from 65 relational databases into one global MongoDB database

HSBC is one of the world's most recognisable banking and financial services organisations, operating in over 60 countries and serving more than 40 million customers. However, with this scale comes a significant amount of operational complexity - not least in terms of how the bank delivers its applications and data models.

Speaking at MongoDB.Live this week, Narasimha Reddy, data designer at HSBC Commercial, explained how the organisation is looking to simplify its approach to application delivery by migrating away from 65 relational databases, into one global instance of MongoDB.

In practice this means that each country will be able to maintain its individual application requirements, but without having to operate a unique country database. A single data model is being created, which is not only saving on costs and resources for HSBC, but is giving it the freedom to drive forward its own data model design.

Reddy explained how the below image created a complex global data model for global applications, which created a high cost model at every step of the software development cycle, made it less flexible for changes, and led to higher costs on business as usual operations. He said:

Global entities have the same application running for most of its operating countries in the world. But it is not possible to have just one version of the application running for all the countries. Each country will have its own customisations to fulfil its local or regional functions and operations. And of course regulatory requirements.
That makes it impossible to maintain one version of the application and one data model, in the relational database world.
Consequently we end up having different code bases. We all know that the data model drives most of the system design. So what we end up having while using a relational database - one data model for each country and that makes it impossible to maintain one version of the application.

A global model

Reddy said that HSBC has been looking to achieve a global data model and consequently a global database, so that it can get to a truer version of a ‘global application'.

The benefits of this include reduced costs, flexibility and the ability to more easily run global analytics and reporting (with each country running on a single data model).

Historically, as per the image above, HSBC did have an application core program environment, which had most of an application's core functionality. But it couldn't have a single programme environment running for all the countries, due to the differences in data models and databases.

As such it would have to put a country specific program environment on top of the application's core environment to fulfil each country's specific application needs. So when any country user accesses the application, it ends up having its own execution path. And then the country specific program environment and core program environment together would access the country's specific database and process the application.

This is because each country has its own functions, fields, business logic interfaces, data rules, data life cycles and data access controls. As such, if a tweak is made to the data model, the program environment becomes incompatible with the changed data model and a new program environment would have to be stood up.

Most of HSBC's applications have been running for decades on iSeries, mainframe systems and DB2. Reddy said:

Due to all these concepts it becomes highly complex to design an application to run using a single instance and a single database for multiple countries.
This model brings additional consequences. We'll have to develop and apply another data model and database to run data analytics and reporting on global data. Which, of course, consumes additional resources. It's definitely taking cost in multiple different ways.

However, as per the image below, HSBC now has a new architecture. It now has operating countries across the globe using the same application, but the use of resources has reduced. It's now a one service environment, one database and one execution path for all the countries. This is made possible because of MongoDB's document model and the ability to map all the different table requirements for each country into a single collection, using sub-documents. Everything is simplified into one collection using country specific identifiers.

Reddy explained:

Local requirements for each country will be built into the application, but there's no need to maintain separate data models or separate databases anymore. We could easily design the global data model and database using the MongoDB JSON schema model. That brings data from all operating countries into one database and the application can run on just one database. Which is a lot of reduction in resource and maintenance cost.
Another benefit is to use the same database for global data analytics and reporting. We don't need to translate into another data model or another database to run the analytics and reporting from that particular data. All this brings big savings in resources and cost.
I have learned while using MongoDB that when a database is schema-less and provides powerful querying and indexing, I drive my data model design, not the database.