无需独特实例的 Cloud DAM 自定义简单技术

asadul71

近，我一直在与已经开始使用（或计划使用）云/SaaS DAM 的客户合作。所有这些都是从旧产品平台迁移而来的，其中一些更传统地作为单实例解决方案托管，而另一些则是本地部署的。正在取代传统同行的云供应商是中端和高端 DAM 系统的混合体（按价格点衡量）。

经常出现的一个问题是需要定制产品，因为它缺乏某些关键的功能元素，或者存在会引起问题的用户界面问题（出于某种原因）。在某种程度上，可能会出现这样的情况：那些有动力聘请像我这样的顾问来帮助他们的 DAM 用户可能有模糊或不寻常的需求，但根据我的经验，所有 DAM 计划都会发生这种情况。我在实施 DAM 解决方案方面拥有大约 25 年的经验，我不记得曾经有哪个客户不需要其他人以前从未要求过的东西。  数字资产管理是一种本质上高度概念化的抽象活动。与 Web 内容管理之类的输出是可见的（网页等）相比，用户最终没有得到太多有形的东西。“有组织的资产”显然是一个高度主观的描述。因此，即使供应商在应用程序架构设计方面非常熟练，也总会缺少一些东西。

过去解决此问题的常用方法是创建自定义版本或（如果可行）一些复杂的配置来强制 DAM 应用程序提供所需的行为。正如 David Diamond去年在 DAM News 采访中谈到的那样，对于本地 DAM，这并不难处理，因为客户可以拒绝升级 乌克兰电话号码表  或推迟升级，直到与其部分定制版本的任何问题或冲突得到解决。对于云/SaaS DAM，这不是一个选择。尽管最终用户认为他们拥有自己的专用 DAM，但这只是软件造成的幻觉，而现实情况是“他们的 DAM”与供应商的所有其他客户共享。因此，当这些频繁出现的晦涩请求出现时，许多 DAM 供应商会用“我们不能这样做，这是一个 SaaS 平台，我们不能只为你改变这一点”（或者这样的话）来回应。达到这个效果）。为了尝试解决这些问题，现代 DAM 系统具有大量的配置设置，但即便如此，出于所讨论的所有原因，它们仍然无法涵盖所有​​可能发生的情况。

普通读者都知道，我曾经从事过 DAM 系统业务（甚至更早以前我也曾经开发过它们）。大约 11-12 年前，当我的雇主仍在提供产品时，我们就遇到了这个问题，这并不是一个新问题。理想情况下，我们希望只有一个可供每个人使用的平台，而不是维护许多不同的版本（同时仍然可以灵活地应用与核心 DAM 的其余部分隔离的定制）。通过这种方式，我们可以升级每个人，但自定义功能不会受到影响 - 这与供应商及其用户现在遇到的问题相同。正如《DAM》中经常出现的情况一样，演员和布景可能会发生变化，但基本情节保持不变。



我们设计了一种非常简单的技术，使我们能够做到这一点，并且这也同样适用于 Cloud DAM。我在极少数 DAM 系统上看到过类似的情况，但太多的系统没有看到类似的情况，或者即使看到了，供应商也让它变得不必要地过于复杂。我将在本文的其余部分描述其工作原理。我将尽力使描述尽可能简单，但这本质上是低水平和技术性的。

首先，这取决于拥有带有 API 的 DAM（最好是全面且功能齐全的 DAM）。API-First DAM 非常适合此目的，并且有很多原因可以解释为什么这些平台比那些不适合的平台更可取，但即使是具有经过改造的 API 的传统 DAM 仍然可以工作，尽管在方面灵活性较差可以实现什么目标。