Concept
A layer names a responsibility: resolving who the customer is, choosing what should happen next, delivering it across channels. A product is a thing you buy from a vendor with a contract attached. Every architecture answers two separate questions, which responsibilities have to exist and which product carries each one, and the vocabulary of this industry runs them together so thoroughly that most people never notice the second question is being answered at all. One product can legitimately carry several responsibilities. One responsibility split across several products is usually how a stack starts to drift.
Why it matters
When someone says you need a CDP, they might mean that something has to own identity resolution, which is almost always true, or that you should buy a standalone CDP, which frequently is not. The first is a statement about architecture and the second is a statement about procurement, and they have different answers because they depend on different things. Conflating them produces two opposite failures that look nothing alike from the inside. In one, a team buys a product for a responsibility nobody has agreed to own, and the licence renews for three years while the profile stays as thin as it was. In the other, a team declines the product and assumes the responsibility is handled because a platform’s feature list mentions it, which is a claim about the software rather than about their own data.
A simple example
Two companies both need identity resolution, so both answer the first question identically. The retailer has stores, an app, a website, a loyalty scheme and a call centre, which means customer records arrive from systems the engagement platform never sees, and a profile assembled inside that platform can only ever resolve what passes through its own channels. The subscription business acquires, converts and serves entirely through email, push and its own app, so there is nothing to reconcile that the engagement platform is not already handling. Same responsibility, same answer to the first question, and a different honest answer to the second one.
The architecture view
The responsibilities stay the same. What moves is where the product boundaries fall around them.
This is the whole content of the three CDP and CEP patterns. The responsibilities do not change between them, and neither does the order they sit in. What changes is which vendor boundary encloses which responsibility, and that is decided by who owns the customer data, how many independent systems need to read the same profile, and what the organisation can realistically operate. The six criteria in the architecture decision work through that choice properly.
The mistake I often see
The recurring error is reading a layer diagram as a shopping list. Someone sees identity, decisioning and delivery drawn as three boxes and concludes that three purchases are required, when the diagram was only ever a map of responsibilities and says nothing about how many contracts it takes to discharge them. I have watched an organisation with one channel and one team buy a three-product stack because the reference architecture had three boxes in it. The mirror image is just as common and quieter: a product lists identity resolution among its capabilities, everyone treats the responsibility as settled, and nobody asks whether it resolves the identities this particular business actually has. A feature list describes the software. Only your own sources describe the problem.
Go deeper
For the six criteria that decide where the boundaries should fall, and the three patterns they choose between, read the CDP and CEP architecture decision. For the forces that pull those boundaries around in practice, Four Gravities maps them.
This node sits underneath the rest of Architecture Literacy. Read it before what a CDP is, what a CEP is and what decisioning is, because each of those names a responsibility, and the question of which product carries it stays open every time.