The argument always starts the same way. Product marketing wants alt text managed in the PIM because it belongs with the product. The web team wants it in the CMS because it belongs with the page. The DAM team wants it on the asset because it describes the image.
All three are right, which is why the argument never resolves on its merits.
Short answer: the question that settles it is not “where does this belong” but “which system is authoritative for this field, and where does everything else get it from”. One system owns each field, everyone else references. Alt text describes the image, so the DAM owns it. The PIM and CMS read it. That rule, applied consistently, resolves nearly every boundary dispute in an afternoon.
What each system is actually for
Strip the feature overlap and each one has a distinct job.
DAM owns the visual and rich media object and everything intrinsic to it. What the asset depicts, who made it, what rights attach, which version is current, how it is allowed to be rendered. The category definition is broader than that in practice, but the intrinsic-to-the-asset test is the useful one.
PIM owns product information. SKU, specifications, dimensions, materials, pricing structure, category placement, and the localised marketing copy per market. Product information management exists because product data has hundreds of attributes, dozens of locales, and a supply chain of contributors, and no CMS handles that shape well.
CMS owns page structure and editorial content. Which components sit on which page, in what order, with what copy, in which locale, published when. A content management system is a composition tool, and its record is the page or the component, not the things it references.
MDM owns golden records for the entities the whole enterprise shares. Customer, product identity, supplier, location. Master data management is upstream of all of the above and mostly invisible to the marketing side, which is why it gets left out of these conversations and then turns out to be the thing defining what a product even is.
The authority rule
Write this down and put it in the architecture decision record, because it is the whole framework:
For every field, exactly one system is authoritative. Every other system that displays it holds a reference, not a copy. If a second system must store the value for performance, it stores it as a cache with a defined refresh, and it is never edited there.
The failure this prevents is the one that costs the most: two systems that both allow editing of the same field. That produces divergence, and divergence in a field like licence expiry or product dimension is not an inconvenience, it is a defect with legal or commercial consequences.
The corollary is that “we’ll sync it both ways” is almost always the wrong answer. Bidirectional sync between two systems that both allow edits is a conflict resolution problem, and conflict resolution problems get solved by whoever wrote the integration, at 4am, badly.
The boundary map
Field by field, here is where authority usually lands. This is not universal, but the exceptions should be deliberate and documented.
The DAM owns: the master file and its renditions, what is depicted, photographer and creator, licence terms and expiry, model and property releases, approval state, colour profile, asset-level version history, and alt text.
The PIM owns: SKU and product identifiers, specifications and attributes, category and taxonomy placement in the commerce sense, per-market product copy, pricing structure, and the association between a product and its assets.
The CMS owns: page and component structure, editorial copy that is not product copy, navigation, publication scheduling for pages, and the choice of which asset appears in which slot.
The MDM owns: the canonical identity of products, customers, suppliers and organisational units, and the reconciliation rules between source systems.
Note where the product-to-asset relationship sits. It belongs in the PIM, not the DAM, because the relationship is a fact about the product rather than about the image. The DAM holds the asset; the PIM holds the statement “these six assets depict this SKU”. Getting this backwards is common and it makes the DAM into a shadow product catalogue.
The two genuinely contested boundaries
Most of the map is uncontroversial. Two areas are not, and pretending otherwise wastes a lot of workshop time.
Alt text and image descriptions. The case for the DAM is that the text describes the image, so it should live with the image and be reusable everywhere the image appears. The case for the CMS is that good alt text is contextual, and the same photograph legitimately needs different alt text on a product page and in a news article. Both are correct.
The workable answer is two fields, not one argument. The DAM holds a default description of what the image shows, which is intrinsic. The CMS may override it per placement, which is contextual, and the override is the exception rather than the norm. The MDN guidance on the img element and the WCAG overview both support this reading: alt text serves the function of the image in context, and the context is not always known at asset level.
Crops and renditions. The PIM wants a square product image. The CMS wants a 16:9 hero. Historically both got a stored file, produced by someone, kept somewhere, going stale independently.
The clean answer removes the argument entirely: neither system stores a crop. Both request one from the DAM by parameter at the point of use. When renditions are derived rather than stored, there is nothing to own, because there is no artefact. Cloudinary’s transformation model is the reference implementation of that pattern, and it turns a governance dispute into a URL. This is the same argument made from the delivery side in single source of truth is an architecture.
Do you need all four?
No, and most organisations should not buy all four.
- Under a few hundred products with simple attributes: the CMS can carry product data. Skip the PIM until the attribute count or locale count makes it painful, which is usually somewhere around a thousand SKUs or five markets.
- Single brand, single market, no external distribution: the CMS media library may genuinely be enough, and adding a DAM adds an integration without adding an answer. The threshold is covered in why the shared drive stops working.
- MDM is worth its cost when several systems each independently define what a product or customer is. If only one system defines it, that system is your master data management and you do not need a separate one.
What you should not do is buy a system to solve a problem another system already owns. A DAM bought to fix product data will not fix product data, and a PIM bought to manage images will manage them badly, in a schema designed for attributes.
How do you decide when two systems both offer a feature?
Three questions, in order:
- Which system holds the record this field describes? Alt text describes an image; the image lives in the DAM. Dimensions describe a product; the product lives in the PIM. This resolves most cases outright.
- Which system’s users maintain it? If cataloguers maintain a field and cataloguers work in the DAM, putting the field in the PIM guarantees it stays empty. Authority should follow the workflow where possible.
- Which system can enforce it? A field with a controlled list and validation in one system and free text in the other is not a real choice. Enforcement wins, because unenforced fields become inconsistent fields, which is the argument in the metadata schema an enterprise actually needs.
Write the answers into an ownership matrix and get it signed by the owner of each system. That single artefact prevents more integration rework than any other document in the programme, and it becomes the input to integration patterns for an enterprise DAM.
If you are still establishing what the DAM half of that map is responsible for, what enterprise DAM actually is covers it.