Es ist ein Muster, das wir in fast jedem DXP-Auswahlprozess sehen, den wir bei Laioutr begleiten: Drei Vendor stehen auf der Shortlist, drei Excel-Tabellen mit hunderten Zeilen, drei Mal grüne Häkchen. Personalisierung, A/B-Testing, Headless-API, KI-Funktionen, Multi-Site, Lokalisierung. Alle drei Plattformen liefern auf dem Papier alles, was die Marketing-Organisation für die nächsten drei Jahre verspricht. Achtzehn Monate nach dem Go-Live ist genau eine dieser Organisationen zufrieden, eine zweite startet ein "Stabilisierungsprojekt", und die dritte beginnt mit der Vorbereitung des nächsten Replatforming-Projekts.

Der Unterschied liegt fast nie in den Features. Er liegt in der Architektur, die im RFP nie sauber bewertet wurde.

Warum Feature-Matrizen den Blick auf das Wesentliche verstellen

Ein Feature-Vergleich belohnt Breite, nicht Tiefe. Eine Plattform, die Personalisierung über Server-Side-Rendering ausspielt, und eine Plattform, die am CDN-Edge personalisiert, bekommen beide denselben grünen Haken. Eine Lösung mit zwölf vorgefertigten Konnektoren und eine mit über siebzig No-Code-Integrationen erscheinen in derselben Zeile. Die Matrix kann nicht abbilden, wie ein Feature unter Last performt, wie viel Custom-Code es braucht, um es produktiv nutzbar zu machen, oder wie es sich in einer bestehenden Composable-Architektur verhält.

Im DACH-Raum kommt ein zweiter Effekt hinzu, den wir aus jedem zweiten Auswahlprojekt kennen: Die Beschaffung will Vergleichbarkeit erzwingen. Eine Bewertungsmatrix mit hundert binären Kriterien wirkt objektiv, ist juristisch dokumentierbar und lässt sich an den Vorstand weiterreichen. Sie produziert aber genau das Ergebnis, das Sie nicht wollen: Sie maximiert die Anzahl der Häkchen pro Plattform und ignoriert, wie diese Funktionen sich zu einem System verhalten.

Aus unserer Erfahrung sind es drei Dimensionen, die ein Feature-Vergleich strukturell nicht abbilden kann: wie sich Funktionen zu einer kohärenten Experience verbinden lassen, wie sich der Stack mit veränderten Geschäftsanforderungen weiterentwickelt, und wie viel organisatorische Reibung die Plattform zwischen Marketing, Produkt und Engineering erzeugt.

Die wahren Kostentreiber liegen außerhalb der Lizenz

Eine Branchen-Erhebung aus 2025 hat ergeben, dass 65,7 Prozent der Organisationen die Datenintegration als ihre größte Herausforderung im Martech-Stack benennen. Nicht Funktionalität, nicht Lizenzkosten, nicht KI-Reife. Integration. Genau die Dimension, die in einem Feature-Vergleich am schwächsten abgebildet ist.

Diese Zahl deckt sich mit dem, was wir in Laioutr-Engagements regelmäßig sehen: Lizenzgebühren machen oft nur etwa ein Drittel der tatsächlichen Total Cost of Ownership einer DXP-Implementierung aus. Der Rest entsteht aus Custom-Integrationen, Schatten-IT in Form von Middleware, organisatorischer Reibung zwischen Teams, kontinuierlichem Wartungsaufwand für brüchige Konnektoren und dem Verlust an Time-to-Market, wenn jede neue Kampagne eine kleine Engineering-Diskussion auslöst.

CMOs und CTOs unterschätzen diese Folgekosten regelmäßig um vierzig bis sechzig Prozent. Das ist kein Pessimismus, das ist die Realität, mit der wir in Migrationsprojekten konfrontiert werden, sobald wir die echten Stundenpfade durch die Buchhaltung und die Jira-Daten der letzten zwei Jahre rekonstruieren.

Die unbequeme Konsequenz: Eine DXP, die im RFP zwanzig Prozent günstiger ist, kann am Ende des dritten Betriebsjahres die teuerste Option im Markt gewesen sein, wenn ihre Architektur Custom-Code an den falschen Stellen erzwingt.

Welche Architektur-Eigenschaften wirklich entscheiden

Wenn Features nicht das richtige Bewertungsraster sind, was dann? Aus den Composable-Commerce- und Composable-DXP-Projekten, die wir bei Laioutr in den letzten Jahren begleitet haben, kristallisieren sich vier Dimensionen heraus, die zuverlässig zwischen einem belastbaren und einem bröckelnden Stack unterscheiden.

Integrations-Modell: API-First oder Plug-in-Friedhof

Die erste Frage ist nicht, wie viele Integrationen eine Plattform mitbringt, sondern wie sie integriert. Eine API-First-Architektur mit klaren Webhooks, idempotenten Endpoints und versionierten Schnittstellen verhält sich grundlegend anders als eine Plattform, die ihre Anbindungen über proprietäre Plug-ins realisiert. Im ersten Fall können Sie Ihre Headless-Storefront, Ihr PIM, Ihren CRM und Ihren Personalisierungs-Layer austauschen, ohne die DXP zu berühren. Im zweiten Fall sind Sie Geisel jedes Vendor-Updates.

Komposition: Visuelle Workspace versus Code-First

Eine echte Composable-Architektur erlaubt Marketing-Teams, Inhalte und Kampagnen ohne Engineering-Ticket zu komponieren und zwar nicht nur die Texte, sondern auch das Layout-Verhalten, die Personalisierungslogik und die A/B-Test-Konfiguration. Plattformen, die hier auf einen rein code-basierten Ansatz setzen, produzieren strukturell Engineering-Bottlenecks. Plattformen, die einen visuellen Workspace anbieten, ohne unter der Haube auf Code-Konsistenz zu achten, produzieren stattdessen WYSIWYG-Chaos. Die belastbare Variante ist die mittlere: ein visueller Workspace, der jede Konfiguration in nachvollziehbaren, versionierten, deploybaren Artefakten ablegt.

Edge- und Daten-Topologie

Wo werden personalisierte Inhalte zusammengesetzt? Wo werden Daten persistiert? Wo läuft die KI-Inferenz? Diese Fragen sind nicht primär Performance-Fragen, sondern Compliance-Fragen. Für DACH-Enterprise-Kunden ist EU-Datenresidenz fast immer ein hartes Auswahlkriterium, und es kollidiert in der Praxis häufig mit einer DXP-Architektur, die ihre Personalisierungs- und Tracking-Engine ausschließlich in US-Regionen betreibt. Eine Plattform, die regional verteiltes Edge-Rendering und EU-Datenpersistenz nativ unterstützt, ist in einem DSGVO-Audit ein anderer Verteidigungsfall als eine, bei der Sie diese Topologie selbst rekonstruieren müssen.

Erweiterbarkeit: Stable Public Surfaces, nicht private Hooks

Jede DXP wird im Laufe der Zeit Fähigkeiten brauchen, die der Hersteller heute noch nicht ausgeliefert hat. Die Frage ist, ob Sie diese Fähigkeiten an stabilen, dokumentierten und versionierten Erweiterungspunkten andocken können oder ob Sie auf private APIs, undokumentierte Hooks und Source-Code-Patches angewiesen sind. Das Anti-Pattern ist gut sichtbar: Wenn die Vendor-Roadmap "Erweiterbarkeit" nur in Form von Marketplace-Apps verspricht, wissen Sie, dass jede individuelle Anforderung später durch eine Custom-Implementierung ohne Update-Pfad realisiert wird.

Orchestrierung oder vollständiger Plattform-Wechsel

Die DXP-Auswahl ist selten eine grüne-Wiese-Entscheidung. In den meisten Fällen existiert ein gewachsener Stack mit einem Headless-CMS, einer Commerce-Engine, einem CDP, einem Marketing-Automation-Tool und einer Reihe an Anbindungen, die irgendwann gut investiertes Geld waren. Die Frage ist dann nicht "welche DXP ersetzt das alles", sondern "in welcher Architektur-Rolle setze ich die DXP ein".

Wir unterscheiden in unseren Engagements zwei klare Pfade. Im Orchestrierungs-Modell bleibt der bestehende Stack weitgehend an Ort und Stelle. Die DXP übernimmt die Rolle der orchestrierenden Schicht: Komposition, Personalisierung, Experimentation und KI-gestützte Content-Operations sitzen oberhalb der bestehenden Systeme. Der Wert wird über Konfiguration realisiert, nicht über Custom-Development. Time-to-Value liegt typischerweise bei vier bis acht Wochen für die ersten messbaren Use-Cases.

Im Replatforming-Modell ersetzt die DXP signifikante Teile des bestehenden Stacks und übernimmt selbst die Rolle des CMS, der Personalisierungs-Engine und der Test-Plattform. Hier ist Migrations-Geschwindigkeit der entscheidende Hebel. Wie schnell lässt sich der bestehende Content reinholen? Wie schnell können bestehende Frontend-Implementierungen wiederverwendet werden? Welche Risiken trägt die Marketing-Organisation während der Übergangsphase?

Die Architektur-Bewertung muss diesen Pfad früh klären. Eine Plattform, die als Orchestrierungs-Layer brillant funktioniert, kann als vollwertiger Plattform-Ersatz zu schmal sein und umgekehrt. Im RFP-Prozess wird das aber selten sauber getrennt, weil Vendor naturgemäß den ambitionierteren Pfad bevorzugen.

Die Fragen, die im RFP wirklich zählen

Wenn wir Auswahlprozesse begleiten, ersetzen wir die klassische Feature-Matrix durch eine Architektur-Fitness-Befragung. Sie zwingt Vendor in ein Gespräch jenseits der Demo-Skripte. Eine Auswahl der Fragen, die in unseren Engagements zuverlässig erkenntnisstiftend war:

• Welche Konfigurationen sind als Code versioniert und deploybar welche sind ausschließlich UI-State?
• Wie viele Stunden Engineering-Aufwand verursacht eine zusätzliche Personalisierungs-Variante in einem produktiven Setup?
• Welche Komponenten der Plattform laufen in welchen Regionen, und welche Daten verlassen die EU?
• Welche APIs sind als stabile öffentliche Schnittstelle dokumentiert, und welche sind explizit "internal use only"?
• Wie groß ist der Aufwand, eine Demo-Komponente in eine produktive Komponente zu überführen, die in einem Design-System konsistent ist?
• Wie verhält sich die Plattform, wenn ein angeschlossenes System für 30 Minuten ausfällt fallen einzelne Personalisierungen aus, oder degradiert die ganze Experience?
• Was passiert mit konfigurierten Erweiterungen, wenn die DXP ein Major-Version-Upgrade durchführt?

Vendor, die auf diese Fragen mit einer Live-Demo, einem Architektur-Whiteboard und konkreten Kundenbeispielen antworten können, beweisen Architektur-Reife. Vendor, die in Produkt-Marketing-Folien zurückfallen, beweisen das Gegenteil.

Was diese Verschiebung für die nächsten Auswahlprozesse bedeutet

Die DXP-Landschaft konvergiert auf der Feature-Ebene. KI-gestützte Content-Operations, semantische Personalisierung, agentische Orchestrierung diese Fähigkeiten werden in den nächsten zwölf bis achtzehn Monaten Standard. Was bleiben wird, ist die Architektur, mit der diese Fähigkeiten zusammengeführt werden. Die Plattformen, die heute auf einer sauberen Composable-Foundation aufbauen, werden diese Funktionen mit minimalem Reibungsverlust integrieren. Die Plattformen, die heute monolithisch denken und erst in der Vermarktung composable klingen, werden in jeder Erweiterung Custom-Implementierungen erzwingen.

Die strategische Implikation für Tech-Leads in DACH-Enterprise-Organisationen ist klar: Verschieben Sie das Gewicht im RFP. Geben Sie der Architektur-Bewertung mehr Gewicht als der Feature-Matrix. Lassen Sie sich von Vendor nicht in eine Demo-Kette ziehen, sondern in einen Architektur-Workshop. Und vor allem: Bewerten Sie die DXP nicht isoliert, sondern als Teil der Composable-Stack-Strategie, in der sie tatsächlich leben wird.

Die DXPs, die in den kommenden drei Jahren liefern, werden nicht die mit den meisten Häkchen sein. Es werden die mit der Architektur sein, die organisatorische Reibung reduziert und Veränderbarkeit als Standardzustand begreift.

Mehr zur Laioutr-Plattform

• Composable Digital Experience Platform
• Agentic Frontend Management Platform
• Personalisierung
• Composable Visual Page Builder

Mehr dazu: DXP auswählen: Warum Architektur wichtiger ist als Features und Warum Architektur wichtiger ist als Features bei der Auswahl einer E-Commerce-Plattform.