Die Leber wächst mit ihren Aufgaben ist ein Bestseller von Kabarettist und Arzt Dr. Eckhard von Hirschhausen (Die Leber wächst mit ihren Aufgaben – bei Amazon).
Sinnbildlich für den Titel erzählt Hirschhausen auf humorvolle Art und Weise Anekdoten aus dem medizinischen Leben.
Nun sollte man natürlich, als jemand wie ich, der ein gutes Glas Rotwein zu schätzen weiß, diesen Titel nicht falsch interpretieren, allerdings hat er mich tatsächlich zu diesen neuen Blogpost animiert.
Wäre es nicht, ganz abgesehen von der humorvollen Seite, eine tolle Sache, wenn Dinge mit ihren Aufgaben wachsen würden?
Sicherlich gibt es dies in vielen Bereichen des Lebens, aber wie sieht es denn mit meinem Lieblingsthema den DAM Systemen aus?
Viele Unternehmen betreiben und erwerben noch immer Legacy DAM Systeme, die meisten ohne es auch nur im Ansatz zu ahnen.
Der Markt der DAM Systeme ist nämlich ein gewachsener. Manch’ Systeme tummeln sich seit 20 Jahren auf dem Markt, ohne dass sie jemals nennenswerte Erneuerungen an ihrem Software Source Code und an ihrem Application Design umgesetzt hätten.
Sehr häufig finden sich einfach nur kosmetische Verbesserungen, die vor allem das User Interface betreffen.
Coole und funktionale User Interfaces sind sehr wichtig für ein stimmiges Produkt, aber sie sollten nicht als das einzige Kaufargument für ein System dienen.
Schon Steve Jobs hat gesagt:
“Design ist nicht wie es aussieht. Design ist wie es funktioniert.”
Und wie so oft liegt Steve Jobs hier absolut richtig. Nur also, wenn auch “unter der Haube” die richtige Architektur verbaut ist, wird ihr DAM vernünftig funktionieren.
Die meisten der Legacy DAM Systeme wachsen definitiv NICHT mit ihren Aufgaben, sondern ganz im Gegenteil, ihre Leistung nimmt mit zunehmenden Aufgaben drastisch ab!
Der ständig wachsende Omnichannel Marketing Prozess, erfordert von den DAM Systemen ein hohes Maß an Skalierbarkeit.
Fatal ist es, sich für ein System zu entscheiden, welches bereits ein, von der Architektur her, vorgegebenes Limit hat.
Wie soll man den Omnichannel Prozess hochskalieren, wenn das Herzstück der Kette limitiert ist?
Wie soll man mit einem eklatant gesteigerten Datenvolumen umgehen können, wenn ein System nicht dynamisch hoch und auch wieder runter skalieren kann?
Wie soll man die User Suchanfragen und API calls von Drittsystemen bewältigen, wenn Datenbanken und Suchindexe nicht expandiert werden können?
Grundsätzlich gibt es zahlreiche unterschiedliche Arten, wie man Systeme skalieren kann.
Früher wurde hauptsächlich die Hardware aufgestockt, um dann häufig festzustellen, dass dies leider keine Lösung für das eigentlich Problem war.
Unterdimensionierung der Hardware ist heutzutage nur ein sehr seltener Grund warum ein DAM System von der Performance her seinen Dienst nicht mehr tut.
Der wesentlich häufigere Grund liegt im Design der Softwarelösung an sich.
Am Datenmodell, an der Strukturierung der einzelnen Prozesse, an der fehlenden Parallelisierung von Prozessen und am mangelnden Einsatz von Queuing Systemen etc.
Wie erkennt man nun gut designte DAM Systeme?
Dies ist eine Herausforderung für die man schon ein wenig Know How benötigt!
Ein erster wichtiger Punkt ist es sich die Architektur darstellen und erklären zu lassen.
Natürlich muss man hier zumindest über Grundkenntnisse des Software und Applikationsdesigns verfügen. Ein DAM System kann prinzipiell in verschiedene “Services” zerlegt werden zum Beispiel:
– Speicher zur Ablage der Binär Mediendaten
– Datenbank zum Speichern der Verweise und Metainformation
– Rendering Engine zum Erstellen der Previews und Derivate
– Suchindex zum Suchen von Assets
etc.
Jede diese Komponenten muss in sich sauber gestaltet sein, genauso wie das Zusammenspiel aller Komponenten. Scheuen sie sich nicht davor externe Hilfe in Anspruch zu nehmen, wenn ihnen selbst das Wissen fehlt diese Architekturen zu beurteilen. Dies ist essentiell wichtig für die Selektion des richtigen DAM Systems!
Ein zweiter Punkt kann das Anfordern von Benchmarks sein.
Hier werden sie vermutlich auf große Verwunderung stoßen, da die meisten DAM Hersteller keine Benchmarks für ihre Software erstellen. Benchmarks sind ein wichtiger Indikator, wie sich ein System unter Last verhält. Hier können mehrere gleichzeitige User Zugriffe und API Zugriffe abhängig von der Anzahl der Daten etc. miteinander kombiniert werden. Dies gibt einen sehr guten Eindruck was ein System wirklich im Stande ist zu leisten
Hat der Hersteller keine eigenen Benchmarks, können diese über Aufrufe der API (die hoffentlich jedes DAM hat!!!) simuliert, erstellt und ausgewertet werden. Auch hierfür werden sie sich vermutlich externe Unterstützung holen, aber es wird sich definitiv für sie lohnen!
Und zu guter letzt:
Fragen sie den Hersteller des DAM Systems ein “Loch in den Bauch” und lassen sie sich Antworten schriftlich bestätigen.
Fragen könnten zum Beispiel sein:
– Kann ich jederzeit im Standard eine zweite Datenbank hinzufügen, falls eine Instanz nicht mehr ausreichend ist?
– Kann ich den Suchindex einfach skalieren und ab wann (Anzahl Datensätze) gibt es Sinn mit der Skalierung zu beginnen?
etc.
Die Beurteilung, ob ein DAM System eine solide, stimmige und vor allem auch skalierbare Architektur hat, ist mit Sicherheit für Laien nicht ganz einfach. Nichts desto trotz ist es eine Bewertung, die unbedingt gemacht werden muss, um keine böse Überraschung zu erleben.
Bei Fragen, oder Anregungen freue ich mich über ihre Nachricht!