Headless Architektur

Die Headless-Architektur und APIs als Eckpfeiler der DAM-Integrationsfähigkeit

Ganz nach dem „Single Source of Truth“-Prinzip muss sich das DAM nahtlos in die wichtigsten Anwendungen eines Informationssystems eingliedern können. Aber wie kann die Plattform mithilfe der Headless-Architektur und der erweiterten API-Funktionen des DAM einfach in das Informationssystem von Unternehmen integriert werden?

Ein DAM für Unternehmen darf nicht als isoliertes Konzept des Informationssystems (IS) angesehen werden. Denn es handelt sich um einen zentralen Aspekt des „Single Source of Truth“-Prinzips der Inhalte dieses IS, der stark mit den Kernanwendungen in Verbindung steht. Jetzt kommt die Headless-Architektur für DAM ins Spiel.

 Hier einige Beispiele:

Im Hinblick auf diese Systeme entspricht das Enterprise DAM einem Datenanbieter sowie einem Datenverbraucher. Die Integrationsfähigkeit muss somit nahtlos geschehen, um einerseits die Konsistenz der Inhalte (vor allem der Produktmerkmale) und andererseits deren Bereitstellung (zielgenau und über die richtigen Kanäle) und auch deren Anpassungsfähigkeit zu gewährleisten. Dies ist nur möglich, wenn sich das DAM auf diese beiden Grundprinzipien stützt: Die Headless-Architektur und die API-Funktionen.

 

Das DAM für Unternehmen ist also ein Headless-Content-Management-System (keine Sorge, wir behalten trotzdem einen kühlen Kopf!)

Das Konzept der Headless-Architektur begann sich Ende 2018 einen Namen zu machen. Sein Wachstum basiert auf der Notwendigkeit, unterschiedliche Aspekte über ein zentrales Backoffice zu verwalten: Websites, mobile Apps, zahlreiche Netzwerke … Genau hier kommen das Headless-CMS ins Spiel, um diese Omnichannel-Herausforderung zu bewältigen. Aber wie zeichnen sich diese aus? Während in einem „herkömmlichen“ CMS das Backoffice mit einem Web-Frontend (einem Interface zur Wiederherstellung von Inhalten) gekoppelt ist, ist das Headless-CMS vergleichbar mit einem Backoffice ohne Frontend. Obwohl die Inhalte im Backoffice organisiert und bearbeitet werden, ist es die Aufgabe der Entwickler, Frontends zu entwerfen, die in der Lage sind, die dort vorhandenen Inhalte intelligent zu verwenden. Genau aus diesem Grund bietet das Headless-CMS eine Reihe an APIs, mit denen die Inhalte gezielt aufgerufen werden können. Ein solches CMS kann daher mit verschiedenen Frontends verwendet werden, die unterschiedliche Technologien nutzen.

Während die Unterscheidung zwischen „klassischem“ und „kopflosem“ CMS noch Sinn macht, wird sie mit einer DAM-Lösung gar nicht mehr als solche verwendet. Der Grund dafür ist einfach: Das DAM ist prinzipiell „headless“, da es dahingehend entwickelt wurde, um die beherbergten Inhalte auf allen Kanäle verfügbar zu machen. Dabei handelt es sich um aktuelle sowie zukünftige Versionen, die heute noch unbekannt sind. Dies setzt die Fähigkeit voraus, die Formate dieser Inhalte den unterschiedlichen Kanälen anzupassen und diese unter den bestmöglichen Bedingungen bereitzustellen.

Hierbei ist jedoch Vorsicht geboten, denn die DAM-Integration in eine Headless-Architektur ist nicht nur eine Frage der Plugin-Verfügbarkeit für das eine oder andere CMS. Ein Plugin mag eine offensichtlich einfache Lösung sein, um über ein CMS den Daten-Baum eines DAM zu erforschen. Es sagt jedoch nichts über die Fähigkeit aus, die Inhalte der DAM-Lösung wirklich nutzen und bereitstellen zu können.

 

Das DAM als Anbieter sowohl als Verbraucher von APIs

Wirklich wichtig ist die Reichhaltigkeit der vom DAM vorgeschlagenen APIs, um die richtigen Inhalte abrufen zu können. Dies bedeutet: Die Übermittlung der notwendigen Infos an das DAM, um beispielsweise ein Video im richtigen Format (Auflösung, Bildverhältnis, Kodierung …), in der richtigen Sprache, mit oder ohne Untertitel usw. anzeigen zu können. Diese Fähigkeit ermöglicht es den API das „Content as a Service“ (CaaS) um weitere Funktionen zu bereichern, um Inhalte mit spezifischen Eigenschaften von einem beliebigen Punkt aus dem IS abrufen zu können.

Das DAM benötigt dementsprechend eine Abfragetiefe durch die APIs, auch im Hinblick auf Drittanwendungen. Das DAM sollte sich beispielsweise weitmöglichst auf die Produkt-Taxonomie stützen (für die Klassifizierung und/oder Kennzeichnung der Assets), um somit eine E-Commerce-Plattform optimal betreiben zu können. Dies setzt die Fähigkeit voraus, über das PIM oder ERP die nötigen Informationen abfragen zu können. Das Gleiche gilt für öffentlich zugängliche Informationen: Hierbei muss der Inhalt einer Plattform dem angemeldeten Kunden angepasst werden können. Das DAM muss in der Lage sein, Schlüsselinformationen (Land, Sprache, Kaufhistorie, Präferenzen usw.) aus einem CRM oder CDP abrufen zu können.

 Man kann sagen, dass ein Enterprise DAM auch eine Integrationsplattform ist: Eine Umgebung, die es ermöglicht, die von anderen Anwendungen zur Verfügung gestellten APIs nutzen zu können, um Inhalte durch eigene APIs besser darstellen zu können. In diesem Zusammenhang kann es sich um API-Anbieter und Verbraucher innerhalb von Content-Architekturen handeln, die immer mehr und mehr das Headless-Modell übernehmen. Ziel hierbei ist es, alle Inhalte zu nutzen, um Omnichannel-Herausforderungen zu bewältigen und Kundenbeziehung besser gerecht werden zu können.

Erfahren Sie, warum es sich lohnt in eine DAM-Lösung zu investieren.