No More Data Mess: Why Your MarTech Architecture Needs Owners and Decentralized Data

Monday, 9 AM, the marketing director is demanding to know why the ROAS on the Looker dashboard doesn’t match what the Performance Manager sees in the Ads Manager. Meanwhile, the data engineer is drowning in a 2000-line SQL pipeline trying to fix a UTM_source field that the CRM team changed without telling anyone.

If you think the solution to this is buying a new tool or “centralizing everything in a Data Lake,” you’ve already lost the battle.

Data Mesh emerges precisely when we accept that centralizing data creates a human bottleneck. It’s not software. It’s organizational architecture. In marketing, this means stopping treating data as a technical byproduct and starting to treat it as a Data Product delivered by those who understand the business.

Okay, but what does this thing actually look like in practice?

If you Google it, you’ll read that Data Mesh is a “socio-technical paradigm.” Translated from corporate speak: it means to stop treating data as a responsibility that one department throws into another’s lap and start treating it as a real product: with an owner, processing costs, and, above all, quality control.

The Data Mesh architecture rests on four pillars that, if you ignore one, the building collapses:

• Domains (Domain Ownership): The Performance team owns the customer acquisition data; CRM owns the retention data. Being an “owner” isn’t just having access; it’s having technical resources (like Data Engineers) allocated to the domain. If the Salesforce schema changes, the one who resolves it is the engineer sitting with the Sales team who understands the impact of this on hitting the target, not a central team that doesn’t even know what a “Lead Status” is.
• Data as a Product: Data isn’t “located” somewhere. It is delivered. This means it needs to be easy to find (catalog), reliable, and, most importantly, readable. If I need a 40-hour course to understand your conversion table, your product is bad.
• Self-Service Platform: This is where the central data engineer comes in, acting as a solutions architect. Instead of doing the ETL for everyone themselves, they build the technological ‘conveyor belt’ (BigQuery, dbt, Fivetran). The secret here is that this central team does not touch the domain’s data; they ensure the foundation is solid so that Marketing has the autonomy to plug in their data without needing permission or risking breaking the global architecture.
• Federated Governance: These are the global rules. “Every customer ID must be a SHA-256 hash.” “Every table must have an expiration date.” These are the laws that ensure domains can talk to each other.

The core idea of the architecture is the Domain.

Instead of a centralized data team trying to clean up everyone’s mess, each area takes responsibility for what it produces. The Performance team owns the Ads campaigns domain. The CRM team owns the email and push campaigns domain.

They don’t deliver “a spreadsheet” or “database access.” They deliver a product with documentation, an SLA, and most importantly: Data Contracts.

If your Data Mesh lacks well-defined contracts, you just have a distributed “Data Mess.”

Illustrative image generated with AI

The Data Contract is your only protection

For the engineer, the contract is a YAML file or a JSON Schema that validates the data input. If the Growth team tries to upload a conversion event without the transaction_id field, the pipeline breaks at the source, before polluting the tables.

For the director, the contract is the guarantee that the metric they see in the report has an owner. If the data is wrong, it’s not “IT’s fault.” It’s a failure in the source domain’s contract.

This solves the biggest integration problem: semantics. What’s the point of integrating Google Ads and Salesforce if the “Customer ID” in one is the email and in the other is a random hash that no one mapped? The contract forces this conversation before the first line of code is written.

But how do we “think” about this architecture (The trick)?

Thinking in Data Mesh means to stop “JUST” drawing data flow diagrams and start drawing responsibility boundaries as well.

Imagine Marketing is an independent factory. They have their own raw material (Ads APIs, Google Analytics, Pixel). In the old model (Monolithic), they sent this raw material to a central warehouse (the Data Lake) and waited for someone inside to do magic. In the Data Mesh, Marketing has its own assembly line. They deliver not just the running conveyor belt, but the product (the clean and modeled data) for the rest of the company to consume via Data Contracts.

The reality check for leadership

There is no “Data Mesh as a Service” on the corporate credit card.

There’s no point in hiring the most expensive tool on the market if your culture is still “store the data there and the analytics team will figure out how to clean/consume it.” Implementing this architecture hurts because it requires managers to understand governance and engineers to stop being dashboard “order takers.”

Data Mesh solves scale. If you have 5 channels, centralization works by shouting. If you have 50, you either distribute the responsibility, or you’ll spend the rest of your life fixing an attribution query that is useless.

The architecture is not about “where” the data is

You can have Data Mesh using a single Snowflake instance or separating everything into several. The physical location is irrelevant. What defines whether you are doing Mesh or not is:

• If the Facebook Ads pipeline breaks, who gets the alert on Slack?
• If the answer is “the central infra/data team,” you are still in the monolith.
• If the answer is “the MarTech Tech Lead,” congratulations, you’ve started to distribute the mesh.

Tip from the trenches: Don’t try to implement all four pillars at once. Start with the contract, but instead of forcing a single definition of each metric, focus on establishing interoperability standards in the contract.

This means the CRM domain can have its own activation logic and the Performance team another, as long as both respect the global Identity standard (the same customer ID, for example) and expose their rules clearly in the contract code. The domain’s autonomy ends where integration with the rest of the mesh begins. If you want your marketing data to be consumed by others, it needs to speak the federation’s language, even if the accent (the business rule) is local.

Conclusion

The remaining question for MarTech leaders is: is your team ready to take on governance and own their own data products, or is it more comfortable to keep blaming IT for the ROAS that doesn’t match?

At DP6, we understand that the transition to a Data Mesh architecture doesn’t happen overnight; it’s a journey of technical, but mainly cultural, maturity. Our experience shows that success isn’t just about choosing the right tool, but about designing governance processes that actually work in the day-to-day operation.

We support large companies on all fronts of this journey: from the strategic design of federated governance and definition of data contracts to the technical implementation of the data stack (like dbt, BigQuery, and Observability tools). The goal is just one: to ensure your Marketing team has the data it needs, with the autonomy it desires, and the quality the business demands.

Want to transform your “Data Mess” into a scalable, results-oriented architecture? Contact the experts at DP6 and let’s talk about how to structure your marketing data ecosystem.

Profile of the Author:

Matheus Felix | Data Engineer at DP6, working with MarTech and data engineering for almost 10 years. He is passionate about art, politics, music, and finding connections between non-obvious subjects.