Enterprise Digital Asset Management

Blog

  • Access control, SSO and audit trails in an enterprise DAM

    Access control, SSO and audit trails in an enterprise DAM

    Access reviews are a strange exercise. Everybody focuses on who can get in, which is the part that is designed carefully and works. Almost nobody tests what happens when someone leaves, which is the part that is nobody’s job and fails silently.

    A DAM is unusually exposed here because it has more external users than most systems. Agencies, freelancers, printers, resellers, regional partners. All of those relationships end, and most of them end without anyone telling the DAM administrator.

    Short answer: get identity from the corporate directory through single sign-on, derive groups from directory groups, and make the leaver process remove access without any human in the DAM team being involved. Then make sure the audit trail records reads as well as writes, because for a media library the question is usually who downloaded it, not who changed it.

    A corporate security vestibule at night with two glass interlock doors, a cyan-lit card reader in the foreground, and a small amber indicator on a propped-open service door beyond

    Identity first

    Every access problem in a DAM traces back to how identity arrives.

    Local accounts are the failure mode. If administrators create users in the DAM by hand, then the DAM’s user list is a snapshot of who worked here at various points over the last five years. Nobody removes accounts, because removal is manual, nobody owns it, and it never causes a visible problem.

    Single sign-on fixes it structurally. Identity comes from the corporate directory. Someone leaves, HR terminates the record, the directory revokes, and every downstream system including the DAM loses access without anybody remembering to do anything. That is the whole value: it is not convenience, it is that deprovisioning becomes automatic.

    Standards, not proprietary schemes. OpenID Connect over OAuth 2.0, with JWT tokens. SAML is still common in the enterprise and is fine. A vendor’s own authentication scheme is not fine, and it is a reliable predictor of an integration that overruns.

    Groups from the directory. Roles should derive from directory group membership rather than being assigned in the DAM. Someone moves from the German team to the French team, their access follows, and no ticket is raised. If roles are assigned locally, they drift out of alignment with the org chart within a year and the access review becomes archaeology.

    External users are the actual risk

    Internal identity is usually solved by the time a DAM arrives, because the corporate directory already exists. External identity is not, and it is where the exposure sits.

    Four practices that address most of it:

    • Time-bound access by default. External accounts expire on a date and require renewal. Not a policy, a system setting. If your platform cannot expire an account, the compensating control is a monthly review, and monthly reviews decay.
    • Sponsorship. Every external user has a named internal sponsor. When the sponsor leaves or changes role, the external accounts they sponsored surface for review automatically.
    • Share links over accounts. For a printer who needs six files once, an expiring link is safer than an account. Accounts are forever unless somebody acts; links expire unless somebody acts. Prefer the default that fails closed.
    • Separate the consumption tier. Read-only distribution to a wide partner network should not run through the same mechanism as contributor access. Different risk, different controls, usually different licensing too, which is covered from the commercial side in what enterprise DAM costs.
    A blueprint of a federated sign-on flow in four vertical lanes with numbered token exchanges, a dashed trust boundary, and one amber arrow short-circuiting it

    What the permission model can and cannot do

    Be precise here, because there is a persistent gap between how DAM security is described in proposals and what products actually enforce.

    In most enterprise DAM platforms, including Cloudinary, permissions are administered at the folder or collection level rather than per individual asset. Folder modes determine how assets inherit from their placement, and that inheritance is the mechanism you design around.

    This covers the overwhelming majority of real requirements, and it has a practical implication worth acting on early: your folder structure is your permission structure. Design it to match your entitlement boundaries, which usually means business unit, brand, market and sensitivity, rather than to match a browsing hierarchy. Browsing is what facets are for, and that separation is the argument in designing a taxonomy people actually use.

    What this model does not give you is an independently queryable permission set attached to each individual asset that an application can evaluate at request time. If your security design assumes that, validate it against the product before writing it into a control framework, because retrofitting a folder structure after migration is a project and designing it correctly at the start is a workshop.

    Separately from library permissions, delivery of the asset itself needs its own control. Public URLs are public, which is correct for a marketing site and wrong for pre-release material. Access control on delivery covers restricted delivery and signed URLs, which is the mechanism that stops an unlisted address from being an open one.

    The nine questions security will ask

    Have written answers before the review, not during it.

    1. How does identity arrive, and from where? SSO from the corporate directory, or you will spend the meeting on this one alone.
    2. How is access removed? The question that fails. Answer must be automatic, via the directory.
    3. How are roles assigned? From directory groups, not by hand in the DAM.
    4. Who has administrative rights, and how many are there? The number should be small and you should be able to name them.
    5. How do external users get access, and when does it end? Time-bound, sponsored, reviewed.
    6. What is logged, and for how long? See below, this is usually where the second gap is.
    7. How do integrations authenticate? Service accounts with scoped credentials, never a person’s login. And any browser-originated write path uses server-side signing so keys never reach a client.
    8. Where is data stored, and does that satisfy residency requirements? Relevant under GDPR for any library containing images of identifiable people in the EU.
    9. What assurance does the vendor hold? SOC 2 is the usual expectation. Ask for the report, not the badge.

    Map the answers to NIST SP 800-53 control identifiers if your organisation reports against that catalogue. It takes an afternoon and it converts a bespoke evaluation into three lines in a register the security team already maintains.

    An off-white tractor-feed log strip unspooling across deep navy, one row marked with a cyan line and a missing section edged in amber

    The audit trail, and the part that gets missed

    Most systems log writes well and reads poorly. For a media library that is backwards.

    The questions that get asked after an incident are almost always about access rather than modification: who downloaded the unreleased product images, when did the agency last retrieve this file, which partner accessed material outside their territory. If your log records uploads and edits but not downloads and deliveries, none of those is answerable.

    What to require:

    • Reads as well as writes. Downloads, deliveries, share link access. Volume is higher, retention may be shorter, and it is the half that matters.
    • Identity on every entry, including for integrations. An entry attributed to a shared service account tells you a system acted, not which user caused it, so pass through the acting user where the API allows.
    • Retention that matches your obligations, not the vendor default. Ninety days is common and frequently insufficient; contract disputes surface a year later.
    • Exportable. The log must leave the platform and reach your SIEM. A log you can only read in a vendor interface is a log your security team does not have.
    • Immutable. Administrators should not be able to alter or remove entries. If they can, the trail is evidence of nothing.

    Test the controls, once a year, deliberately

    Design is not operation. The controls that fail are the ones nobody has exercised.

    Four tests, half a day:

    Deprovisioning. Pick a genuine recent leaver. Confirm access is gone, including any share links they created and any integration running under their credential. This test fails more often than any other.

    External expiry. Confirm an expired external account cannot authenticate and that its share links no longer resolve.

    Audit retrieval. Ask for every download of a specific asset in the last six months. Time how long it takes to produce. If it takes more than an hour, you do not have an audit capability, you have log storage.

    Delivery restriction. Take a restricted asset and confirm its delivery URL does not resolve without authorisation. Public-by-default delivery is a common and quiet misconfiguration.

    Record the results. That record is what turns your governance framework from a document into evidence, and it is what an auditor is actually asking for when they ask whether the control operates.

    The rights half of the compliance picture is in rights and expiry as first-class asset data, the architectural reason deletion and takedown are executable at all is in single source of truth is an architecture, and the wider context is in what enterprise DAM actually is.

  • The asset lifecycle, from brief to archive

    The asset lifecycle, from brief to archive

    Somebody searches the library, finds four versions of the same product shot, and has no way to tell which one is current. So they ask in a channel, someone answers from memory, and the wrong one goes to print.

    The library was not wrong. It contained all four. It just had no opinion about any of them, because the only states it modelled were present and absent.

    Short answer: an asset needs a state, the state needs to be visible in search, and every transition between states needs a defined trigger and a recorded actor. Seven states cover almost every enterprise case: draft, in review, approved, published, superseded, expired, archived. Without them a DAM is a well-indexed pile, and people go back to asking colleagues, because a colleague at least has an opinion.

    An isometric seven-station production loop connected by a raised cyan track, with a siding dead-ending at an amber buffer where carriers have piled up

    The seven states

    Draft. In the system, not usable. Working files, first cuts, material awaiting selection. Excluded from default search. The reason to hold drafts at all is that the alternative is people holding them on desktops, where they are invisible and unbacked.

    In review. Submitted for approval, with a named approver and a due date. Visible to the review path only.

    Approved. Cleared for use. This is the state most search should default to, and getting that default right is most of what makes a library trustworthy.

    Published. In active use on at least one surface. Distinct from approved, and the distinction matters: approved means allowed, published means currently out there. You cannot execute a recall without knowing which assets are published and where.

    Superseded. A newer version exists. Still resolvable, because things printed last year should keep working, but never offered as a new choice.

    Expired. Rights have ended. Not deleted, not usable. Findable deliberately, invisible by default. The behaviour required at this transition is the subject of rights and expiry as first-class asset data.

    Archived. Past active life, retained for record or legal reasons. Often on cheaper storage, often with slower retrieval, and that is fine as long as the metadata stays in the main index so people can find out it exists.

    Most implementations model three of these. The four that get skipped, published, superseded, expired and archived, are exactly the four that determine whether the library can be trusted.

    A state machine of seven labelled nodes with directed cyan arrows, the expired node amber and a dashed amber arrow bypassing review

    What each transition requires

    A state is only meaningful if the transition into it is controlled. Three properties per transition, every time:

    • A trigger. Human action, elapsed time, or an event from another system. Write it down. Transitions with no defined trigger do not happen.
    • A recorded actor. Who or what caused it, with a timestamp. This is your audit evidence and it should be a by-product of the transition, not something anyone assembles later.
    • A downstream consequence. What else changes. Search visibility, notifications, cache invalidation, an event emitted to consuming systems.

    That third property is where implementations usually fall short. An asset that becomes expired inside the DAM while remaining live on a public page has changed a field, not a state. The event mechanism that closes that gap is covered as pattern two in integration patterns for an enterprise DAM, and notification hooks are the usual implementation.

    The unofficial path

    There is always one. In most organisations it is approved-to-published without passing through review, because a deadline moved and someone with authority said go.

    Do not design it out. Design it in, with a record.

    An emergency path that requires a named override reason and a nominated approver gives you three things: the work gets done, the exception is visible, and the exception rate becomes a metric you can review. An emergency path that does not exist officially gets used anyway, off-system, and produces no record at all.

    Exception rate is one of the more useful numbers in the whole governance framework. A rising override rate means the standard path is too slow, which is a process problem you can fix rather than a compliance problem you can only report.

    Versions, variants and derivatives

    Three different things, routinely conflated, and the conflation is why version questions are so hard to answer.

    A version is the same asset, changed. Retouched, colour corrected, updated logo. Linear history, one current version, older ones retained. Platform-level version management handles this, and it should be automatic rather than a naming convention.

    A variant is a deliberately different asset in the same family. The winter version of the campaign key visual, the alternate model, the horizontal composition. These are siblings, each with its own lifecycle state, and they are not versions of each other even though people file them that way.

    A derivative is a mechanical output. The 400px crop, the WebP conversion, the CMYK export. Under a derivation model these are not stored at all, they are produced from the current version on request, which means they cannot be stale and they have no lifecycle of their own. That is the property discussed in single source of truth is an architecture.

    If your library treats all three as “files that look similar”, version questions become unanswerable, which is the situation described at the top of this piece.

    Where does retention fit?

    At the end, and it is the part almost every implementation defers indefinitely.

    Retention means two decisions per asset class: how long it is kept after active use, and what happens then. Records management has a century of thinking on this and the principles carry over directly, with one difference specific to visual material: images of identifiable people carry obligations under GDPR that do not attach to most other document types, so “keep everything forever” is not the risk-free default it appears to be.

    Practical guidance:

    • Set retention by class, not by asset. Product photography, campaign material, event photography, brand assets. Four to six classes covers most estates.
    • Default to retain, but define the exceptions. Material with identifiable people and material with expired third-party rights are the two classes where indefinite retention is an active risk.
    • Never hard-delete without an approval path. Deletion is the one irreversible operation in the whole system and it deserves a named approver and a record.
    • Archive is a state, not a location. Moving to cheap storage is an implementation detail. What matters is that the asset stays findable and its metadata stays in the index.
    A cold storage archive aisle receding into darkness, one shelf pulled out and lit from within by a cyan strip, a single amber lamp far down the aisle

    Starting before the asset exists

    The highest-leverage change available in lifecycle design is to start it at the brief rather than at the upload.

    When a shoot is commissioned, everything you will later ask a cataloguer to guess is already known and written down: the campaign, the products, the market, the intended channels, the licensing terms negotiated with the photographer. Capturing that as a record before any asset exists, then attaching arriving assets to it, converts cataloguing from an act of reconstruction into an act of association.

    The difference in both cost and quality is substantial, and it removes most of the contribution burden that drives the pattern in why DAM rollouts fail. It also means the rights fields are populated by the person who actually negotiated the rights, which is the only person who reliably knows them.

    Very few organisations do this. The ones that do have noticeably better libraries, and it is a process change rather than a platform feature, so it is available to you regardless of what you have bought.

    Keep the model small

    Seven states is not a target, it is a ceiling. If your workflow diagram has fourteen states and nine conditional branches, it will be implemented once, understood by two people, and routed around by everyone else.

    The test is whether a contributor can describe the lifecycle from memory. If they cannot, it is not a lifecycle, it is a specification, and specifications do not govern behaviour.

    The field model that carries the state is in the metadata schema an enterprise actually needs, status as a search facet is covered in designing a taxonomy people actually use, and the reason any of it matters is in what enterprise DAM actually is.

  • Single source of truth is an architecture, not a slogan

    Single source of truth is an architecture, not a slogan

    The slide says single source of truth. The architecture diagram behind it has the DAM in the middle with arrows going out to five systems, and every one of those arrows is labelled sync.

    That is not a single source of truth. That is six sources of truth with a preferred one and a nightly job that hopes.

    Short answer: you have a single source of truth when consuming systems hold a reference rather than a copy, and derivatives are produced on request rather than stored. Everything else is replication with a favourite. The test is concrete: change the master and count how many systems need to be told. If the answer is more than zero, you have copies, and copies diverge.

    A schematic split by a vertical rule: five amber store blocks each holding a copy with chaotic sync arrows on the left, one cyan master feeding five consumer panels through a single reference bus on the right

    The two architectures

    Replication. The DAM holds the master. Each consuming system receives a copy, stores it, and serves it. Sync jobs or events keep the copies aligned.

    This is how most enterprise estates actually work, and it is not stupid. It is what you get when the consuming systems were built to hold files, which most of them were. It has three permanent costs: storage multiplied by the number of consumers, a divergence window between the master changing and each copy catching up, and a class of bug where one copy silently stops updating and nobody notices for months.

    Reference and derivation. The DAM holds the master. Each consuming system holds an address. When a page renders, the asset is fetched from the media platform, transformed to the requirements of that surface, and cached at the edge.

    Storage is one master. The divergence window is zero, because there is nothing to diverge. And the failure mode changes from silent staleness to a visible outage, which sounds worse and is much better, because you find out immediately.

    The property that makes it work

    Reference-only architecture is only viable if the platform can produce any derivative on demand. Otherwise consumers legitimately need their own copies, because their requirements differ.

    That is the hinge. When the 400 by 400 thumbnail is a URL parameter rather than a file, the commerce platform does not need a copy. When the 16:9 hero crop is a parameter, the CMS does not need a copy. When the print-resolution CMYK version is a parameter, the print pipeline does not need a copy.

    The Cloudinary transformation reference is the full parameter vocabulary for that model, and responsive images covers the case where the required size is not known until the browser knows its own viewport, which no stored-variant approach can handle at all.

    Without derivation, “single source of truth” degrades into “the place the copies come from originally”, which is a genuinely weaker claim and should be described as such in your architecture documents.

    A lineage graph with a cyan root fanning through two generations to eleven leaves, edges carrying parameter chips, one amber branch carrying file icons instead

    Where the copies come from

    Four legitimate reasons systems keep copies. Each has a specific answer.

    Performance. “We cache locally so the page is fast.” Reasonable instinct, wrong solution. Edge caching on immutable derivative URLs gives you the same latency without the storage or the staleness. The mechanics are standard HTTP caching, and the key is a version token in the URL so a replaced master produces a new address rather than requiring a purge.

    Availability. “What if the media platform is down.” A real concern that deserves a real answer rather than a copy. Assess the delivery network’s actual availability, decide whether images are on your critical rendering path, and if they are, handle it with graceful degradation and a fallback rather than with a full replica you now have to keep current.

    Offline or air-gapped use. Print production, exhibition systems, field distribution. Genuinely legitimate. Export deliberately, mark the export as a point-in-time snapshot, and do not pretend it is synchronised.

    The consuming system cannot reference. Some legacy systems can only ingest files. This is the honest case for a scheduled sync, covered as pattern three in integration patterns for an enterprise DAM. Treat it as debt with a name, not as the architecture.

    Anything outside those four is a copy that exists because nobody asked whether it needed to.

    How do you test whether you have it?

    Five questions. Run them against your current estate and the answer will be uncomfortable and useful.

    1. Change a master. How many systems need to be told? Zero is reference architecture. Any other number is replication.
    2. Delete a master. What happens to the derivatives? They should stop resolving immediately. If copies survive deletion, you cannot execute a takedown, a rights expiry, or a privacy deletion request, and that is a compliance problem rather than an architectural preference.
    3. Count distinct masters, then count total stored files. The ratio is your replication factor. It should be close to one.
    4. Ask for a new aspect ratio for a new channel. If the answer is a batch job, you are storing variants. If it is a string change, you are deriving them.
    5. Who can edit the description field? If more than one system allows editing, you have two sources of truth for that field regardless of what the diagram says. The ownership discipline for this is in who owns which record.

    What single source of truth does not mean

    Three misreadings that cause real design errors.

    It does not mean one system holds everything. Product data belongs in the PIM and page structure belongs in the CMS. Single source of truth is per field, not per system. Every field has exactly one authoritative home, and different fields have different homes.

    It does not mean no caching. Caches are copies with a defined lifetime and an eviction policy, which is what makes them different from replicas. A cache that never expires is a replica wearing a disguise.

    It does not mean one physical store. Backups, disaster recovery replicas and archive tiers are all copies and all correct. The distinction is that none of them is independently editable. A copy that cannot be written to is not a second source of truth, it is durability. Version management and backup is the sanctioned form of this.

    Extreme macro of a mirror-flat lapped gauge block on a granite surface plate reflecting a cyan light bar, with an amber reflection from a misaligned second block

    Version identity is the part people get wrong

    If derivative URLs are immutable and cacheable, replacing a master has to produce new URLs. Otherwise you are choosing between short cache lifetimes, which costs performance, and stale images, which costs correctness.

    The standard solution is a version token in the address, so .../v1718294/asset.jpg becomes .../v1719901/asset.jpg when the master changes. Old URLs keep resolving to the old bytes, which is usually what you want for anything already printed or emailed, and new references pick up the new version automatically.

    Two consequences worth designing for deliberately:

    • Consuming systems must store the reference without the version, and resolve the current version at render time. Otherwise every consumer holds a pinned old version and you are back to replication, just with URLs instead of files.
    • You need an explicit policy on whether replacing an asset should update existing placements. Sometimes yes, a corrected logo. Sometimes no, an image in a published legal document. That is a business rule and it belongs in the asset lifecycle, not in whatever the platform happens to do by default.

    The compliance argument

    The strongest case for this architecture is not efficiency, it is that certain obligations are only executable under it.

    When a licence expires, the asset has to stop being served. When someone exercises a deletion right over a photograph in which they are identifiable, every instance has to go. When a claim is disputed, an image has to come down within hours across every surface.

    Under reference architecture those are one operation on one object. Under replication they are a search, across systems you may not control, with no guarantee you found everything. The rights model that depends on this is in rights and expiry as first-class asset data, the access half is in access control, SSO and audit trails, and the API properties that make it possible at all are in headless DAM.

    If you are still building the foundational case, what enterprise DAM actually is covers the ground underneath this one.

    Related field note

    Continue with A decision matrix for integration architecture.

  • Why DAM rollouts fail after a successful launch

    Why DAM rollouts fail after a successful launch

    Launch week is good. Attendance at training is high, the login numbers are strong, the executive sponsor sends a note. Everything is working.

    Month four, uploads have flatlined. Month six, the brand team has a folder again. Nothing broke. Nobody complained. The system simply stopped being where the work happened.

    Short answer: DAM rollouts fail because the DAM is a cost to contributors and a benefit to consumers, and nobody funds the contribution side. Uploading and describing an asset takes real minutes and delivers value to someone else, later. Unless that cost is removed, paid for, or made unavoidable, contribution decays to zero and the library ages out. Everything else people call an adoption problem is downstream of this.

    An isometric scene of a polished cyan-edged building with an empty entrance ramp, and a well-worn amber dirt path leading round it to a cluster of improvised sheds

    The asymmetry, precisely

    Two populations, opposite incentives.

    Consumers get immediate value. They find something in thirty seconds that used to take fifteen minutes. They need no persuading and they will use the system happily forever.

    Contributors pay the whole cost. Uploading, categorising, filling in rights fields, attaching approval evidence. It takes minutes per asset, it produces no benefit to the contributor, and the beneficiary is an anonymous colleague at an unspecified future date.

    Every metric that looks like adoption failure follows from this. Login counts stay high because consumers keep coming. Upload counts fall because contributors stop paying. And because consumption looks healthy on the dashboard, the decay is invisible for two quarters.

    An adoption curve chart with a cyan logins line spiking at launch then decaying, and an amber assets-uploaded line that never leaves the floor

    The four failure mechanisms

    1. Contribution is unfunded. Nobody’s objectives include cataloguing. The studio manager is measured on output, the agency is paid for deliverables, the campaign lead is measured on the campaign. Describing assets is the thing everyone does last and therefore does not do.

    2. The system is not where the work is. If contributing requires opening a second application, the fraction of people who do it is much smaller than you would guess. This is not laziness, it is context switching cost, and it is why the embedded picker pattern in integration patterns is an adoption intervention rather than a technical one.

    3. Search does not work well enough, early enough. Consumers give it two or three chances. If the first searches fail because the library is thin or the metadata is sparse, they revert to asking a colleague and never come back. Adoption is won or lost in the first month of consumer experience, which is why launching with a small well-described library beats launching with a large badly-described one.

    4. Nobody owns it. The programme had a project manager. The project ended. The role did not become a job, so schema drift, vocabulary sprawl and permission decay accumulate with nobody watching, and the governance framework becomes a document about a system nobody is running.

    The operating model

    Four roles. They do not each need a person, but each needs a named owner with allocated time.

    Platform owner. Accountable for the system: roadmap, vendor relationship, integrations, budget. Usually part of a marketing operations or digital function. Roughly 0.3 to 0.5 FTE at mid enterprise scale.

    Librarian. Owns the schema, the vocabularies and data quality. Reviews the metrics, approves vocabulary changes, fixes what is broken. This is the role most often left unfilled and the one whose absence is most visible after eighteen months. Between 0.5 and 1.0 FTE depending on ingest volume.

    Contributors. The studios, agencies and campaign teams who put material in. The critical design question is not who they are but whether contributing is in their brief and their contract.

    Consumers. Everyone else. Need nothing from you except that search works.

    The two that get missed are librarian and the contractual half of contributor. If your agency contracts do not specify that assets are delivered into the DAM with completed metadata, they will be delivered by email in a zip file, and you will pay someone internally to do the cataloguing that the agency was better positioned to do.

    Change your agency statement of work at the next renewal. It is the highest-leverage single intervention available and it costs nothing.

    An operating model figure with owner, librarian, contributor and consumer role cards, the contributor card amber with a broken dashed connector

    Removing the contribution cost

    Since contribution is the bottleneck, most of your effort should go into making it cheaper rather than into persuading people it matters.

    Automate every field you can. Dimensions, format, colour, detected subject, extracted text. None of these should ever be typed. Machine analysis on ingest, such as automatic asset analysis, populates the descriptive layer so humans only supply the business context that machines cannot know. This alone can halve the fields on the form.

    Set defaults from context. If the upload comes from the German product studio integration, market and business unit are known. Do not ask. Server-side upload presets let you bind those rules to the ingest path rather than to the person.

    Cut the form. Six required fields, not twenty. The reasoning is in the metadata schema an enterprise actually needs, and the adoption argument is simply that every field is a cost multiplied by every asset.

    Ingest where the work already happens. Watched folders, direct connectors from the studio’s tools, automated delivery from the agency’s system. The best upload is the one nobody performed.

    Catalogue at the point of highest knowledge. The person who commissioned the shoot knows what it is for. Two months later, nobody does. Capturing metadata from the brief at commissioning time, before the asset exists, is unusual and it works remarkably well.

    How do you tell if adoption is actually failing?

    Not from login counts. Four measures that tell the truth:

    • Contribution rate. New assets per month against your estimate of assets created per month. The gap is your shadow library, and it is the single most important number in the whole programme.
    • Metadata completeness on new assets. Falling completeness means people are gaming the form, which means the form is too long or the fields are unclear.
    • Zero-result search rate. Rising means the library is not keeping up with what people need, which is the consumer-side symptom of a contribution problem.
    • Proportion of published placements referencing the DAM. If your CMS can tell you how many images on the live site come from the DAM versus uploaded locally, that number is the closest thing to ground truth you will get. It is usually sobering.

    Review these monthly for the first year. Not because you will act every month, but because the decay is gradual and only visible as a trend.

    What actually works, in order

    Make the DAM the only path. Not a policy, an architecture. If the CMS can only place images that come from the DAM, the shadow library has nowhere to go. This is uncomfortable and it is the single most effective intervention available. Introduce it after search is good, never before.

    Fund the librarian. A funded 0.6 FTE beats a policy document and an all-hands presentation, every time.

    Launch small and well described. A thousand assets that are findable creates advocates. Fifty thousand that are not creates a reputation that takes two years to shake off. This is also why migration should leave most of the library behind.

    Fix agency and studio contracts. Metadata is a deliverable. Write it in.

    Publish the numbers. Monthly, to the sponsor, including the bad ones. A programme that reports honestly gets support when it needs it. One that reports only launch metrics gets quietly defunded at the next budget round.

    None of this is about training. Training is necessary and it is not the constraint. The constraint is that somebody has to pay the contribution cost, and until you decide who, the answer will be nobody.

    The taxonomy discipline that keeps search working is in designing a taxonomy people actually use, the state model behind it is in the asset lifecycle, the funding argument belongs in the business case, and the foundation is in what enterprise DAM actually is.

  • The DAM business case your CFO will actually sign

    The DAM business case your CFO will actually sign

    The business case says the DAM will save 400,000 a year in productivity. The CFO reads it, asks how many people will therefore leave the organisation, and the answer is none. The saving is discounted to zero and the case now rests entirely on the storage line, which is 12,000.

    Short answer: finance discounts benefits it cannot verify, and productivity claims with no headcount consequence are the most discountable claims there are. Build the case out of avoided spend you can point at on an invoice, plus risk you can quantify from incidents that have already happened to you, and treat productivity as a supporting argument rather than the main one. A smaller case built from verifiable numbers gets signed. A larger one built from estimates does not.

    A waterfall chart building from a baseline bar through four rising cyan benefit increments and two falling amber cost decrements to a net bar

    The four benefit categories, ranked by how much finance believes them

    1. Avoided external spend. Highly credible. Money currently leaving the organisation that will stop. Duplicate stock photography purchases, agency charges for re-supplying assets they already delivered, reshoot costs for material that exists but cannot be found, a separate CDN or delivery contract the DAM replaces.

    This is the strongest category because every item is an invoice. You can name the vendor and the amount. Nobody argues with an invoice.

    2. Avoided risk. Credible if you have incidents. Licence overrun settlements, takedown costs, rework after publishing an unapproved asset, audit findings and their remediation cost.

    The trick here is to use your incidents, not industry averages. An industry average is a benchmark; your own settlement from eighteen months ago is evidence. If you genuinely have had no incidents, do not manufacture the category, use it qualitatively instead.

    3. Avoided internal cost. Moderately credible. Contractor days spent on manual asset handling, agency retainer hours logged against asset supply, storage and infrastructure you will decommission.

    Credible to the extent it is contracted spend rather than salaried time. A contractor day is a real number. A salaried hour is not, unless the headcount actually changes.

    4. Productivity. Weakly credible on its own. Time saved searching, time saved on rework, faster campaign turnaround.

    All genuinely real, all correctly discounted by finance, because saved minutes distributed across sixty people do not reduce any budget line. Include it, quantify it honestly, and do not build the case on it.

    How to make the productivity number defensible anyway

    If you want the productivity benefit to survive scrutiny, it has to be measured rather than assumed. Three ways to do that, in ascending order of effort and credibility.

    Instrument the current state. Most DAM cases quote a search-time figure from a vendor’s white paper. Do not. Run a two-week diary study with twenty people recording time spent looking for assets and time spent recreating things that already existed. Twenty people, two weeks, a shared spreadsheet. The number will be lower than the vendor’s and infinitely more defensible.

    Tie it to a throughput commitment. “The team will deliver eighteen campaigns next year instead of fourteen, with the same headcount.” That converts productivity into output, which finance can verify after the fact. It is also a commitment, which is why people avoid it and why it works.

    Convert to avoided hiring. If the marketing operations team was going to grow by one to cope with volume, and now will not, that is a real number with a real budget line. This is by far the strongest form of the productivity argument and it is available more often than people realise.

    A cumulative cash flow curve dipping amber below zero, crossing to cyan above it about a third of the way along, with a marker at the crossing

    The cost side, honestly

    A case that understates costs gets one signature and then loses credibility for the next three years. Use the full stack from what enterprise DAM costs: licence, implementation, migration, storage, delivery, and people.

    Two lines to be specific about, because reviewers look for them and their absence is a tell:

    The ongoing people cost. A named role, or a named fraction of one, funded. If the case does not contain this, an experienced reviewer will assume the programme has no owner and price the risk accordingly. They will be right.

    Year two and beyond. Renewal uplift, growth in volume, and the second wave of integrations that always follows a successful first wave. A five-year model with realistic growth beats a one-year model with a good first-year discount, and total cost of ownership is the framing your finance team already uses.

    Where the real savings hide

    Two lines that are often larger than the headline productivity claim and almost never appear in the case.

    Delivery and bandwidth. If your organisation currently serves original-resolution images to web and mobile, the saving from automatic format and quality selection is a genuine, measurable infrastructure number. Serving modern formats to browsers that support them typically cuts image payload substantially, and the Cloudinary image optimization documentation covers the automatic format and quality mechanism, with WebP and AVIF support now broad enough that this is not a hypothetical.

    Get your current monthly image bytes from your CDN, model the reduction, and price it at your actual rate. It is one afternoon of work and it produces a number from an existing invoice, which puts it in benefit category one rather than category four.

    There is a revenue side to this too, which is worth stating carefully rather than overclaiming: image weight is a primary input to Largest Contentful Paint, and page performance affects conversion. Do not put a conversion uplift number in the case unless you can run the test. Do mention the mechanism.

    Storage multiplication. If every crop and format is a stored file, you are paying for the master times some multiple, forever. Count the distinct masters in your current library, count the total files, and the ratio is your multiplier. In a derived-rendition model it goes to one. That arithmetic is covered from the architecture side in single source of truth is an architecture.

    Extreme macro of a watch escape wheel and pallet fork under a raking cyan light, one tooth discoloured amber

    Benefits to leave out

    Three that weaken a case by being in it.

    “Improved brand consistency.” Real, important, and unquantifiable. It reads as filler in a financial document. Put it in the strategic narrative, not the model.

    “Better collaboration.” Same problem, worse. Finance has seen this phrase in every business case for twenty years and it carries no information.

    Vendor-supplied industry benchmarks. “Organisations typically see a 30% reduction in…” Any experienced reviewer knows where that came from. One statistic sourced from the party selling you the thing damages the credibility of every other number in the document.

    Structure the document like this

    Six sections, ten pages maximum. Longer documents are read less carefully, not more.

    1. The problem, with evidence from your organisation. One incident, one measured number, one quotable line from the diary study.
    2. What is being proposed, in one paragraph, without vendor names.
    3. The cost model, five years, all six lines, with assumptions listed separately so they can be challenged individually.
    4. The benefit model, four categories, each labelled with its confidence, and each traceable to a source.
    5. Payback and sensitivity. When does it turn positive, and what happens if benefits land at half. A case that survives its own downside test is a case that gets signed.
    6. What happens if we do nothing. Usually the strongest section, and usually the shortest. Rights exposure that is already running, migration cost that grows every year you wait, and the specific thing that broke last quarter.

    Then commit to measuring it

    The final paragraph should name the metrics you will report at six and twelve months, with the baseline stated now. Duplicate ratio, search zero-result rate, image bytes served, licensed assets with a valid expiry date on file.

    This is unusual enough that it materially improves your chances of approval, and it also means the benefits get realised rather than assumed. Programmes that do not measure post-implementation are the ones that quietly stop being used, which is the pattern described in why DAM rollouts fail.

    Build the requirement set that generates your quotes from the requirements checklist, and if you are still establishing what the category does at all, start at what enterprise DAM actually is.

  • Migrating a million assets without losing provenance

    Migrating a million assets without losing provenance

    The migration plan says twelve weeks. Week one moves four hundred thousand files without incident and everybody relaxes. Week nine is still going, because somebody noticed that the folder names encoded the campaign, the campaign is not a field in the target system, and eleven months of context evaporated on the way across.

    Short answer: a DAM migration is a metadata project with a file copy attached, not the other way round. Most of what makes an asset useful lives outside the file, usually in folder paths, filenames, spreadsheets and people’s heads. Extract that first, map it explicitly, validate the mapping on a sample, and only then move bytes. And leave most of the library behind, because most of it is not worth the cost of bringing.

    An isometric mass migration: thousands of matte tiles on the left, a cyan transfer bridge with an inspection arch, ordered tiles on the right, and a few amber tiles face down with tags stripped

    Where the context actually lives

    Before you plan anything, go and look at where meaning is currently stored. In a typical enterprise estate it is in five places, and only one of them is the file.

    • Folder paths. Usually the richest source. /2025/Campaigns/AutumnRange/DE/Approved/ carries year, activity, campaign, market and status. That is five fields, encoded positionally, undocumented, and inconsistent after the third reorganisation.
    • Filenames. Version numbers, crop indicators, photographer initials, client codes. Also positional, also undocumented, also inconsistent.
    • Embedded metadata. IPTC and EXIF fields, where they survived. Check with ExifTool rather than assuming. Most production pipelines strip these on export, so coverage is usually far lower than people expect.
    • Side files and spreadsheets. The tracking sheet the studio maintains. Nearly always the best source of rights information, and nearly always in a shared drive nobody mentioned in the discovery workshop.
    • People. Which is not migratable, which is why the discovery interviews have to happen before anyone’s notice period starts.

    Write an extraction plan for each of the first four. The fifth is why you do this now rather than later.

    The sequence

    Nine steps. Skipping any of the first four is how twelve weeks becomes nine months.

    1. Inventory. Count distinct masters, not files. Hash everything and group by hash. The duplicate ratio you find is the first real number in the project and it is usually somewhere between 3:1 and 8:1. It also tells you how much of the migration you can simply not do.

    2. Profile. For each source of context, measure coverage. What percentage of assets have a parseable folder pattern, a usable filename convention, embedded metadata, a spreadsheet row. This determines the mapping strategy and it is a day of work.

    3. Decide what moves. The single most valuable decision in the project. Criteria that work in practice: accessed in the last two years, or referenced by a live placement, or carrying third-party rights, or part of the current brand system. Everything else stays where it is, in a read-only archive, reachable but not migrated.

    Expect this to eliminate somewhere between fifty and eighty percent of the library. That is not data loss, it is declining to pay to move things nobody will ever open. Everyone finds this uncomfortable and everyone who does it is glad afterwards.

    4. Map fields explicitly. Source expression to target field, one row per rule, written down and reviewed. Regular expressions over paths and filenames, lookups against spreadsheets, defaults for the rest. This artefact is the migration; the code is just an implementation of it.

    5. Dry run on a stratified sample. Two thousand assets chosen to cover every folder pattern you found, not two thousand at random. Random samples miss the weird corners, and the weird corners are the whole problem.

    6. Review the sample with the people who own the material. Not with the migration team. The cataloguers and brand managers will spot in ten minutes what an engineer cannot spot at all, because they know what the values are supposed to mean.

    7. Migrate in waves, grouped by source pattern rather than by volume. Each wave validates the mapping rules for that pattern before the next one runs.

    8. Reconcile every wave. Count in, count out, checksum match, required-field completeness. A wave that does not reconcile does not get signed off, and the next wave does not start.

    9. Cut over reads before writes. Point consumers at the new system while the old one is still writable, then close writes on the old system once traffic is stable. Reversing that order is how you end up with two live systems and a merge problem.

    A field mapping figure with mostly clean cyan one-to-one lines, three converging many-to-one lines, and two amber source slots with drop icons

    What gets silently lost

    Five things, and the word to notice is silently. None of these throws an error.

    Folder-encoded context, if you copy the tree as a tree instead of parsing it into fields. The most common single failure, and the most expensive, because it is only detected months later when search does not work.

    Version relationships. Which file superseded which. Usually encoded in filenames, usually discarded, and once gone it is unrecoverable because the information was never anywhere else.

    Usage history. Where an asset was published. Rarely captured anywhere and therefore rarely migrated, which matters the first time you need to recall something.

    Rights terms, if they lived in a spreadsheet rather than a field. This one has legal consequences, and it is worth doing manually for the licensed subset even if everything else is automated. The field model to migrate into is in rights and expiry as first-class asset data.

    Approval state. Often expressed as a folder called Approved, which is exactly the kind of thing a naive path copy turns into a directory nobody looks at.

    Do you migrate the derivatives?

    No. This is one of the few genuinely easy calls in the project.

    If your source library contains a master plus fourteen crops and format variants, migrate the master. In a platform where renditions are derived from a URL parameter rather than stored, the fourteen variants have no reason to exist on the far side, and the transformation reference covers what replaces them. You will reduce the volume to be moved by an order of magnitude and eliminate a whole class of “which crop is current” questions permanently.

    Two exceptions worth handling deliberately. Hand-retouched variants are not derivatives, they are separate masters, and they need identifying before you delete anything. And any derivative whose URL is referenced by a live external system needs a redirect or a replacement reference, which is the same problem as any URL change.

    For the mechanics of bringing material in at volume, the migration documentation covers bulk approaches, and the command line interface is generally the more practical tool than hand-rolled scripts for anything above a few thousand assets.

    A migration burndown chart with a cyan staircase line above a dotted linear plan, and one amber plateau where validation stalled

    How long does it actually take?

    Depends almost entirely on metadata quality, not on volume. Two useful reference shapes:

    Well-described library, consistent conventions, good embedded metadata. Six to ten weeks for a few hundred thousand assets, and most of that is validation rather than transfer.

    Inconsistent conventions, minimal embedded metadata, context in people’s heads. Four to nine months for the same volume, and the variance is entirely in how much manual cataloguing you accept versus how much you leave undescribed.

    The lever is step three. Every asset you decide not to migrate is an asset you do not have to describe, and describing is the expensive part. Teams that migrate everything spend the difference on cataloguing material nobody will search for.

    The thing that actually derails it

    Not technology. Scope creep dressed as quality improvement.

    Halfway through, somebody proposes fixing the taxonomy while we are in here. Then improving the descriptions. Then adding the fields we always wanted. Each is individually reasonable and collectively they turn a migration into a re-cataloguing programme with a migration attached, and the go-live date moves twice.

    Migrate to the schema you designed, with the data you have. Improve afterwards, as business as usual, against the metrics in designing a taxonomy people actually use. A live system with adequate metadata beats a perfect one that is still three months out, and the difference in adoption between those two outcomes is enormous.

    Before any of this, be sure you have decided what you are migrating away from and why. Why the shared drive stops working covers the diagnosis, headless DAM covers what you need from the target platform’s API to script any of this, and if the destination is still open, alternatives to a traditional enterprise DAM is worth reading before you commit. The foundation is in what enterprise DAM actually is.

    Related field note

    Continue with DAM maturity models without duplicate files.

  • Rights and expiry as first-class asset data

    Rights and expiry as first-class asset data

    An agency invoice arrives with a demand attached. A photograph on your German landing page has been in use for fourteen months beyond its licence. Nobody did anything wrong. The person who negotiated the licence left, the person who built the page never saw the contract, and the contract itself is a PDF in a system the marketing team does not have access to.

    That is not a compliance failure caused by carelessness. It is a data model failure, and it is entirely preventable.

    Short answer: rights have to be structured fields on the asset, not a document filed somewhere near it. Licensor, licence type, permitted uses, permitted territories, start date, end date, and the identifier of the underlying agreement. Then expiry has to fire an event that changes the asset’s state automatically, because a report that expiry has happened is not a control. It is a notification that a control was absent.

    A wax-sealed contract with a visible date stamp on a matte black surface under a raking cyan light, with a wall of out-of-focus print proofs behind and one lit amber

    The gap, precisely

    Draw the chain for a licensed photograph and the break is obvious.

    The contract lives in a contracts or procurement system, owned by legal. The asset lives in the DAM, owned by marketing operations. The published page lives in the CMS, owned by the web team. Three systems, three owners, and no field anywhere that joins them.

    So the question “is this image licensed for this use, today” cannot be answered by any single system, and answering it requires a person to hold all three contexts at once. That person exists in most organisations, knows this is a problem, and is one resignation away from the whole thing becoming unanswerable.

    The fix is not to move contracts into the DAM. It is to put the terms on the asset, as data, with a reference back to the agreement of record.

    The field model

    Nine fields. This is the smallest set that answers the questions that get asked.

    • Rights status. Controlled list: owned, licensed, restricted, expired, unknown. Unknown is a legitimate and important value. Assets whose provenance you cannot establish exist in every library and pretending otherwise just hides them.
    • Licensor. Who granted it. Controlled where possible, because agency names spelled five ways defeat every report you will want to run.
    • Agreement reference. The identifier in the contracts system. Not the PDF. A link that survives the PDF being reorganised.
    • Licence type. Royalty free, rights managed, editorial only, work for hire, employee-created. Determines which of the remaining fields matter.
    • Permitted uses. Controlled list: web, print, paid social, out of home, internal. Multi-select.
    • Permitted territories. Controlled list from whatever market codes your organisation already uses. Do not invent a second geography vocabulary.
    • Start date and end date. Actual dates, indexed and queryable. Perpetual is a null end date, not the string “perpetual” typed into a text box.
    • Depicted persons or property. Whether identifiable people or private property appear, and whether releases exist. This is the field that connects to privacy obligations.
    • Restrictions note. Free text for the things a controlled list cannot express. Every rights model needs one escape hatch and exactly one.

    Every one of those except the note is filterable, which is the entire point. Rights status = licensed AND end date < 90 days from now is a query that takes a second and replaces a quarterly panic.

    The enforcement mechanics matter as much as the model. Fields defined loosely at the interface but not at the API are fields your integrations will populate incorrectly, which is why typed, centrally defined metadata with validation on every write path is worth checking for specifically. The general argument is in the metadata schema an enterprise actually needs.

    A gantt-style rights timeline with cyan licensed windows, a vertical today rule, and three amber expired bars still in use

    What has to happen on expiry

    This is where most implementations stop short, and the shortfall is the whole risk.

    A date field with no behaviour attached produces a report. Reports get emailed to a distribution list, the list contains people who have moved roles, and the report is read for two months and then never again. Meanwhile the asset stays live.

    What expiry has to do, in order:

    1. Change the asset state to expired, automatically, at the boundary. Not “flag for review”. Change the state.
    2. Remove it from search defaults, so nobody picks it for a new placement. It should still be findable by someone deliberately looking for expired material, because that is a legitimate archival need.
    3. Emit an event so downstream systems can react. Unpublish the placement, purge the cache, notify the page owner. Notification hooks are the standard mechanism, and the integration patterns for consuming them are in integration patterns for an enterprise DAM.
    4. Notify at 90, 30 and 7 days, to a named owner rather than a list. Renewal is often possible and cheap; discovering the need on the expiry date is neither.

    Point three is the one that separates a DAM that reduces risk from one that documents it. If the asset can expire in the DAM while remaining live on a page, you have moved the problem rather than solved it, and the reason that happens is almost always that the CMS holds a copy instead of a reference. That is the argument in single source of truth is an architecture.

    Where privacy obligations attach

    Worth being clear about, because it is regularly missed: an image of an identifiable person is personal data. The obligations under GDPR attach to the photograph itself, not only to the database row that references it. Similar reasoning applies under the CCPA framework in California.

    Practically that means three things your rights model has to support:

    • Identifying which assets depict a given person, so that a deletion or objection request can actually be executed. If you cannot query this, you cannot comply with it.
    • Recording the lawful basis, usually a model release, and where it is held.
    • Executing deletion across derivatives, which is straightforward when renditions are derived from one master and genuinely hard when fifteen copies live in five systems.

    That last point is a good argument for the derived-rendition model on grounds nobody expects. Deleting one master removes every derivative. Deleting one master in a stored-variant estate starts a search.

    An engineering schematic of a rights clearance gate with three sequential interlocks, one token stopped amber at the second and vented to a hold tank

    What a DAM does not do

    Two honest limits, because the category oversells here and it is worth knowing before you write a policy around it.

    It does not enforce rights outside itself. Once a file has been downloaded it is gone. Watermarking, tracking pixels and access logging tell you what was taken, not what was done with it afterwards. Anyone selling you enforcement rather than governance is selling you a feeling.

    Permissions are usually not per asset. In most platforms, including Cloudinary, access is administered at the folder or collection level, with folder modes determining inheritance, and delivery restriction handled separately through mechanisms like access control on delivery. That combination covers the great majority of real requirements. What it does not give you is an independently queryable permission set attached to each individual asset, so if your rights design assumes that, validate it against the product before it becomes a control in a framework. Structure your folders to match your entitlement boundaries and this is a non-issue; retrofit it later and it is a project.

    Start with the assets that already scare you

    Do not begin by modelling the whole library. Begin by answering one question: which currently published assets carry third-party rights, and when do they end?

    In most organisations that is a few hundred assets, not a few hundred thousand. Capturing rights properly for those takes days rather than months and removes almost all of the near-term exposure. Everything else can be filled in as assets are touched.

    That is also the finding an auditor will ask for first, which makes it the highest-value thing in the whole governance framework to have working. How the rights state fits into the wider set of state transitions is in the asset lifecycle, the access half of the problem is in access control, SSO and audit trails, and the case for the whole category is in what enterprise DAM actually is.

  • Designing a taxonomy people actually use

    Designing a taxonomy people actually use

    The taxonomy workshop produces a beautiful structure. Seven levels deep, mutually exclusive at every branch, exhaustively covering the material. The person who built it can find anything in it in four seconds.

    Nobody else can find anything in it at all, and within a year half the assets are sitting in a top-level folder called To Be Sorted.

    Short answer: stop building a tree and build facets. A tree forces one classification and requires the user to guess the designer’s mental model. Facets let several independent dimensions intersect, so anyone can start from whichever one they happen to know. Three to six facets with governed vocabularies will outperform any hierarchy you can design, and they are far easier to maintain.

    A card index drawer pulled half out of a dark cabinet, front tabs neat under a cyan light, rear tabs degrading into mismatched handwritten additions in amber shadow

    Why deep hierarchies fail

    Three reasons, and only the third is about the design.

    Users do not know where things go. A hierarchy asks you to reproduce the classifier’s reasoning. Is a photograph of a product being used by a customer filed under Product, under Lifestyle, or under Campaign? Any answer is defensible, which means the filer guesses and the searcher guesses differently.

    Real material does not partition cleanly. Taxonomy in the strict sense) requires mutually exclusive categories. Marketing assets are not mutually exclusive. A single image is simultaneously product photography, spring campaign, German market, approved, and licensed until 2027. A tree makes you pick one of those as primary and hide the rest.

    Depth multiplies error. Each level is a decision with a failure rate. Seven levels at ninety percent accuracy each gives you a bit under fifty percent chance the asset is where anyone expects. That is not a training problem, it is arithmetic.

    The facet model

    Replace the single hierarchy with a small number of independent dimensions. A query is the intersection.

    A typical enterprise set:

    • Asset type. Photography, illustration, logo, video, document, icon. Shallow and closed. Rarely more than a dozen values.
    • Business context. Brand, business unit, or product line, depending on how your organisation is actually shaped. This one mirrors the org chart and therefore needs a refresh path when the org changes.
    • Subject. What is depicted. The largest vocabulary and the one most worth basing on a standard rather than inventing, since the Getty vocabularies already cover most subject, material and place terms.
    • Market or locale. Where it may be used. Closed list, taken from wherever your organisation already maintains market codes.
    • Status. Draft, in review, approved, superseded, expired. Small, closed, and the single most valuable facet in the set, because it is what turns a library into something you can trust.
    • Rights. Owned, licensed, restricted, expired. Also small, also closed, and it carries the legal exposure described in rights and expiry as first-class asset data.

    Six facets, each shallow, each independently selectable. That structure answers “approved product photography cleared for Germany” without anyone knowing a folder path, and it answers “everything expiring next quarter” too, which no tree does.

    Note what is not in the list: date and campaign. Both are usually better as filters over structured fields than as facets, because they are continuous or unbounded, and unbounded facets become scroll lists nobody reads.

    Two taxonomy trees compared: a deep narrow amber corridor of single-child nodes, and a shallow wide cyan tree with cross-cutting facet chips beneath it

    How deep should a facet go?

    Two levels. Three at the absolute limit, and only for subject.

    The reason is that a facet is displayed as a list you scan, not a path you traverse. Past about thirty visible values, scanning fails and people stop using the facet. If a dimension genuinely needs more values than that, it wants type-ahead search rather than a browsable list, and that is a different interface affordance.

    The practical rule I use: if a facet value has fewer than about five assets under it and is not going to grow, it should not be its own value. Merge it upward. A vocabulary with two hundred terms where a hundred and forty are used once is a vocabulary that has failed and is generating noise.

    Governing the vocabulary

    This is the part that determines whether the taxonomy is alive in three years or fossilised.

    Someone owns each vocabulary. Named. With a documented process for proposing, approving and retiring terms. Unowned vocabularies grow monotonically, because adding is easy and removing is frightening.

    Additions require a case. Not a hard case, but a stated one: what search failed without this term. That single question kills most requests and improves the rest.

    Synonyms map to a preferred term. Auto, Car, Vehicle and Automobile should be one concept with three non-preferred labels, not four terms. ANSI/NISO Z39.19 is the standard covering exactly this construction and is worth reading once before you build.

    Deprecation is a state, not a delete. Retire a term and remap existing assets. Never delete a term that is in use, because the assets do not disappear, they just become uncategorised.

    Review quarterly, with data. Term usage counts, zero-result searches, and facet click-through. Half an hour of numbers prevents years of drift.

    Where does free tagging fit?

    Somewhere between “useful” and “a slow-motion disaster”, depending entirely on governance.

    Open tagging feels democratic and produces product, products, Product, product-shot and prodshot inside a quarter, at which point the tag facet is noise and people ignore it. If you want the flexibility, the workable compromise is a two-tier arrangement: a governed vocabulary that drives facets and filters, plus a free-text keyword field that feeds full-text search only and never appears as a facet. Users get to write what they like, and the navigation stays clean.

    Automated tagging changes this calculation somewhat, and it is worth being precise about how. Machine analysis is consistent, which is its main advantage over human tagging: it will call the same thing by the same name every time, which is exactly what human taggers fail to do. It is also frequently generic, and it does not know your business vocabulary. Cloudinary’s asset analysis will reliably tell you an image contains a person, a chair and daylight. It will not tell you it is the Q3 campaign key visual.

    So the sensible split is: machine tags populate the subject facet and full-text search, humans populate business context, status and rights. Machines are good at what is in the frame and useless at what it is for.

    A search refinement figure with a pool of assets narrowing through four filter bands, one amber band letting almost nothing through

    How do you tell if the taxonomy is working?

    Four numbers, collected quarterly. Same discipline as the schema review in the metadata schema an enterprise actually needs, and often the same meeting.

    • Zero-result rate. Proportion of searches returning nothing. Above about ten percent and your vocabulary does not match how people talk. Read the actual failed queries; they will tell you which terms are missing in the users’ own words.
    • Facet usage distribution. Which facets get clicked. A facet nobody uses should be demoted to a plain field. This is the metric that gives you permission to remove things.
    • Term concentration. If ten percent of your terms carry ninety percent of the assets, the vocabulary is too coarse in the middle. If most terms have one asset, it is too fine.
    • Time to first useful result. Hard to instrument precisely, easy to observe. Sit with five people, watch them find something, and count the steps. Twenty minutes of observation beats a month of analytics.

    Do not do this in a workshop

    The most reliable way to build an unusable taxonomy is to design it in a room with the six people who know the material best. They share assumptions the rest of the organisation does not have.

    Build the first draft from evidence instead: the search logs you already have, the folder names people actually created, and the words used in the briefs that commissioned the material. Then test it on people who were not in the room, with real retrieval tasks, before it goes anywhere near production.

    The taxonomy is not a deliverable, it is a running service. Treating it as a project that finishes is the reason so many of them are dead by year two, which is one of the mechanisms behind why DAM rollouts fail. It also has to survive the state changes described in the asset lifecycle, and it only matters at all because of the argument in what enterprise DAM actually is.

    Related field note

    Continue with Designing localization workflows for human and agent operators.

  • Integration patterns for an enterprise DAM

    Integration patterns for an enterprise DAM

    The DAM goes live and works. Six months later there are eleven integrations, four of them written by a contractor who has left, two of them polling every sixty seconds for changes that happen twice a week, and one that nobody can turn off because they are not sure what breaks.

    That is not a technology failure. It is what happens when eleven integrations get built as eleven decisions instead of as instances of four patterns.

    Short answer: almost every DAM integration is one of four patterns. Reference by URL, event-driven push, scheduled synchronisation, or embedded picker. Pick deliberately, because the wrong choice is not wrong on day one, it is wrong in month nine when the volume changes. The default should be reference by URL, and everything else needs a reason.

    A large orthographic schematic of a central media core with eight labelled satellite systems, four line treatments for four integration patterns, and two amber point-to-point connections crossing untidily

    Pattern one: reference by URL

    The consuming system stores a URL, not a file. When a page renders, the browser fetches the asset directly from the media platform, with the required transformation expressed in the URL itself.

    Use it for anything rendered to an end user. Websites, applications, emails, partner pages, product feeds. This should be your default and it covers more ground than people expect.

    Why it wins. There is one copy of the asset, and it lives in the system of record. Update the master and every surface updates. Add a new size and it is a string change. Nothing to sync, nothing to invalidate, no storage duplicated across five systems.

    The prerequisite is that the platform can produce derivatives from the URL. If it cannot, this pattern degrades into “reference the original and let the browser download 4MB”, which is worse than the alternatives. Cloudinary’s URL delivery model is the reference for what to look for: the transformation is part of the address, the result is cached at the edge, and the origin is untouched.

    How it fails. Two ways. Someone hardcodes a transformation string across the codebase and it becomes unchangeable, which is solved by named presets or a small helper. And the delivery domain becomes a hard dependency on your critical rendering path, which is a real availability consideration and belongs in your architecture review.

    Pattern two: event-driven push

    The DAM emits an event on a state change and the consuming system reacts. Asset approved, so publish it. Licence expired, so unpublish it. Asset replaced, so purge the cache.

    Use it for anything where a state change must cause an action within minutes, and for keeping downstream indexes current.

    Why it matters for governance. This is the mechanism that turns policy into behaviour. An expiry date in a field is a report. An expiry date that fires an event is a control, which is the distinction drawn in the governance framework. Cloudinary’s notification system covers upload, moderation and transformation events, which is the typical set.

    How it fails. Reliably, and always the same way: nobody handles redelivery. Webhooks arrive more than once, arrive out of order, and occasionally do not arrive. Your handler must be idempotent, must verify the signature, and must have a reconciliation job behind it that catches what was missed. Teams that skip the reconciliation job discover the gap during an incident, which is an expensive way to learn it.

    Four small pattern cards in a row showing point-to-point, hub and spoke, event driven and embedded widget topologies, the point-to-point card visibly tangled and tinted amber

    Pattern three: scheduled synchronisation

    A job runs on a schedule, pulls changed assets or metadata, and updates the target system.

    Use it for systems that genuinely cannot accept a reference or an event. Print production, legacy ERP, offline distribution, partner drops, and anything behind a boundary that will not allow inbound calls.

    Why it is the last resort. It creates a second copy, which creates a divergence window, which creates the question “which one is right” that the DAM existed to eliminate. It is also the pattern most likely to still be running in five years after everyone forgot why.

    How to make it survivable. Sync on a cursor rather than a full sweep, so cost scales with change rather than with library size. Record what was synced and when. Make it restartable. And give it an owner, because an unowned scheduled job is a future incident with a date on it.

    How it fails. Full-table syncs that took four minutes at launch and take six hours at year three, running into the next window and overlapping with themselves.

    Pattern four: embedded picker

    The DAM’s asset selection interface is embedded directly in the consuming application, so an author picks an asset without leaving the CMS, the commerce admin or the campaign tool.

    Use it for any human-facing authoring workflow. This is the single highest-leverage adoption intervention available to you, and it is consistently underrated in architecture reviews because it looks like a UI concern.

    Why it matters. People use the path of least resistance. If choosing an approved asset requires opening a second system, searching, downloading, and uploading, a meaningful fraction of your authors will use the file on their desktop instead. Embedding removes four steps and, with them, most of the shadow library. Media library widgets are the standard mechanism.

    How it fails. Authentication. The picker needs to know who the user is without a second login, which means the embedding application has to pass identity properly. Get this wrong and you have built a beautiful component that everybody dismisses because it asks them to log in again.

    An isometric conveyor loop carrying tagged parcels between four station blocks, with one station jammed amber and parcels backed up behind it

    Point to point versus a hub

    At three integrations, direct connections are fine. At eleven, they are a maintenance liability, because every consuming system has its own understanding of your schema and every schema change is eleven coordinated deployments.

    The usual correction is a thin integration layer that owns the mapping, so schema changes land in one place. Two cautions from having watched this go wrong:

    Do not put the hub on the read path. Rendering should go direct to the delivery URL. A hub in front of image delivery is a bottleneck and an availability risk for no benefit.

    Do not let the hub accumulate business logic. It should map and route. The moment it starts deciding which crop a channel gets, you have a second system of record and you are back where you started.

    How do you keep integrations from rotting?

    Four practices. None are clever and all are skipped.

    • A register. Every integration listed with its pattern, owner, credential, and what breaks if it stops. This document takes an afternoon and it is the difference between a controlled estate and archaeology.
    • Service accounts, not personal ones. An integration running under a departed employee’s credential is an outage scheduled for the day IT does its access review. This is also an audit finding, covered in access control, SSO and audit trails.
    • Server-side signing. Any write path from a browser gets signed requests generated server-side. Keys never reach a client. There is no acceptable exception to this.
    • Cache headers you chose. Long max-age on immutable derivative URLs, with a version token so a replaced master produces a new URL rather than requiring a purge. The HTTP caching guide covers the mechanics, and getting this right is most of the win described in delivery is part of your DAM.

    The decision, compressed

    Ask two questions per integration and the pattern falls out.

    Does a human select the asset? If yes, embedded picker for the selection and reference by URL for the rendering. If no, continue.

    Does the consuming system need the bytes, or just the address? If the address, reference by URL. If the bytes, event-driven push where the system can receive calls, scheduled sync where it cannot.

    That is genuinely the whole decision tree. The complexity in most estates comes from making this choice implicitly, once per project, under delivery pressure, rather than deciding it once as an architecture standard.

    Before you build any of it, settle which system owns which field, because an integration that moves a field between two systems that both allow editing is not an integration, it is a future data quality incident. That map is in who owns which record, the API surface these patterns depend on is in headless DAM, and the architectural principle underneath all of it is in single source of truth is an architecture. For the wider context, what enterprise DAM actually is.

  • DAM, PIM, CMS and MDM: who owns which record

    DAM, PIM, CMS and MDM: who owns which record

    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.

    Four labelled quadrant panels reading DAM, PIM, CMS and MDM connected by cyan token-carrying lines, with two amber connectors doubled back on themselves

    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.

    Four isometric matte filing volumes holding different record shapes, connected in a ring by thin cyan bridges, one bridge amber and broken in the middle

    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.

    A responsibility matrix grid with six domain rows and four system columns, solid cyan for ownership, hollow for consumption, amber in three contested cells

    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:

    1. 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.
    2. 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.
    3. 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.