Microservices and capability-based architecture are a huge step forward, but like all architectural choices they introduce complexity in the context of data, leading especially to its fragmentation and compartmentalization. Banks must strike a balance between keeping the organization's capabilities separate and therefore able to evolve independently, while also allowing data to flow freely between them.
Data is fundamental and must sit at the center of the architecture because it allows the organization to understand the customer and create personalized products and journeys. Data must be able to come together and connect with the separate capabilities, but without requiring them to reconfigure – that must be able to happen independently of the data.
Linking data across silos and adding structure – a layer of semantics and ontology – makes the data far more useful for banks. Consider a bank that wants to offer habitual gamblers the option to lock card payments when a specified spending threshold is reached. To achieve this, the bank needs the ability to analyze data in real time and link several data sources such as the category of vendor where the card is being used, the customer’s transaction history and the rules the customer has set for their card use.
Over the years, we have successfully used domain-driven design to decompose business logic, but the same principles have not been applied at the level of data. Concerns about fragmenting the data has caused us to build monoliths, initially data warehouses and more recently data lakes. These are a substantial improvement over data warehouses because they allow multiple schema and ways to interact with the data. But real gains will be realized only with Data Mesh architecture, in which data is federated but also linked by a system of semantics and ontology.3
Traditionally, data models have proved one of the most difficult aspects of the enterprise to change. As a result, APIs built on top of static data models have tended to be static as well. However, if we build a semantic layer between the data store and the microservices, this frees the APIs and allows them to evolve irrespective of the data model. They can now move independently at their own rate.