Von außen betrachtet wirken viele PMI-Software-Suiten wie ein perfekt designter Quilt – eine harmonische Oberfläche aus einem Guss. Doch wer die Nähte genauer untersucht, entdeckt oft eine andere Realität: ein kunstvolles Patchwork aus unterschiedlichen Stoffen, Garnen und Techniken, die nur an der Oberfläche zusammengehalten werden. Dieser Artikel beschreibt mit technischer Klarheit, warum viele PMI-Suiten im Inneren Patchwork-Konstrukte sind, bewertet die Folgen aus unterschiedlichen Perspektiven und zeigt, welche Architekturmuster in verschiedenen Kontexten relevant werden.

Haftungsausschluss: Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Anlageberatung, Rechtsberatung oder verbindliche Handlungsempfehlung dar. Die Ausführungen basieren auf meiner Erfahrung als unabhängiger Senior Business Consultant und Analyst.

1. Begriffsklärung: Was ist ein Patchwork-System?

Ein Patchwork-System ist keine pauschale Abwertung, sondern eine präzise technische Beschreibung: eine „Suite“, die funktional breit aufgestellt ist, sich aber intern aus heterogenen Modulen zusammensetzt. Diese Module können unterschiedliche Codebasen, Datenmodelle und Zeitlogiken haben. Sie sind oft über ETL-Jobs, Mapping-Tabellen oder UI-Aggregator-Layer verbunden — nicht über ein gemeinsames, temporales Datenmodell.

• Module mit eigenen Datenmodellen (GL-orientiert vs. Portfolio-orientiert vs. Reporting-orientiert)
• Heterogene Technologie-Stacks (Java, .NET, Python, legacy VBA/Excel)
• Integration in der Regel Batch-getrieben statt event-chronologisch
• Unterschiedliche Historisierungslogiken und Audit-Modelle

Patchwork heißt also: funktionale Breite, technische Heterogenität.

2. Wann Patchwork legitim ist – und wann Risiken entstehen

Modulare Architekturen sind per se kein Problem. Best-of-Breed-Ansätze, Microservices und Domain-Driven Design basieren bewusst auf Heterogenität – mit klaren Integrationsgrenzen und definierten Schnittstellen. Problematisch wird Patchwork typischerweise, wenn:

• Keine bewusste Integrationsstrategie existiert: Module wurden ad-hoc verbunden, nicht architektonisch geplant
• Module unterschiedliche Zeitlogiken haben: Event-basiert vs. periodisch vs. batch-getrieben ohne Reconciliation-Layer
• Daten manuell reconciliert werden müssen: Systematische Differenzen zwischen Modulen erfordern wiederkehrende manuelle Eingriffe
• Keine gemeinsame Taxonomie existiert: Gleiche Begriffe bedeuten in verschiedenen Modulen unterschiedliche Dinge

Der Unterschied liegt also nicht in der Modularität selbst, sondern darin, ob die Integration by design oder by workaround erfolgt.

3. Warum PMI-Vendoren strukturell anfällig sind

Die Marktdynamik erzeugt spezifische Pfadabhängigkeiten:

• Kleiner TAM (Total Addressable Market): Weniger Scale → begrenzte F&E-Budgets für grundlegende Neuentwicklungen.
• Wachstum durch Akquisition: Anbieter vergrößern Funktionalität oft durch Zukauf spezialisierter Lösungen. Tiefe Re-Integration ist zeitintensiv und risikoreich.
• Historisch getrennte Funktionscluster: Fund Accounting, Portfolio Management und Reporting entstanden häufig separat — mit eigenen Prioritäten und Modellen.
• Time-to-Market über Re-Design: Kunden verlangen schnelle Lösungen; Anbieter ergänzen lieber als neu zu bauen.

Technisch führt das zu einem „Wachstumsmodus“, der Integration überbrückt statt sie strukturell zu lösen. Diese Dynamik ist nachvollziehbar – führt aber zu spezifischen Konsequenzen.

4. Drei typische Patchwork-Formen in der Praxis

A) Modul-Heterogenität

Module haben abweichende Begriffsdefinitionen (z. B. „Commitment“, „Available Funds“, „NAV“), unterschiedliche Historienmodelle und separate Validierungslogiken. Ein Feld, das in Modul A als Event verarbeitet wird, ist in Modul B vielleicht nur als Stichtagswert bekannt.

B) Technologie-Heterogenität

Verschiedene Laufzeitumgebungen, Programmiersprachen und Release-Zyklen sorgen für technische Silos. API-Standards fehlen oder variieren; Authentifizierungs- und Deployment-Prozesse sind inkonsistent.

C) Operationales Patchwork

In vielen Setups „richtet“ eine Batch-Kette die Systeme einander ein: Daten werden transformiert, abgeglichen, manuell verifiziert. Für Ausnahmen existieren manuelle Workarounds und Shadow-Prozesse.

Architektur-Typ	Charakteristik	Stärke	Herausforderung
Monolith	Ein Datenmodell, eine Codebase	Konsistenz, einfache Transaktionen	Unflexibel, hohe Anpassungskosten
Best-of-Breed mit bewusster Integration	Spezialisierte Module, definierte Schnittstellen	Flexibilität + Konsistenz möglich	Hoher Integrationsaufwand, klare Governance nötig
Patchwork (ad-hoc)	Heterogene Module, Batch-Integration	Schnelle funktionale Erweiterung	Technische Schulden, manuelle Reconciliation

5. Konsolidierungswelle: Kaufen ist einfach – integrieren ist die eigentliche Herausforderung

In den letzten Jahren haben große Anbieter zahlreiche spezialisierte Lösungen akquiriert. Strategisch ist das sinnvoll, um Marktabdeckung zu erweitern. Technisch ist die Akquisition der einfache Teil; die eigentliche Herausforderung ist die Integration. Akquisitionen bringen typischerweise eigene Datenmodelle, differente Zeitlogiken und unterschiedliche Release-Zyklen mit. Integrationsmuster sind meist Batch-Synchronisationen, Mapping-Engines oder UI-Aggregator-Schichten. Diese Wege erzeugen zwar Funktionalität, verlagern aber technische Komplexität in die Mittelschicht.

6. Die spezifischen Anforderungen von Private Markets

Private Markets erfordern eine event-getriebene Sicht: Commitments, Drawdowns, Distributions und Bewertungsevents sind sequenziell und historisch relevant. Systeme müssen eine Zeitachse rekonstruieren können. Patchwork-Systeme ohne explizite Temporallogik sind oft relational oder periodisch konstruiert, was die Recompute-Fähigkeit einschränkt. In solchen Setups entstehen typischerweise Inkonsistenzen, die manuelle Reconciliations oder separate Schatten-IBORs erforderlich machen. Diese Diskrepanz zwischen Anforderung und Architektur ist messbar – und hat konkrete operative Konsequenzen.

7. Operative Konsequenzen aus unterschiedlichen Perspektiven

Die Auswirkungen von Patchwork-Architekturen unterscheiden sich je nach Stakeholder-Gruppe:

Für Asset Manager (Anwenderseite):

• Mehrere konkurrierende „Wahrheiten“ (unterschiedliche NAVs, Cash-Views)
• Längere Korrektur- und Abstimmungszyklen
• Erhöhter Aufwand bei der Einführung neuer Felder oder Produkte
• Erhöhte Kosten für Betrieb, Testing und Integration
• Abhängigkeit von spezialisierten Integrations-Teams

Für Softwareanbieter (Vendorseite):

• Schnellere funktionale Marktabdeckung durch Zukäufe
• Reduziertes Risiko bei Neuentwicklungen (erprobte Lösungen)
• Erhöhte Komplexität in Support, Release-Management und Dokumentation
• Langfristige technische Schulden, die zukünftige Innovationen bremsen

Beide Perspektiven sind legitim. Die Frage ist, ob die Trade-offs bewusst gewählt und transparent kommuniziert werden.

8. Architektur-Muster, die Integrationskomplexität reduzieren

Folgende Architekturmuster können helfen, die Komplexität von heterogenen Systemlandschaften zu reduzieren:

• Echtes Event-Sourcing mit rekonstruierbarer Historie
• Ein einheitliches temporales Datenmodell oder bitemporale Historisierung
• Eine zentrale Engine für Business-Logik statt Logik verteilt in Modulen
• Eine konsistente Taxonomie / Ontologie als Shared Layer zwischen Modulen
• Ein Data Dictionary zur Steuerung neuer Felder über alle Module hinweg

Die Priorisierung hängt vom jeweiligen Kontext ab:

• Für Greenfield-Projekte: Event-Sourcing + temporales Modell von Anfang an
• Für Brownfield-Migration: Zentrale Taxonomie + Data Dictionary als erste Schritte
• Für akquisitionsgetriebenes Wachstum: API-first mit strikten Standards und Governance-Prozessen

Solche Muster verringern technische Schuld und erhöhen die Agilität. Ihre Implementierung ist jedoch ressourcenintensiv — daher bleiben sie in akquisitionsgetriebenen Roadmaps oft nachrangig.

Checkliste für Entscheider: 5 Fragen, die Sie Ihrem Software-Anbieter stellen sollten

1. Welche Datenmodelle existieren in Ihrer Suite und wie werden semantische Inkonsistenzen zwischen ihnen aufgelöst? Gibt es eine zentrale Taxonomie oder ein Mapping-Framework?
2. Wie werden Daten zwischen dem akquirierten Modul X und Ihrem Kernmodul Y synchronisiert – per Echtzeit-Event oder per nächtlichem Batch-Lauf? Wie wird Konsistenz sichergestellt?
3. Wie wird ein neues, benutzerdefiniertes Feld systemweit ausgerollt? Ist dies eine Konfiguration im Data Dictionary oder erfordert es Anpassungen in den Codebasen mehrerer Module?
4. Welche Teile Ihrer Suite basieren noch auf einer Architektur von vor 10 Jahren und wie sieht Ihre konkrete Roadmap zur Modernisierung dieser Komponenten aus?
5. Wie stellen Sie sicher, dass eine rückwirkende Korrektur in einem Modul konsistent in allen anderen Modulen nachvollzogen wird? Ist dies automatisiert oder erfordert es manuelle Schritte?

Diese Fragen zielen nicht darauf ab, Anbieter zu diskreditieren, sondern Transparenz über die tatsächliche Integrationstiefe zu schaffen.

Fazit

Viele PMI-„Suites“ sind funktional breit, architektonisch jedoch heterogen. Konsolidierung per Zukauf erklärt, warum das so ist: Kaufen ist ein schneller Hebel; tiefgreifende Integration ist langwierig und teuer. Diese Dynamik ist aus Anbietersicht rational – Asset Manager müssen jedoch verstehen, welche Teile einer Suite wirklich integriert sind und welche nur funktional zusammengeführt wurden.

Die entscheidende Frage bei der Anbieterauswahl ist daher nicht, ob die Funktionen vorhanden sind, sondern wie sie integriert wurden. Die Unterscheidung zwischen funktionaler Integration (es funktioniert irgendwie) und architektonischer Integration (es basiert auf einem gemeinsamen Fundament) ist der Schlüssel zu einer zukunftsfähigen Systemlandschaft.

In der aktuellen Konsolidierungswelle wird diese Frage immer drängender: Asset Manager sollten kritisch evaluieren, welche Architekturmuster ihre zukünftigen Anforderungen am besten unterstützen – bevor sie sich für 5-10 Jahre an eine Plattform binden. Die Antworten auf die obigen Checklisten-Fragen können dabei helfen, die tatsächliche Integrationstiefe einer Suite zu verstehen und fundierte Entscheidungen zu treffen.