Kopflose Architektur und APIs, die 2 Säulen der DAM-Integrierbarkeit

Um seine Aufgabe als "Single Source of Truth" für Medien erfüllen zu können, muss ein DAM in der Lage sein, sich in die wichtigsten Anwendungen des Informationssystems zu integrieren.

‍

Ein Unternehmens-DAM ist keine isolierte Insel innerhalb des Informationssystems (IS). Ganz im Gegenteil, als die "Single Source of Truth" für die Medienverwaltung ist es ein integraler Bestandteil dieses IS und daher in hohem Maße mit dessen Hauptanwendungen integriert.

‍

Zum Beispiel:

• die verschiedenen CMS(Content Management Systems), die zur Bereitstellung von Inhalten für Websites und Anwendungen verwendet werden 
• Die ERPs(Enterprise Resource Planning) und PIMs(Product Information Management), die wertvolle Informationen zur Produkttaxonomie enthalten.
• das CRM(Customer Relationship Management) und die CDP(Customer Data Platform), die die für die Anpassung der Inhalte erforderlichen Informationen speichern

In Bezug auf diese Systeme ist Enterprise DAM sowohl Lieferant als auch Konsument von Informationen. Seine Integrierbarkeit muss so stark wie möglich sein, um die Konsistenz der Inhalte (vor allem bei Produktinformationen), ihre Verteilung (über die richtigen Fronten und Kanäle) und ihre Personalisierung zu gewährleisten. Um dies zu erreichen, stützt sich DAM auf zwei wichtige Säulen: Headless Architecture und APIs.

‍

Enterprise DAM, nativ headless (und wir haben nicht den Kopf verloren)

Der Begriff der "kopflosen" Architektur kam Ende 2018 auf. Sein Aufschwung ist eng mit der Notwendigkeit verbunden, verschiedene Front-End-Anwendungen von einem einzigen Back-Office aus zu bedienen: Websites, mobile Apps, Bildschirmnetzwerke usw. Headless CMS wurde entwickelt, um dieses Omnichannel-Problem anzugehen. Seine Besonderheit? Während ein "klassisches" CMS ein Back-Office mit einem Web-Frontend (einer Schnittstelle zur Wiederherstellung von Inhalten) hat, ist das Headless CMS vergleichbar mit einem Back-Office ohne Front-End. Während die Inhalte im Backoffice gespeichert, organisiert und veröffentlicht werden, obliegt es den Entwicklern, Front-Ends zu entwerfen, die diese Inhalte konsumieren und anzeigen können. Aus diesem Grund verfügt das Headless CMS über eine Reihe von APIs, die Inhalte darstellen können. Ein solches CMS kann somit verschiedene Frontends bedienen, die mit unterschiedlichen Technologien entwickelt wurden.

‍

Während die Unterscheidung zwischen gekoppeltem und kopflosem System für CMS noch Sinn macht, wird sie für eine Digital Asset Management-Lösung nicht als solche verwendet. Der Grund dafür ist einfach: Das DAM ist von Haus aus headless, da seine ursprüngliche Aufgabe darin besteht, die von ihm gehosteten Inhalte für alle Kanäle verfügbar zu machen. Diejenigen, die wir heute kennen, und die noch unbekannten, die wir morgen brauchen werden. Dies setzt eine starke Kapazität zur Änderung der Formate dieser Inhalte voraus, aber auch die Fähigkeit, sie unter den besten Bedingungen bereitzustellen. 

‍

Hüten Sie sich vor Abkürzungen: Die Integration des DAM in eine Headless-Architektur bedeutet nicht, dass ein Plugin für das eine oder andere CMS verfügbar ist. Das Plugin mag ein einfaches Mittel sein, um von einem CMS aus den Asset-Baum eines DAM zu erkunden, aber es sagt nichts über die Fähigkeit aus, die Inhalte der Digital Asset Management-Lösung wirklich zu mobilisieren und bereitzustellen.

‍

DAM, sowohl Produzent als auch Konsument von API

Im Endeffekt geht es hier um die Reichhaltigkeit der von einem DAM vorgeschlagenen API, um den "richtigen" Inhalt aufzurufen. Mit anderen Worten: Übergeben Sie dem DAM die Informationen, die erforderlich sind, um ein Video im richtigen technischen Format (Auflösung, Verhältnis, Kodierung usw.) mit der verwendeten Sprache, mit oder ohne Untertitel usw. anzuzeigen. Indem sie eine solche Tiefe bietet, kann die API dem, was wir als Content as a Service (CaaS) bezeichnen, wirklich Substanz verleihen: die Fähigkeit, ein Asset mit genauen Merkmalen von jedem IS-Aufrufpunkt aus zu mobilisieren. 

‍

DAM benötigt diese Abfragetiefe auch über APIs für Drittanwendungen. Um zum Beispiel eine eCommerce-Plattform optimal zu bedienen, ist es im besten Interesse von DAM, sich auf die Produkttaxonomie zu stützen (um Assets zu klassifizieren und/oder zu kennzeichnen). Dazu muss man in der Lage sein, das PIM oder das ERP anzufordern, um diese Informationen abzurufen. Dasselbe gilt für Informationen über die Zielgruppe: Um Inhalte für einen auf einer Plattform angemeldeten Kunden anpassen zu können, muss das DAM in der Lage sein, Schlüsselinformationen (Land, Sprache, Kaufhistorie, Präferenzen usw.) aus einem CRM oder einer CDP abzurufen.

‍

Mit anderen Worten, ein Unternehmens-DAM ist auch eine Integrationsplattform: eine Umgebung, die die Nutzung der von anderen Anwendungen zur Verfügung gestellten APIs ermöglicht, um ihre Inhalte über ihre eigenen APIs besser wiederherzustellen. Ein API-Produzent und -Konsument innerhalb von Content-Architekturen, die zunehmend das Headless-Modell übernehmen. Mit einem Ziel vor Augen: die Nutzung von Inhalten, um besser auf die Herausforderungen einer Omnichannel-Kundenbeziehung zu reagieren.