Build, Buy, or
Orchestrate?

Inhalts-
verzeichnis

Executive
Summary

Viele Unternehmen starten ihre Commerce-Transformation mit der falschen Frage: Welche Plattform brauchen wir?

Doch nachhaltige digitale Geschäftsmodelle entstehen nicht durch Systementscheidungen – sondern durch bewusste Architekturentscheidungen.

Heute geht es nicht mehr um: Build vs Buy

Sondern um:

• Wo genügt Standardisierung?

• Wo entsteht Wert durch Komposition?

• Wo brauchen wir echte Differenzierung?

Dieses Framework zeigt, wie Unternehmen ihre Commerce-Landschaft als steuerbare Entscheidungsarchitektur aufbauen – statt als starres Shop-System.

01 |

Warum klassische Auswahlprozesse nicht mehr ausreichen

Traditionelle E-Commerce-Evaluierungen vergleichen:

• Funktionen

• Anbieter

• Lizenzmodelle

• Implementierungsaufwand

Doch moderne Commerce-Landschaften bestehen nicht mehr aus einem System. Sie bestehen aus:

• Datenlogiken

• Entscheidungsregeln

• Services

• Partnerintegrationen

• Experience-Layern

Die zentrale Frage lautet daher nicht: Welche Lösung passt zu uns?

Sondern: Welche Fähigkeiten müssen wir kontrollieren, um langfristig handlungsfähig zu bleiben?

02 |

Commerce ist heute Entscheidungsarchitektur

Früher bestimmte ein System die Möglichkeiten.

Heute gilt: Die Architektur bestimmt die Zukunftsfähigkeit

Commerce ist zu einer Kombination geworden aus:

• Entscheidungslogik

• API-Orchestrierung

• Datensteuerung

• Ecosystem-Integration

Die entscheidende strategische Frage lautet:

Was muss stabil bleiben – und was muss sich verändern können?

Technologie wird zum Baustein

Plattformen, SaaS, Microservices oder Greenfield sind heute keine Strategien. Sie sind Bausteine innerhalb einer Architektur.

Moderne Commerce-Landschaften entstehen aus der bewussten Kombination von:

• Standardkomponenten

• orchestrierten Services

• individuellen Entscheidungslogiken

Nicht die Technologie bestimmt die Handlungsfähigkeit, sondern die Art, wie sie eingesetzt wird.

03 |

Die drei Entscheidungszonen moderner Commerce-Architekturen

Moderne Commerce-Architekturen entstehen nicht aus einem System.

Sie entstehen aus bewussten Entscheidungen darüber, wo ein Unternehmen:

• Effizienz braucht

• Geschwindigkeit braucht

• Kontrolle braucht

Nicht jede Fähigkeit im Commerce verdient den gleichen Grad an Individualität.

Manche sollten bewusst standardisiert werden.
Andere müssen flexibel kombinierbar sein.
Und einige sind so zentral für das Geschäftsmodell, dass sie unter eigener Kontrolle bleiben müssen.

Daraus entstehen drei Entscheidungszonen.

1. Standardisieren

Dort, wo Individualität keinen Wettbewerbsvorteil bringt.

Diese Fähigkeiten müssen zuverlässig funktionieren – aber sie unterscheiden Ihr Unternehmen nicht am Markt.

Ein Kunde entscheidet sich nicht für Sie, weil Ihr Checkout anders ist.
Er erwartet lediglich, dass er reibungslos funktioniert.

Typische Beispiele:

• Checkout

• Payment

• Steuer- und Compliance-Logik

• grundlegende CMS-Funktionen

Hier zahlt sich Standardisierung aus. Sie reduziert Komplexität, senkt Betriebskosten und sorgt für Stabilität.

Das Ziel ist nicht Differenzierung – sondern Verlässlichkeit.

2. Komponieren

Dort, wo Integration Wert schafft.

Viele Commerce-Fähigkeiten entstehen nicht isoliert, sondern durch das Zusammenspiel verschiedener Systeme, Inhalte oder Partner. Hier geht es weniger darum, selbst zu entwickeln, sondern darum, flexibel kombinieren zu können.

Typische Beispiele:

• Customer Journeys über mehrere Kanäle hinweg

• Produkt-Erlebnisse aus Content, Services und Daten

• Channel-Orchestrierung (z.B. Web, Partner, Marktplätze)

• Integration externer Angebote oder Services

Der Wettbewerbsvorteil entsteht hier nicht durch einzelne Bausteine, sondern durch deren Zusammenspiel.

Das Ziel ist Geschwindigkeit und Anpassungsfähigkeit.

3. Differenzieren

Dort, wo Ihr Geschäftsmodell entschieden wird.

Einige Fähigkeiten bestimmen, wie Sie Umsatz generieren, Angebote gestalten oder Kundenbeziehungen aufbauen. Hier entsteht echter Wettbewerb. Diese Bereiche sollten nicht vollständig standardisiert werden, weil sie direkt Ihr Wertversprechen prägen.

Typische Beispiele:

• Pricing-Logik

• Bundling und Angebotsgestaltung

• Vertragslogik

• Subscription-Modelle

• Angebotskonfiguration

• Datenmodelle

Diese Fähigkeiten bestimmen, wie Sie verkaufen – nicht nur, was Sie verkaufen.

Das Ziel ist strategische Kontrolle.

Zukunftsfähige Commerce-Architekturen entstehen nicht durch maximale Individualität, sondern durch die bewusste Entscheidung:

Was standardisieren wir?
Was kombinieren wir?
Und was behalten wir unter eigener Kontrolle?

04 |

Neue Risiken – jenseits von Kosten und Time-to-Market

Früher lag der Fokus auf:

• Lizenzkosten

• Implementierungsdauer

• Ressourcenbedarf

Heute entscheiden andere Risiken:

• Risiko der Unbeweglichkeit
  Wenn Differenzierung in Standardsoftware gefangen bleibt
• Risiko der Fragmentierung
  Wenn Komposition ohne Governance erfolgt
• Risiko des Kontrollverlusts
  Wenn Datenhoheit fehlt

05 |

Organisation entscheidet über Architektur

Viele Unternehmen behandeln Architekturentscheidungen wie Technologieentscheidungen. Sie wählen eine Plattform, definieren eine Zielarchitektur und starten die Umsetzung.

Doch moderne Commerce-Architekturen sind keine IT-Strukturen. Sie sind Organisationsmodelle.

Denn verteilte Systeme funktionieren nur dann, wenn Verantwortung ebenso verteilt ist wie Funktionalität.

Genau hier entsteht in vielen Transformationen die größte Reibung:
Technologie wird modularisiert – Organisation bleibt zentralisiert.

Composable Commerce, API-basierte Landschaften oder Microservices versprechen Flexibilität und Geschwindigkeit. In der Praxis führen sie jedoch häufig zu wachsendem Abstimmungsaufwand, Entscheidungsengpässen und Integrationsproblemen.

Der Grund liegt selten in der Technologie.

Er liegt darin, dass technische Modularität ohne organisatorische Modularität eingeführt wird.

Wenn Pricing, Produktmodell, Customer Experience oder Vertragslogik technisch entkoppelt sind, aber weiterhin funktionsübergreifend abgestimmt oder projektbasiert entschieden werden müssen, entsteht keine Beweglichkeit – sondern Reibung.

Moderne Commerce-Architekturen verlangen daher nicht primär neue Systeme, sondern klare Verantwortungsräume.

Die entscheidende Frage lautet nicht mehr: Wer betreibt das System?

Sondern: Wer besitzt die Fähigkeit?

• Pricing wird zu einer Domäne.
• Customer Journey zu einer eigenen Verantwortung.
• Partnerintegration zu einer eigenständigen Fähigkeit.

Technische Services spiegeln diese Domänen wider.

APIs sind dabei nicht nur Schnittstellen, sondern Organisationsverträge. Sie definieren, wer welche Daten liefert, wer über Änderungen entscheidet und wer Stabilität garantiert. Ebenso entscheidend ist die semantische Ownership von Daten.

Technische Integration allein reicht nicht aus.
Organisationen müssen klären:

• Wer definiert Preislogik?
• Wer verantwortet Kundenstatus?
• Wer steuert Angebotslogik?

Ohne diese Klarheit entstehen widersprüchliche Logiken, doppelte Implementierungen und langfristig ein Verlust strategischer Kontrolle.

Modulare Architektur verlangt daher modulare Entscheidungsfähigkeit.

Teams müssen innerhalb klar definierter Verantwortungsbereiche eigenständig handeln können. Governance ersetzt dabei zentrale Kontrolle – nicht durch weniger Steuerung, sondern durch eindeutig definierte Regeln und Zuständigkeiten. An die Stelle von Abstimmung tritt Verantwortung.

Erst wenn Organisation und Architektur zusammenpassen, entsteht echte Anpassungsfähigkeit.

Technologie kann Modularität ermöglichen.

Nur Organisation kann sie nutzbar machen.

06 |

MVP neu gedacht

Ein Minimum Viable Product ist heute kein minimaler Shop. Es ist ein minimaler Wertfluss.

In klassischen Commerce-Projekten bedeutet MVP oft:

• Produkt anzeigen

• Warenkorb

• Checkout

Technisch funktionsfähig — wirtschaftlich jedoch noch nicht wirksam. Denn Sichtbarkeit ist noch kein Geschäft.

Ein modernes MVP fokussiert sich nicht auf Features, sondern auf die Fähigkeit, Wert zu erzeugen.

Die zentrale Frage lautet nicht: Welche Funktionen brauchen wir für den Go-Live?

Sondern: Welche Fähigkeiten brauchen wir, um echten Umsatz zu realisieren?

Ein wertorientiertes MVP konzentriert sich daher auf die Bausteine, die tatsächliche Transaktionen ermöglichen und skalierbar machen.

Typische MVP-Fähigkeiten sind:

• Angebotsfähigkeit – die Fähigkeit, Produkte, Services oder Bundles kontextbezogen anzubieten

• Preislogik – die Fähigkeit, Preise dynamisch oder regelbasiert zu bestimmen

• Vertragsabschluss – die Fähigkeit, Geschäftsbeziehungen formal abzuschließen

• Partnerintegration – die Fähigkeit, Dritte in den Wertfluss einzubinden

Diese Fähigkeiten bilden gemeinsam den kleinsten funktionierenden Geschäftsprozess – nicht nur eine digitale Oberfläche.

Der Unterschied ist entscheidend:

Ein Feature-MVP zeigt, dass Technologie funktioniert.
Ein Value-MVP zeigt, dass Geschäftsmodelle funktionieren.

So entsteht früh echter Business-Wert – nicht nur Funktionalität.

07 |

Ergebnis: Commerce wird steuerbar

Die Zukunft des E-Commerce gehört nicht den besten Plattformen, sondern den Unternehmen, die verstehen:

• wo Standard genügt

• wo Komposition Geschwindigkeit schafft

• wo Differenzierung unverzichtbar ist

Unternehmen, die Commerce als Entscheidungsarchitektur verstehen:

• skalieren schneller

• integrieren einfacher

• differenzieren gezielter

• bleiben technologisch beweglich

Download