There are several strategies for generating business use cases from data. These include Data Mesh, Data Driven and Data Centric. But which approach should you choose? While the Data Centric approach remains the most relevant, it is entirely complementary to the Data Mesh approach. Interview with two JEMS data experts.

Gentlemen, could you please introduce yourselves?

Pascal DURY : I’m vice-president in charge of data management and governance. I support our customers in all aspects of organizational determination around data governance.

Anthony LIBOR :  Hello, I’m vice-president for AI and Analytics, and I help our customers with their IS and Data transformation, to serve their new uses around data.

Could you remind us of the difference between Data Mesh and Data Centric?

Anthony :The Data Mesh approach breaks down a data platform by business domain. This is very useful in large organizations, where you need to adopt an iterative approach, and are driven by business use cases. The Data Mesh favors the distribution of responsibilities, as owners and processes can be defined for each data domain. The Data Centric approach complements this.

Pascal : To complete Anthony’s point, Data Mesh takes up the elements of Domain Driven Design. It’s not new, it’s a rebranding of things that have been around for a few years now, namely identifying data and organizing it according to a domain vision where each domain is responsible for its own perimeter (HR, marketing, production, etc.).

What is a Data Centric approach?

Pascal : The Data Centric approach considers that data is not just a consumable, but a company asset. It considers that every company has a reusable data asset, independent of the uses to which it is put. It aims to standardize information so that it can be used for all types of use, including data-driven dashboards, performance, predictive use with AI, etc.

Is it necessary to have a Data Mesh then Data Centric approach, or the opposite?

Pascal : The two are complementary. Let me explain: in JEMS terminology, to be Data Driven is to make data-driven decisions; I take data at its source, apply it to my use case and consume it. And I’d do the same thing again tomorrow for another use case. That’s all very well, but it’s ineffective in the long term, because data is seen as a consumable, not as a key company asset. If you adopt a Data Mesh approach without having a Data Centric approach, the limitations will be the same.

You have to be Data Centric, then Data Mesh, and avoid the consumerist Data Driven approach as much as possible.

We create the data asset that will then be consumed in uses that are, by nature, more or less organized into domains. If your data asset is huge, having a single team to manage it becomes very difficult, and you’ll lose agility. So we’ll distribute the asset across the various domains. We’ll have objects that are transversal between one or two domains, or even between all domains, and others that are mono-domain: this is the Data Mesh approach.

Anthony : I don’t quite agree with SAP (Security Assurance Plan). When you’re building a data platform, you’re necessarily driven by business use cases. Mainly for financial reasons. We’re going to organize the data as we normally do, by layer, following an organization by business domain. It’s similar to the Data Mesh approach!

On the other hand, we need to make this capitalization effort right away, to design objects that will be as reusable as possible, and that can themselves be enriched by other domains. And yes, I agree with you: a Data Centric approach is the best possible strategy from the outset.

In terms of cost, what’s the best approach?

Pascal : Well, there’s an extra cost involved in going from Data Mesh to Data Centric. It’s the same as going from Data Driven to Data Centric.

There are examples of companies who have taken this approach and realized that, in the long term, the Data Driven approach was not appropriate, and who have rebuilt their entire data architecture. Renault, for example, has rebuilt its entire data architecture based on a Data Centric approach, from which they build their Data Products.

What final advice could you give?

Pascal: Data Mesh requires a solid foundation of data governance. To say that business units should take responsibility for organizing themselves as they see fit is to plant the seeds of anarchy within the data system. In 3 years’ time, we’ll be going backwards because it’s not working.

Data Mesh is the application of federated governance. Federated governance means that at central level, we define a framework, the rules of the game: what we can do and what we’re not allowed to do. Once defined, the domains use these rules and apply those that concern them, adapting some to their specificities, and we have something that will work. That’s fundamental.

Anthony:  The trend in IS evolution, with the emergence of Microservices architectures, is to adopt a modular and elemental approach to the components we put in place to serve uses such as AI or digital applications that will consume data from data platforms.

My advice is to adopt a marketplace approach to data patrimony, building modular data counters to serve these uses.
But to get the best Time to Market, we need to capitalize on and reuse the asset by determining the right company objects.

“The product has a limited lifespan. Your data asset doesn’t, it’s immortal”.