Was data mesh just a fad?

"Typically, there were multiple copies or slightly modified versions of the same data floating around, along with accuracy and completeness issues. Every mistake in the data would need multiple discussions and eventually lead back to the source team to fix the problem. Any new column added to the source tables would require tweaks in the workflows of multiple teams before the data finally reached the analytics teams."

"A polar opposite approach from a data lake, a data mesh gives the source team ownership of the data and the responsibility to distribute the dataset. Other teams access the data from the source system directly, rather than from a centralized data lake. The data mesh was designed to be everything that the data lake system wasn't. No separate workflows for migration. Fewer data sanity checks. Higher accuracy, less duplication of data, and faster turnaround time on data issues."

Centralized data lakes built by separate engineering or analytics teams caused misunderstandings, multiple modified copies, accuracy and completeness issues, and reliance on source teams to fix errors. Schema or column changes required coordinated workflow updates across teams, producing delays, data loss, and declining trust in centralized lakes. Data mesh assigns ownership and distribution responsibility to source teams and enables direct access from source systems, reducing migrations, duplication, and turnaround on issues while improving confidence in data quality. Data mesh requires a long-term commitment to maintain schemas that downstream systems can read, creating persistent implementation and maintenance challenges that frustrated many users.

Read at InfoWorld