Wie ersetze ich mein DAM System? – Ein Mini Fahrplan!

Veröffentlicht am von ulrichleidl

Im neuen Jahr fassen viele Menschen den Vorsatz sich von alten unliebsamen Gewohnheiten, oder in die Jahre gekommenen Dingen, zu trennen.
Auch so manches DAM System ist über die Jahre gealtert und wenn Sie schließlich an dem Punkt angekommen sind, an dem sämtliche Anti Aging Kuren erfolglos geblieben sind, dann ist es wohl Zeit sich zu verabschieden (Ist es Zeit ihr „Legacy System“ zu tauschen? 5 Anzeichen, die dafür sprechen!).
Veränderungen und Abschiede fallen nicht immer leicht, daher sollte man hierfür einen kleinen Fahrplan parat haben!

Hinweis:
Dieser Artikel beschäftigt sich nicht mit der Evaluierung eines neuen DAM Systems. Ich setze hier voraus, dass dies bereits getan wurde!(siehe auch: Die agile Software Auswahl – Deshalb werden Sie damit erfolgreich sein!)

Einige Ideen für einen solchen Fahrplan möchte ich hier gerne mit Ihnen teilen.

Letztendlich könnte man die Umgebungsvariablen eines DAM Systems grob in drei Eckpfeiler unterteilen:

  1. Das DAM System selbst, also der Kern der Anwendung
  2. Die Menschen, die mit dem System arbeiten
  3. Die anderen Systeme, die mit dem DAM System interagieren

1. Schauen wir als erstes auf das DAM System selbst.

(Natürlich muss individuell entschieden werden, welche Daten oder ob überhaupt Daten migriert werden sollen!)

Letztendlich besteht ein DAM vereinfacht gesagt aus drei Bestandteilen:
  1. Die physikalischen Daten wie Bilder, Dokumente, Movies, Audios etc.
  2. Die abstrahierten Daten, sprich die unterschiedlichen Arten von Metadaten
  3. Die User und Gruppenverwaltung inkl. des Rechtesystems

Die physikalischen Daten liegen meist so vor, dass sie nicht einfach “gegriffen” werden können. Dies bedeutet ich kann sie in der Regel nicht einfach per Dateisystem kopieren. Hierfür benötigt man meist Exportfunktionen.
Gleiches gilt für die Metadaten die aus einer Datenbank extrahiert werden müssen.
Bei den Usern und Gruppen stellt sich zuerst die Frage, ob diese tatsächlich im DAM System angelegt wurden, oder ob das DAM System an eine zentrale Benutzerverwaltung (z.B. Active Directory) angebunden wurde.
Ist letzteres der Fall, dann muss das neue DAM System einfach ebenso an diese zentrale Verwaltung angebunden werden (Standard heutzutage! Siehe auch: Bind your DAM to AD (german written only))
Liegen die Benutzer lokal im alten DAM System, hängt es davon ab, ob es möglich ist diese zu exportieren (Achtung: Stolperstein Passwörter!) mit Hilfe von Standard und oder custom Funktionen. Im schlimmsten Fall müssen sämtliche User und Gruppen neu angelegt werden. Im Fall der Berechtigungen wird dies sowieso gemacht werden müssen, da diese kaum migriert werden können.

2. Die Menschen, die mit dem DAM System arbeiten:

Die Benutzer und Gruppeninformationen stellen eine wichtige Informationsbasis dar. Mit Hilfe dieser Informationen kann man sehr gut nachverfolgen, wer alles im DAM System arbeitet. (Lassen wir temporäre Gast Zugänge mal aussen vor)
Hier gilt es auch zu hinterfragen von wo diese Anwender auf das DAM zugreifen – nicht immer soll ein DAM System aus dem Internet frei erreichbar sein. Gibt es Anwender ausserhalb der Organisation, muss daran gedacht werden diese mit VPN oder Ähnlichem zu versorgen.

3. Die anderen Systeme, die mit dem DAM System interagieren:

An diese Stelle wird es meist etwas “tricky”. Der Wunsch wäre natürlich, dass im Unternehmen bereits eine zentrale API, oder ein zentraler Data Hub existiert in welchen das DAM seine “Infos” einspeist.
Aktuell ist dies so gut wie nie der Fall (diese Architektur sollte aber ein Zielbild sein für das neue DAM System)!
An dieser Stelle ist meist etwas Detektivarbeit gefragt.
Wenn man hier bei Null beginnen muss, dann lohnt es sich erstmal “einfach” zu beginnen.

Im Grunde genommen kann es zwei unterschiedliche Arten von Interaktionen geben:

  • Ad hoc Interaktionen, sprich getriggerte Aktionen zum Beispiel in einem Drittsystem wird ein Bild aufgerufen, dieser Aufruf geht direkt ans DAM System
  • Zyklische Interaktionen: Zum Zeitpunkt x wird Aktion y ausgeführt. Beispielsweise einmal pro Nacht werden Bilder für den Webshop bereitgestellt.

    • Mit diesem Wissen kann man sich hier vorarbeiten. Letztendlich wird man zuerst schauen, ob es logfiles, oder Konfigurationen im System gibt, wenn dies nicht der Fall ist, kann man dazu übergehen den Traffic zu überwachen.
    Dies sind alles mit Sicherheit keine Dinge, die ein Product Owner/ Projektleiter tun kann, er sollte diese aber auf dem Schirm haben und dementsprechende Leute mit ins Boot holen.
    Bei diesem, durchaus komplexen Punkt, habe ich verschiedenste Mechanism entwickelt auf die man zurückgreifen kann, gerne unterstütze ich sie hierbei!
    Siehe hierzu auch: DAM Evangelist – Leistungen

    Dann kann man nun loslegen?!

    Loslegen ja, aber die Migration eines DAM Systems erfordert eine gute Planung.
    Dieser Mini Fahrplan soll nur die Hauptbereiche herausstellen, die immer von einer Migration betroffen sind.
    Diese Bereiche müssen individuell mit Leben gefüllt werden. Hierfür wird man sich den ein oder anderen Experten mit ins Boot holen müssen. Vor allem der Punkt “Kommunikation mit anderen Systemen” kann sehr schnell hoch komplex werden

    Gerne beantworte ich ihre Fragen oder unterstütze sie in einem oder allen Punkten!

     

    Kommentar verfassen