Die dwpbank kündigt mit WP3 eine cloud-native Wertpapierplattform für zwei Drittel deutscher Banken an – mit Microservices, Bare-Metal-Kubernetes und Active/Active-Betrieb. Die Ankündigung folgt dem bekannten Muster der deutschen Finanz-IT: technologisch ambitioniert, architektonisch überzeugend, institutionell fragil. Eine Analyse der strukturellen Hürden zwischen Konzept und Umsetzung.
Die Ankündigung als Symptom
Die dwpbank positioniert ihre WP3-Plattform als Antwort auf jene Probleme, an denen Finanz Informatik und Atruvia seit Jahren laborieren: Legacy-Ablösung, Modernisierung monolithischer Strukturen, regulatorische Agilität. Cloud-native Architektur, Microservices auf Bare-Metal-Kubernetes, zwei Rechenzentren im Active/Active-Betrieb – die technische Roadmap liest sich wie ein Lehrbuchbeispiel zeitgemäßer Infrastruktur-Strategie.
Bemerkenswert ist nicht die technologische Ambition, sondern der institutionelle Kontext. WP3 operiert im gleichen Ökosystem genossenschaftlicher und sparkassennaher IT-Dienstleister, das strukturell für Konsenszwänge, Governance-Komplexität und risikoaverse Entscheidungsprozesse bekannt ist. Die Frage ist nicht, ob die Architektur theoretisch funktionieren kann, sondern ob sie im praktischen Betrieb die Versprechungen einlöst – oder ob sich hier erneut die “PR-Schere” öffnet zwischen kommunizierter Innovation und operativer Realität.
Architektonische Versprechen und operative Risiken
Active/Active als Prüfstein: Der angekündigte Betrieb zweier Rechenzentren im Active/Active-Modus mit automatisiertem Failover “im Minutenbereich” markiert eine kritische Schwachstelle. Echte Active/Active-Architekturen auf Kubernetes mit State-Synchronisation erfordern Millisekunden-Latenz, konsistente Datenhaltung über Rechenzentren hinweg und fehlerfreie Split-Brain-Prävention. “Minuten” als Zeitrahmen deutet auf manuelle Eingriffe oder semi-automatisierte Prozesse hin – ein Hinweis darauf, dass zwischen Architektur-Diagramm und Produktivbetrieb erhebliche Kompromisse liegen.
Mikroservices ohne Transaktionsgrenzen: Die Zerlegung monolithischer Strukturen in Microservices ist architektonisch sinnvoll – scheitert aber regelmäßig an der Realität verteilter Transaktionen. Wenn die neue Service-Architektur weiterhin auf zentrale, relationale Datenbanken zugreift oder wenn die Transaktionsgrenzen nicht sauber zwischen Services gezogen sind, entsteht ein “verteilter Monolith”: äuße…