Every platform project starts with the same artifact. Somebody opens a drawing tool and produces the stack diagram—Web SDK feeding AEP, AEP feeding CJA, identity graph in the middle, destinations fanning out to the activation tools, consent gating the whole thing.
It gets polished, it goes in the deck, it gets printed on a conference room wall. And it is genuinely useful for explaining how data moves.
But here's what I've come to believe after enough of these implementations: that diagram is not the architecture. It's a picture of the plumbing.
The actual architecture—the thing that decides whether the platform works or quietly rots—is the ownership map. Who owns the schema. Who can approve an identity change. Who is allowed to touch a merge policy. Who signs off before a new destination goes live. That map almost never gets drawn, and that's exactly why so many well-built platforms underperform.
When every arrow points the right way
The box-and-arrow diagram makes an implicit promise: that if the data flows the way the arrows say, the platform is sound. It isn't. Data flow is a necessary condition, not a sufficient one.
The failures I've actually watched happen weren't failures of plumbing. The data moved fine. What broke was decision-making about the data.
A few shapes this takes:
- A schema field gets added by whoever needed it that week, with no owner deciding whether it belongs, how it's governed, or what it means. Six months later nobody can tell you what half the fields are for, and your “single source of truth” is a junk drawer.
- Two teams define the same event differently because no one owns the definition. Now your CJA numbers and your downstream numbers disagree, and every meeting spends twenty minutes arguing about whose number is right instead of what to do.
- A merge policy gets changed to fix one use case and silently breaks another, because the person who made the change didn't know—had no way to know—who else depended on that identity behavior.
None of those are visible on the stack diagram. Every arrow is still pointing the right way. The platform is “working.” It's just producing outcomes nobody trusts, and the reason is that the diagram answered “how does data move” when the question that actually mattered was “who gets to decide.”
The parts of the stack that are really governance questions
If you look at an AEP/CJA implementation honestly, most of the pieces that people treat as technical are governance questions wearing a technical costume.
- Schemas look like a modeling exercise. They're really a standing agreement about what the business considers a customer, an event, a product—and agreements need owners, not just authors.
- Identity looks like a graph. It's really a policy: what counts as the same person, who is allowed to assert that two identifiers belong together, and who reviews it when the stitching logic changes. Get the policy wrong and the graph faithfully executes the wrong thing at scale.
- Merge policies look like configuration. They're really a shared contract about which version of the truth every downstream consumer sees. Change the config, you've changed the contract for everyone—whether you told them or not.
- Consent and governance labels look like compliance plumbing. They're really the rules for who may do what with which data, and they only hold if someone owns enforcing them rather than assuming the tool does.
- Destinations look like integrations. They're really the moment data leaves your governed environment and becomes someone's campaign, which is precisely why “who approves a new one” matters more than how the connector is built.
Every one of those has a technical surface and a human decision underneath. The stack diagram draws the surface. The RACI draws the decision. And the decision is the part that fails.
Four or five real questions
I'm not arguing for a heavyweight governance bureaucracy—those collapse under their own weight and everyone routes around them. I'm arguing for clarity on a small number of questions that, left unanswered, will absolutely come back to bite you:
- For each schema and each key field: who is accountable for it? Not who created it—who owns it continuing to make sense.
- For identity and merge policies: who must be consulted before a change ships, and who gets informed after? These are the changes with the widest blast radius and they're the ones most often made quietly.
- For new destinations: who approves data leaving the platform, and against what criteria—consent, purpose, governance labels?
- For the definitions everyone reports on: who is the single owner of “what this metric means,” so the number stops being up for debate?
That's it. Four or five real questions. If you can answer them cleanly, your platform will outperform a technically superior one where nobody can. If you can't, no amount of elegant plumbing saves you—you've built a very fast way to disagree.
The diagram that is actually load-bearing
The shift I'd push any team toward is this: stop treating the org chart and the governance model as paperwork you do after the real work. They are the real work.
The Web SDK integration is a solved problem with good documentation. “Who decides what a customer is” is not solved by documentation—it's solved by a human being with a name, owning it.
So when someone hands me the beautiful stack diagram, my first question now is almost never about the arrows. It's “okay, who owns each of these boxes, and who has to be in the room before this one changes?”
The answers tell me more about whether the platform will succeed than any amount of architecture ever could. If the answer is a shrug, the diagram is fiction. A pretty one, but fiction.
The reframe
Draw the second diagram.
The stack diagram tells you the platform can work. The ownership map tells you whether it will.
Draw the second one. Put names in the boxes. Decide who's consulted before identity changes and who approves data leaving the building. It's less satisfying than the architecture picture and it photographs terribly, but it's the diagram that's actually load-bearing.
A platform doesn't fail because the data couldn't move. It fails because nobody owned deciding where it should go.