Diese Woche bringt zwei Ereignisse auf einmal: Storyblok hält heute (30. Juni, 15:00 Uhr CET) sein &…
DXP auswählen: Warum Architektur wichtiger ist als Features
Es gibt einen Moment in jedem DXP-Auswahlprozess, der sich immer gleich anfühlt: Die Präsentationen der Anbieter sind abgeschlossen, die Demoumgebungen wurden begutachtet, und das Team schaut auf eine ellenlange Feature-Matrix. Personalisierung? Alle haben es. A/B-Testing? Auch. KI-Funktionen? Natürlich. Integrationen? Sagen alle, ja.
Und genau hier beginnt das eigentliche Problem.
Wer eine Digital Experience Platform nach Features auswählt, trifft eine Entscheidung, die auf den nächsten 18 Monaten basiert. Aber eine Plattform-Entscheidung wirkt fünf bis zehn Jahre. Die Features, die heute auf der Checkliste stehen, sind in zwei Jahren entweder Standard oder obsolet. Was hingegen bleibt, ist die Architektur darunter.
Die Feature-Falle: Warum Checklisten in die Irre führen
Feature-Matrizen belohnen Breite statt Tiefe. Ein System, das Personalisierung über serverseitiges Rendering liefert, und ein System, das personalisierte Erlebnisse am CDN-Edge bereitstellt, bekommen in der Tabelle das gleiche Häkchen. Für den Nutzer macht das einen Unterschied von 200 Millisekunden. Für den Umsatz macht das manchmal den Unterschied zwischen Conversion und Abbruch.
Die Frage ist nicht, ob eine Funktion existiert. Die Frage ist, wie sie innerhalb der Architektur funktioniert.
Dazu kommt der Kostenaspekt, der bei feature-basierten Evaluierungen systematisch unterschätzt wird. Die Lizenzgebühr ist selten das, was eine DXP-Entscheidung teuer oder günstig macht. Es sind die Integrationskosten, die Entwicklungsaufwände für maßgeschneiderte Schnittstellen, die Wartung von Custom-Code, der entsteht, weil sich zwei Systeme nicht sauber verbinden lassen. Und die Stunden, die Teams in Ticket-Queues verlieren, weil die Plattform eine Entwickler-Abhängigkeit erzeugt, die nie geplant war.
Das Ergebnis: Viele Unternehmen unterschätzen ihre tatsächlichen Martech-Gesamtkosten erheblich, weil Feature-basierte Evaluierungen die Lizenzgebühr mit den Gesamtkosten gleichsetzen. Was als budgetfreundliche Wahl erscheint, wird schnell zur teuersten Entscheidung der digitalen Agenda.
Was bei einer DXP-Auswahl wirklich zählt: Drei Architekturdimensionen
Wenn Features das falsche Hauptkriterium sind, was sollten Entscheidungsträger stattdessen bewerten? Drei Architekturdimensionen trennen Plattformen, die liefern, von Plattformen, die gut demonstrieren.
1. Integrationsarchitektur: Wie verbindet sich die Plattform mit dem bestehenden Stack?
Die Frage ist nicht, wie viele Integrationen ein Anbieter listet. Die Frage ist, wie diese Integrationen technisch realisiert werden. Gibt es vorkonfigurierte Konnektoren, die ohne Custom-Code funktionieren? Oder entstehen bei jeder Anbindung neue individuelle Entwicklungsprojekte, die langfristig gewartet werden müssen?
Für E-Commerce-Unternehmen ist diese Frage besonders kritisch. Ein moderner Online-Shop verbindet typischerweise ein CMS, ein PIM-System, eine Commerce-Engine, ein CDP, ein DAM und ein Analytics-Tool. Wenn jede dieser Verbindungen maßgeschneidert entwickelt werden muss, potenziert sich der Wartungsaufwand mit jeder Systemversion und jedem Plattform-Update.
Eine gesunde Integrationsarchitektur nutzt offene APIs und vorkonfigurierte Konnektoren, die Updates der beteiligten Systeme absorbieren, ohne dass die Integrationsschicht neu gebaut werden muss. Das reduziert nicht nur Entwicklungskosten. Es reduziert die Abhängigkeit von spezialisiertem Wissen, das im schlimmsten Fall nur ein einziger Entwickler im Team besitzt.
2. Composability als Fundament: War die Plattform von Beginn an modular gedacht?
Es gibt einen wesentlichen Unterschied zwischen einer Plattform, die von Grund auf composable gebaut wurde, und einer Plattform, die nachträglich mit modularen Elementen ausgestattet wurde. Dieser Unterschied bleibt in Demos unsichtbar. Er zeigt sich erst in der Implementierung.
Nachträglich composable gemachte Systeme bringen in der Tiefe monolithische Annahmen mit. Content-Modelle sind rigide. Presentation-Layer und Content-Schicht sind stärker gekoppelt als versprochen. Neue Kanäle lassen sich nicht ohne erheblichen Entwicklungsaufwand anbinden. Die modulare Fassade verbirgt ein System, das intern weiterhin wie ein Monolith denkt.
Für E-Commerce-Teams, die auf neue Kanäle, neue Märkte oder neue Touchpoints reagieren müssen, ist dieser Unterschied existenziell. Eine wirklich composable Architektur trennt Content, Daten und Darstellung als unabhängige, austauschbare Schichten. Was in einem Kanal aufgebaut wird, kann in einem anderen wiederverwendet werden. Eine neue Marktregion erfordert keine Neuimplementierung, sondern eine Konfiguration.
3. Organisationale Reibung: Wie viel Developer-Abhängigkeit produziert die Plattform?
Das ist der am häufigsten unterschätzte Faktor bei einer DXP-Entscheidung.
Jede Plattform erzeugt Abhängigkeiten zwischen Marketing-Teams und Entwicklern. Die Frage ist, wie groß diese Abhängigkeit ist und wo sie entsteht. Eine Plattform, die für jedes Kampagnen-Update, jeden Landing-Page-Wechsel und jede Personalisierungsregel ein Entwickler-Ticket benötigt, ist keine Marketing-Plattform. Sie ist ein Entwickler-Projekt, das von Marketing-Budget bezahlt wird.
Für wachstumsstarke E-Commerce-Unternehmen bedeutet jede Woche mit einer unnötigen Entwickler-Abhängigkeit eine Woche, in der Kampagnen später live gehen, Personalisierungsexperimente verzögert werden und Marktchancen ungenutzt bleiben.
Eine architektonisch gesunde DXP gibt Marketing-Teams die Kontrolle über das, was Marketing-Teams kontrollieren sollten: Inhalte, Erlebnisse, Personalisierungsregeln, A/B-Tests. Entwickler behalten die Kontrolle über das, was technisch kritisch ist: Komponenten, Code-Qualität, System-Integrationen.
Zwei Einstiegspunkte, eine Architektur-Frage
Die Evaluierungsfragen bleiben dieselben, egal welchen Einstiegspunkt ein Unternehmen wählt. Was sich ändert, ist die Gewichtung der Antworten.
Wer den bestehenden Martech-Stack orchestrieren will, ohne ihn zu ersetzen, legt das Hauptgewicht auf die Integrationsarchitektur. Kann die Plattform über dem bestehenden Stack als Kompositions- und Optimierungsschicht arbeiten? Bleiben Content-Systeme dort, wo sie sind, während Edge-Personalisierung, Testing und KI-gestützte Optimierung als Konfigurationsschicht darüber gelegt werden?
Wer hingegen eine vollständige Plattformmigration plant, legt das Hauptgewicht auf Migrationssicherheit und Time-to-Value. Wie schnell ist ein Unternehmen in der Lage, produktiv zu gehen, ohne die laufenden Kampagnenoperationen zu unterbrechen? Inkrementelle Migrationsstrategien, die Geschäftswert in jeder Phase statt erst nach einem großen "Big Bang"-Launch liefern, sind dabei entscheidend für den realen ROI.
Fünf Fragen, die im Vendor-Gespräch den Unterschied machen
Wer eine DXP nach Architektur bewertet statt nach Features, stellt andere Fragen im Evaluierungsgespräch:
Wie viele Custom-Integrationen sind notwendig, um die Plattform mit den bestehenden Systemen zu verbinden? Und was sind die laufenden Wartungskosten pro Integration?
Können Marketing-Teams personalisierte Erlebnisse ohne Entwickler-Beteiligung starten? Und wie liefert die Plattform diese Personalisierung ohne Ladezeit-Einbußen?
Wenn ein einzelnes System im Stack ausgetauscht werden soll: Unterstützt die Architektur einen modularen Wechsel, oder zieht jede Änderung eine Kaskade durch das Gesamtsystem?
Wie orchestriert die Plattform Content aus mehreren Quellen gleichzeitig? Erfordert das Custom-Code oder Konfiguration?
Was ist der Migrationspfad, und wie minimiert der Anbieter Content-Freeze-Phasen während der Transition?
Anbieter, die auf diese Fragen mit architektonischen Spezifika antworten statt mit Feature-Versprechen, demonstrieren die Grundlage, die langfristig funktioniert.
Der wahre Preis einer Feature-getriebenen Entscheidung
Die eigentlich schmerzhaftesten DXP-Entscheidungen sind nicht die teuren. Sie sind die, die sich erst nach 18 Monaten als teuer herausstellen.
Ein Unternehmen wählt eine Plattform auf Basis überzeugender Demos und einer beeindruckenden Feature-Liste. Sechs Monate später hat es ein Integrations-Team, das die Hälfte der Zeit mit der Pflege von Custom-Konnektoren verbringt. Zwölf Monate später hat es eine Marketing-Organisation, die frustriert ist, weil jede Kampagnen-Anpassung ein Entwickler-Ticket erfordert. 18 Monate später beginnt die Diskussion über die nächste Plattform.
Der Ausweg aus diesem Kreislauf beginnt mit der richtigen Frage im Evaluierungsprozess. Nicht: Welche Features hat diese Plattform? Sondern: Wie ist diese Plattform gebaut, und was produziert sie an täglichen Abhängigkeiten für unser Team?
Architektur zu evaluieren erfordert mehr Aufwand als eine Feature-Checkliste. Aber sie ist die einzige Methode, die den Total Cost of Ownership wirklich sichtbar macht, bevor Verträge unterschrieben werden.
Was das für E-Commerce-Teams konkret bedeutet
Für E-Commerce-Unternehmen, die auf Plattformsuche sind, lassen sich die Architektur-Fragen sehr konkret ableiten:
Wie verbindet sich die Plattform mit dem Produktkatalog? Gibt es eine vorkonfigurierte PIM-Integration, oder ist für jeden Produkttyp Custom-Code nötig?
Wie funktioniert die Personalisierung auf Kategorie- und Produktseiten? Ist das eine Server-seitige Funktion mit Latenz-Auswirkungen auf SEO-Leistung, oder arbeitet die Personalisierung am Edge?
Wie werden Checkout-Flows, Kampagnen-Landing-Pages und reguläre Content-Seiten in derselben Plattform verwaltet? Gibt es eine einheitliche Kompositionsschicht, oder operieren verschiedene Teams in verschiedenen Systemen ohne Verbindung?
Wie unterstützt die Plattform die Internationalisierung? Ist eine neue Marktregion eine Konfigurationsaufgabe oder ein Entwicklungsprojekt?
Diese Fragen führen schneller zu validen Erkenntnissen als jede Demo. Denn in einer Demo zeigt jeder Anbieter seine Stärken. In Architektur-Gesprächen zeigen sich die Grenzen.
Fazit: Architektur ist die langfristige Wette
Eine DXP-Entscheidung ist eine der langfristigsten Technologieentscheidungen, die ein digitales Team treffen kann. Features wechseln. Architekturen bleiben.
Unternehmen, die die Architektur-Fragen stellen, bevor sie Lizenzverträge unterschreiben, bauen Stacks, die mit dem Unternehmen wachsen. Sie bezahlen nicht mehrfach für Integrationen, die auf Konfiguration basieren sollten. Sie erzeugen keine Ticket-Queues, die Kampagnen verlangsamen. Und sie treffen nicht 18 Monate später die nächste Plattform-Entscheidung.
Die gute Nachricht: Wer weiß, welche Fragen man stellen muss, hat den größten Teil des Evaluierungswegs bereits hinter sich.
Mehr zur Laioutr-Plattform
Weiterführend: Composable Digital Experience Platform.
Mehr dazu: DXP-Auswahl: Warum die Architektur über den Erfolg entscheidet, nicht der Feature-Vergleich und Warum Architektur wichtiger ist als Features bei der Auswahl einer E-Commerce-Plattform.