Many data teams believe they already have a platform because provisioning has become a script. One command creates the bucket, another deploys the Spark job, another generates the CI pipeline. Tom De Wolf, Architect and Innovation Lead at the Belgian consultancy ACA Group, published a piece on martinfowler.com that dismantles this feeling by applying the CNCF Platform Engineering Maturity Model to data mesh. A transparency note: I worked as a Senior Data Engineer at Thoughtworks, the company the site is tied to, until June 2026.
This matters now because many companies invest in infrastructure as code expecting domain autonomy and end up with more fragmentation, not less. My thesis is simple: what most data platforms lack is not automation but the data product abstraction, and building it is a design decision, not a tool purchase.
Fast provisioning is not coherent architecture
To see why scripts don't add up, it helps to remember what data mesh asks for. Goedegebuure et al. (2024) consolidate practitioners' views on "the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance". Self-serve platform and data as a product sit side by side: the platform exists to serve products, not loose components. The problem, according to De Wolf, is that data technologies "typically lack the necessary abstractions for concepts like data contracts or data products".
The CNCF model has four levels (Provisional, Operational, Scalable and Optimizing), assessed across five aspects: investment, adoption, interfaces, operations and measurement. Per-component Terraform scripts live at the Operational level. They remove the ticket queue, but, as De Wolf describes, the developer is still alone in integrating networking, security roles, storage, pipelines and secrets.
The result is what he calls "Frankenstein" data products, similar on the surface because they use the same technologies but "architecturally inconsistent under the hood". For the argument, this shows that provisioning speed and architectural coherence are different things, and optimizing the first does not deliver the second.
What I learned by attaching guarantees to data
If automating components isn't enough, where is the value? My experience points to the guarantees that travel with the data. In recent years I architected pipelines on different clouds: GCP at Thoughtworks, GCP and AWS in a multi-client engagement at BairesDev, and I built an Azure platform at Programmers. In all these roles the task went beyond moving data: it was delivering data with SLAs and quality someone could hold us to.
At WEX, a US bank, that meant enforcing governance and compliance standards aligned with financial regulations and automating quality checks with Great Expectations. At BairesDev, I implemented observability with DataDog and Monte Carlo, using ML-based anomaly detection to enforce quality SLAs. The most concrete result came from WEX: the automated checks reduced critical data incidents by 30%.
What this proves for the thesis is that the gain didn't come from creating resources faster but from binding verifiable guarantees to the data. That is exactly what a data product abstraction should provide by default, instead of letting each team reinvent the same glue.
The interface is a design decision
Hence the central question: what should this data product interface own? At the Scalable level De Wolf describes, the developer declares input and output ports, transformation code and data contracts, and the platform injects "automated policy checks, audit logging, access controls, and data quality verification". In my reading, it needs to own four things:
- the contract, with versioned schema and guarantees;
- quality checks, running on every load;
- access, derived from the contract rather than requested by ticket;
- lineage, recorded at creation time.
No off-the-shelf tool decides this for you, because it is a choice about what the default path contains. Anjum (2026) concludes that "the evidence supports treating platforms as products, combining delivery metrics with developer experience surveys, and designing golden paths as enablers instead of mandates". In other words, the default path works when it makes builders' lives easier, and that requires deliberate product design, not a catalogue of modules.
The limit: not every company needs level 3
The strongest objection is about the bar. De Wolf states that the Scalable level is "the minimal level for success" for data mesh. For large organizations with many domains, I agree. But this is the opinion of a practitioner who leads data mesh at a consultancy that sells this kind of work, and the adoption curve he presents is conceptual, with no data behind it.
The empirical evidence suggests the bottleneck isn't always technical. Bode et al. (2023) report that "organizations have difficulties with the transition toward federated governance associated with the data mesh concept, the shift of responsibility for the development, provision, and maintenance of data products, and the comprehension of the overall concept". If shifting responsibility is already hard for those adopting the model, a small company with one capable central team may simply not need data mesh.
This doesn't weaken the thesis; it scopes it. Mesh or no mesh, whoever confuses scripts with a platform will face the same problem: fast components and inconsistent products.
Conclusion
The arguments converge on one point. Per-component automation fixes queues, not architecture; real value appears when guarantees travel with the data; and defining those guarantees is product design work, whether or not the company adopts data mesh.
My recommendation is concrete: before writing your next Terraform module, write the specification of one of your company's data products, with contract, quality, access and lineage. If your platform can't create that whole product from a single declaration, you don't have a platform yet. You have a set of scripts.
References
- Tom De Wolf (2026). The Data Product Platform Navigator. martinfowler.com, source newsletter.
- Bode, J.; Kühl, N.; Kreuzberger, D.; Hirschl, S.; Holtmann, C. (2023). Towards Avoiding the Data Mess: Industry Insights from Data Mesh Implementations. arXiv preprint 2302.01713 (later IEEE Access). “Our results show, among other insights, that organizations have difficulties with the transition toward federated governance associated with the data mesh concept, the shift of responsibility for the development, provision, and maintenance of data products, and the comprehension of the overall concept.”
- Goedegebuure, A.; Kumara, I.; Driessen, S.; Di Nucci, D.; Monsieur, G.; van den Heuvel, W.; Tamburri, D. A. (2024). Data Mesh: a Systematic Gray Literature Review. ACM Computing Surveys (arXiv 2304.01062). “The review provides insights into practitioners' perspectives on the four key principles of data mesh: data as a product, domain ownership of data, self-serve data platform, and federated computational governance.”
- Anjum, M. A. (2026). Platform engineering and internal developer portals: a multivocal literature review. Frontiers in Computer Science. “For practitioners, the evidence supports treating platforms as products, combining delivery metrics with developer experience surveys, and designing golden paths as enablers instead of mandates.”