Legacy Modernization and Operational Data Layer

An Operational Data Layer (or ODL) is an architectural pattern that centrally integrates and organizes siloed enterprise data, making it available to consuming applications. It enables a range of board-level strategic initiatives such as Legacy Modernization and Data as a Service, and use cases such as single view, real-time analytics. An Operational Data Layer is an intermediary between existing data sources and consumers that need to access that data. Other terms sometimes used for this architectural pattern include Operational Data Store, Data Fabric, and Operational Data Hub. It is conceptually similar to a Master Data Management or Reference Data Management system.

Benefits

1. Unlock the value of previously siloed enterprise data and to power applications that can’t be served by existing systems.
2. An ODL can offer a “best of both worlds” approach, providing the benefits of modernization without the risk of a full rip and replace.
3. Possible to combine data from multiple legacy sources into a single repository where new applications, such as a customer single view or Artificial Intelligence processes can access the entire corpus of data.
4. Data Access APIs on top of the ODL provide a common set of methods for working with this data. When development teams need access to existing enterprise data, they can simply subscribe to the relevant API to access it from the ODL.
5. A cloud-based ODL can also benefit from the on-demand elasticity of cloud infrastructure. It’s easy to scale the ODL when an additional set of enterprise data is added, when new consuming applications are created, or when workloads grow.
6. When the ODL is built from a distributed cluster of nodes, it’s possible to achieve workload isolation by dedicating a specific replica of data to analytics queries.

Use Cases for an ODL

1. “Single view” describes a unified, real-time representation of all relevant information on a given entity. MetLife’s customer service organization, for example, had to navigate 70 different systems in 15 different screens. By unifying all customer data into one repository.
2. When legacy on-prem systems can’t be migrated but new applications are being deployed in the cloud, a cloud-hosted ODL can provide an intermediary layer.
3. Implementing an Operational Data Layer in front of legacy systems allows you to redirect consuming systems to the ODL, improving availability, helping to meet regulatory requirements, and reducing MIPS costs. At the same time, new apps – or new features built into existing apps – benefit from the option to revise the data model, supporting workloads that weren’t possible before.
4. Developing new mobile applications to extend customer engagement channels, exposing all the information that’s otherwise found on the web, in store, or via customer service.

Operational Data Layer model, with data loading.

The above solution presents two options for triggering the pipelines that capture the real-time changes in the MongoDB Atlas operational data store (ODS) and sync the data.

Success stories

HSBC implemented an Operational Data Layer to become the single source of truth. The ODL, enables HSBC’s development and architecture teams to meet the Banks’s strategy of using technology to make the bank “simpler, faster, and better.”

RBS implemented an Operational Data Layer – which they call an Enterprise Data Fabric – in order to improve data quality, reduce duplication, and simplify architectures to become leaner.