Das Greenfield-Gedankenspiel. Die Architektur, die wir heute empfehlen würden.

Teil 2: Fünf Schichten, vier bis sechs Kernplattformen, drei nicht verhandelbare Prinzipien.

Vorab eine wichtige Klärung: Was hier folgt, ist ein Gedankenspiel, keine Roadmap. Wir wissen, dass kein Unternehmen seine gewachsene Tool-Landschaft einreißt und neu baut. Aber wir glauben: Wer die Zielarchitektur nicht klar vor Augen hat, kann auch keinen sinnvollen Migrationspfad bauen. Genau für diese Klarheit dient dieser Teil.

Und für die schwer zu beantwortende Frage, die am Ende von Teil 1 stehen geblieben ist: Wenn nicht Best-of-Breed der 2000er – was dann?

Was sich seit 2005 fundamental verändert hat

Vier Verschiebungen prägen das Bild von 2026 anders als das von 2005. Jede einzelne ist bedeutsam. Zusammen erklären sie, warum die alte Architektur-Logik überholt ist.

1. Infrastruktur ist Cloud geworden

Was vor 20 Jahren eine Investitions-Entscheidung war – Server kaufen, Rechenzentrum einrichten, Lizenzen erwerben – ist heute eine Konfigurations-Entscheidung: SaaS aktivieren, Konto anlegen, Abonnement starten. Die Schwelle für neue Plattformen ist drastisch gesunken. Das verändert nicht nur den Anschaffungspreis. Es verändert die ganze Logik: Plattformen sind keine Vermögensgegenstände mehr, sondern Dienstleistungen. Damit ändert sich auch, was es kostet, eine Fehlentscheidung zu korrigieren.

2. Integration ist API geworden

Vor 20 Jahren musste jede Integration einzeln entwickelt werden – ein eigenes Projekt mit eigenem Budget. Heute haben praktisch alle relevanten Plattformen offene APIs, kommerzielle iPaaS-Lösungen übernehmen das Daten-Routing, und Event-getriebene Architekturen ermöglichen lose Kopplung. Was früher die teuerste Falle des Best-of-Breed-Ansatzes war – die Schnittstellen-Suppe – ist heute eine eigene Architektur-Schicht, die man bewusst gestaltet.

3. Daten haben eine eigene Disziplin bekommen

Vor 20 Jahren waren Daten ein Nebenprodukt der Anwendungen – sie lebten in der Datenbank des jeweiligen Systems. Heute denken wir Daten getrennt von Anwendungen: zentrale Data Warehouses, Data Lakes, Master Data Management als eigene Plattform. Das ist nicht akademisch. Wer Stammdaten in einer eigenen Schicht hält, kann Anwendungen austauschen, ohne die Daten zu verlieren. Wer es nicht tut, baut einen Lock-in, der mit den Jahren immer teurer wird.

4. Die Kostenkurve für Eigenentwicklung ist durch KI gekippt

Das ist die jüngste und akuteste Verschiebung. Was bis 2022 unstrittig war – Standard-Software ist billiger als Eigenbau – ist heute eine differenzierte Rechnung. KI-gestützte Entwicklung verschiebt den Break-Even, an dem sich Eigenbau lohnt. Aber das ist Stoff für Teil 3 dieser Serie.

Diese vier Verschiebungen wirken zusammen. Keine einzelne erklärt für sich, warum Best-of-Breed der 2000er nicht mehr trägt – aber gemeinsam verändern sie die fundamentalen Annahmen, auf denen die alte Logik basierte.

Die Greenfield-Architektur als Hypothese

Wenn wir heute eine Tool-Architektur für einen typischen Mittelständler entwerfen würden, sähe sie wie folgt aus – ein Schichtenmodell aus fünf Ebenen, mit klarer Trennung der Verantwortlichkeiten.

Die Kernschicht: vier bis sechs Plattformen

Im Zentrum steht ein modernes ERP als Rückgrat – die Single Source of Truth für Finanzen, Beschaffung, Bestände, Produktion. Daneben ein CRM für Vertrieb, Service und Marketing. Je nach Geschäftsmodell ergänzt um ein PLM (für Produktdaten und Engineering-Prozesse, im Maschinenbau und in der Industrie meist unverzichtbar) und ein MES (für Fertigungsausführung). Ergänzt um eine Daten- und BI-Plattform für analytische Auswertungen quer über alle Systeme.

Das sind vier bis sechs Plattformen, nicht 47. Jede mit klarer Funktions-Verantwortung. Jede mit definiertem Datenmodell. Jede mit eigenem Betriebs-Verantwortlichen. Das ist nicht weniger Differenzierung gegenüber dem Zoo – es ist mehr.

Die Integrations-Schicht: eine bewusste Architektur

Statt Punkt-zu-Punkt-Verbindungen eine iPaaS-Lösung oder ein Event-Backbone. Daten fließen über eine zentrale Routing-Schicht – keine direkte Datenbank-zu-Datenbank-Verbindung. Das hat zwei Vorteile: Erstens ist nachvollziehbar, welche Daten wohin fließen. Zweitens kann eine einzelne Plattform ausgetauscht werden, ohne dass die ganze Schnittstellen-Landschaft mitstirbt. Das ist die strukturelle Antwort auf das größte Risiko des alten Best-of-Breed-Ansatzes.

Die Daten-Schicht: ein zentrales Modell

Stammdaten leben nicht im ERP oder CRM – sie leben in einer eigenen Master-Data-Schicht und werden von dort an die Anwendungen verteilt. Kunden, Materialien, Lieferanten haben jeweils einen Eigentümer (eine Plattform, die die führende Quelle ist), und die anderen Systeme bekommen synchronisierte Kopien. Das ist die organisatorische Antwort auf das Stammdaten-Chaos, das wir in fast jeder Bestandsaufnahme finden.

Die Erweiterungs-Schicht: Low-Code und gezielte Eigenentwicklung

Nicht jeder Workflow muss in einer Standard-Plattform abgebildet werden. Spezial-Workflows, die nur eine kleine Nutzergruppe betreffen oder unternehmens-spezifisch sind, gehören in eine Low-Code-Plattform oder eine kontrollierte Eigenentwicklung – aber bewusst, nicht als Schatten-IT. Diese Schicht ist die Antwort auf den Wunsch nach Flexibilität, ohne in den Wildwuchs zurückzufallen.

Die Erlebnis-Schicht: Portale, mobile Apps, Self-Service

Die Schicht, die der Anwender sieht. Idealerweise bekommen Mitarbeiter, Kunden und Partner nicht den Direktzugang zu den Kernsystemen, sondern aufgabenspezifische Oberflächen, die genau das anzeigen, was sie für ihre Aufgabe brauchen. Das reduziert Schulungsaufwand und schützt die Kernsysteme vor Über-Bedienung.

Fünf Schichten, vier bis sechs Kernplattformen, klare Trennung der Verantwortlichkeiten. Das ist das Bild der Greenfield-Architektur, wie wir sie heute empfehlen würden.

→ Wir würden heute keinen Zoo mehr empfehlen. Aber auch keinen Monolithen.

Composable oder Suite – die strategische Wahl

An dieser Stelle die wichtigste strategische Entscheidung: Wer baut die Kernschicht? Zwei extreme Ansätze, plus einen pragmatischen Mittelweg.

Die Suite-Strategie

Alle Kernfunktionen aus einer Hand. Ein integriertes ERP, das auch CRM-, PLM- und gegebenenfalls MES-Funktionen mitbringt. Anbieter wie SAP S/4 oder Microsoft Dynamics 365 verfolgen diesen Ansatz. Der Vorteil: weniger Schnittstellen, gemeinsames Datenmodell ab Werk, ein Vertragspartner. Der Nachteil: starker Lock-in, Best-of-Breed-Funktionen oft nur mittelmäßig abgebildet, hohe Lizenzkosten für nicht-genutzte Module.

Die Composable-Strategie

Jede Kernfunktion mit der jeweils besten Plattform abdecken. ERP von Anbieter A, CRM von Anbieter B, PLM von Anbieter C – verbunden über die Integrations-Schicht. Der Vorteil: tatsächliches Best-of-Breed, hohe Flexibilität, geringere Abhängigkeit von einzelnen Anbietern. Der Nachteil: Disziplin erforderlich. Ohne klare Integrations-Architektur landet man in fünf Jahren wieder im Zoo.

Unsere ehrliche Empfehlung: Hybrid mit Disziplin

Suite für die Kernprozesse, wo Integration und konsistente Daten kritisch sind – ERP plus angeschlossenes CRM aus derselben Familie ist meist die richtige Wahl. Best-of-Breed für strategisch differenzierende Bereiche, in denen Spezial-Funktionalität wertschöpfend ist – PLM im Maschinenbau, MES in der Fertigung, BI-Plattformen mit eigenständiger Stärke.

Das ist nicht das alte Best-of-Breed neu verpackt. Der Unterschied liegt in der bewussten Integrations-Schicht und der zentralen Daten-Schicht. Wir lassen Best-of-Breed nicht mehr zufällig wachsen – wir designen es.

→ Die richtige Frage ist nicht welches System, sondern welche Architekturprinzipien.

Drei nicht verhandelbare Designprinzipien

Welche Plattformen man auch wählt: Drei Prinzipien sind aus unserer Sicht nicht verhandelbar. Sie sind das, was die neue Greenfield-Architektur von der alten Best-of-Breed-Logik unterscheidet.

Eine Source of Truth pro Datenobjekt

Für jedes geschäftskritische Datenobjekt – Kunde, Material, Lieferant, Auftrag – gibt es genau ein System, das die führende Wahrheit hält. Alle anderen bekommen synchronisierte Kopien. Wer den Kunden in drei Systemen unabhängig pflegt, baut den nächsten Zoo. Wer dieses Prinzip akzeptiert, muss organisatorisch klären, wer für welches Datenobjekt verantwortlich ist – und das ist mehr als eine technische Frage.

APIs vor Datenbank-Zugriffen

Wenn System A Daten aus System B braucht, dann über die API von B – niemals direkt aus der Datenbank. Das klingt selbstverständlich, ist aber in der Praxis oft anders: Berichts-Tools greifen direkt auf ERP-Datenbanken zu, Migrations-Werkzeuge umgehen die Anwendungs-Logik, BI-Systeme lesen aus Replikaten. Jede direkte Datenbank-Schnittstelle ist eine Architektur-Schuld, die später teuer wird, wenn das Quellsystem ausgetauscht werden soll.

Klare Domänen-Verantwortung

Jeder Geschäftsprozess hat einen Eigentümer auf Fachseite – nicht in der IT – und ist klar einer Plattform zugeordnet. Wenn drei Plattformen den Bestellprozess gleichzeitig abbilden, hat niemand mehr die Hoheit darüber, wie er aussehen soll. Architektur-Klarheit folgt aus organisatorischer Klarheit, nicht umgekehrt.

Diese drei Prinzipien sind das, was die Greenfield-Architektur am Leben hält, nachdem sie gebaut wurde. Ohne sie wird aus der schönsten Architektur in fünf Jahren der nächste Zoo.

Aber moment – mit KI können wir doch alles selbst bauen?

Hier ist die unbequeme Frage, die wir oft hören und der wir nicht ausweichen wollen. Wenn KI die Eigenentwicklung dramatisch billiger macht – warum dann überhaupt noch Plattformen? Warum nicht alles selbst bauen?

Die Antwort verdient einen eigenen Artikel. Deshalb ist sie Teil 3 unserer Serie. So viel vorab: Die Verschiebung der Kostenkurve durch KI verändert tatsächlich die Make-or-Buy-Rechnung – aber sie macht alles selbst bauen nicht zur klugen Strategie. Sie verschiebt nur die Grenze, an der Eigenbau sinnvoll wird. Welche Bereiche das sind, welche neuen Risiken damit entstehen und wie sich das in die hier beschriebene Architektur einfügt, schauen wir uns in zwei Wochen genauer an.

Was bleibt aus diesem Teil

Vorerst bleibt dieses Bild stehen: Fünf Schichten, vier bis sechs Kernplattformen, eine bewusste Integrations- und Datenschicht, drei nicht verhandelbare Prinzipien. Das ist die Empfehlung, die wir heute geben würden, wenn jemand mit einem leeren Whiteboard käme.

An alle, die jetzt denken in der Praxis baut niemand auf der grünen Wiese: Stimmt. Genau deshalb wird Teil 5 dieser Serie sich dieser Frage widmen – wie man vom heutigen Zoo zur Architektur kommt, ohne Big Bang, ohne das Tagesgeschäft zu lähmen. Aber bevor wir den Migrationspfad zeichnen können, brauchen wir die Zielarchitektur. Dieser Teil war dieses Ziel.

Und die wichtigste Frage zum Mitnehmen: Wenn Sie heute einen Architektur-Workshop in Ihrem Unternehmen aufsetzen würden – wie viele Schichten und Kernplattformen würden Sie am Ende auf dem Whiteboard haben? Und sind es eher fünf – oder eher 47?