Ask most marketing leaders to describe their stack architecture and you’ll usually get a list of platforms: CRM, Marketing automation, Fabric, Analytics, Visualisation etc.,. Maybe a diagram showing how they all connect.
Useful? Yes. Architecture? Not really. That’s an inventory.
The distinction matters because some of the most consequential decisions in a marketing stack have very little to do with which vendor you choose.
Architecture is about the decisions that become painful to reverse.
- How do you define a customer?
- How is identity resolved when the same person appears differently across five systems?
- Which system owns which piece of data?
- How do platforms exchange information? In real time? In batches? Through APIs? Through an integration layer?
Those choices sit underneath the tools people actually interact with. They rarely appear on a vendor comparison slide, which is one reason so many “architecture reviews” end up reviewing everything except the architecture.
Without that distinction being evident to and appreciated by everyone sitting on the discussion
of ‘architecture review’ the exercise becomes anything except about the architecture.
A Simple Test
There’s a useful way to tell the difference.
Ask: Could we undo this decision by cancelling a contract and buying something else?
If the answer is yes, you’re probably dealing with tooling.
If reversing the decision means migrating large amounts of data, changing the assumptions built into several connected systems, rebuilding integrations, or redefining how the organisation thinks about customers, you’re dealing with architecture. Replacing an email platform is largely a tooling decision, in mosts cases. The interface changes. Some workflows need to be rebuilt. People complain for a few weeks. Eventually the new platform becomes normal. I said ‘in most cases’ because that is usually true, but not always. An email platform becomes an architectural dependency when it has quietly become the place where the organisation stores identity rules, suppression logic, lead-scoring definitions, consent records, campaign history or its only usable customer profile.
Changing how customer identity is defined across the enterprise is very different. That decision flows into reporting, segmentation, automation, attribution, personalisation and every downstream system that has quietly been designed around the previous definition.
Yet both decisions can sit next to each other in the same “martech modernisation” programme, with similar-looking project plans, budgets and steering committee approvals.
They shouldn’t be treated as if they carry the same consequences.
A tool does not become architecture because of its category.
It becomes architecture when the organisation embeds irreplaceable data, logic or decision-making inside it.
Why the Harder Decision Often Gets Less Scrutiny
There’s a fairly simple reason this happens. Tooling decisions are easier to evaluate. The licence cost is visible. The implementation cost is visible. The vendor provides a roadmap, a feature comparison and usually a very enthusiastic sales team.
Architecture decisions are different. Their real cost often doesn’t appear for two or three years. It shows up when a new platform can’t consume the existing customer model. Or when reporting teams discover that three systems mean three different things by “customer.” Or when a supposedly simple integration requires six months of remediation because of decisions made several projects ago.
By then, the original architecture discussion is long forgotten.
So the people approving the investment are being asked to compare a cost they can see today with a future cost that is harder to quantify, harder to explain and may not appear during their tenure.
It’s not surprising that the visible cost gets more attention.
It is still the wrong way to make the decision.
Architecture Has More Than One Layer
Customer data is usually where architecture discussions begin. It should not be where they end.
A marketing stack also has an identity architecture, a governance architecture, an integration architecture, a measurement architecture and increasingly an AI-control architecture.
The important question is not simply whether the CRM, automation platform and analytics environment exchange data. It is whether they exchange it using shared definitions, clear permissions, reliable interfaces and rules that survive a change of vendor.
That is the difference between integration and architecture.
Integration connects systems.
Architecture determines whether the connections remain useful when the business changes.
What This Changes
The answer isn’t to make every martech decision go through a six-month architecture process. That would create a different problem. The better approach is to separate the decisions that are genuinely architectural from the ones that aren’t.
Before approving a major martech initiative, ask explicitly:
Which decisions in this programme will be expensive to reverse?
Those are the ones that deserve a different level of scrutiny. They need people in the room who can think beyond implementation and licensing costs and ask what the decision does to the stack three years from now. Because a vendor audit dressed up as an architecture review will nearly always find another platform to replace, consolidate or upgrade.
What it usually won’t find is the architecture underneath the platforms. Nobody asked it to look there.