Board-Advisory & CTO-Sparring

Board-Advisor im Finanzsektor: Vom Legacy-Monolith zur skalierbaren Plattform

Wie ich als Board-Advisor einen CTO beim Aufbau einer Tech-Organisation, Cloud-Migration, Finanzdienstleister-Integration und Etablierung im Vorstand begleitet habe. 5 kritische Lektionen aus 18 Monaten Plattform-Transformation im Finanzsektor.

📖 21 Min. Lesezeit
Board-Advisory CTO-Sparring Finanzsektor Plattform-Transformation Tech-Organisation Cloud-Migration Strangler-Pattern

Board-Advisor im Finanzsektor: Vom Legacy-Monolith zur skalierbaren Plattform

Nach meiner Tätigkeit als CTO und Geschäftsführer eines Fintechs im Bereich KMU-Finanzierung übernahm ich die Rolle des Board-Advisors bei einem jungen, wachsenden Finanzdienstleister – ebenfalls im KMU-Finanzierungsbereich. Verantwortung: Technology. Auftrag: Den CTO als Sparring-Partner unterstützen.

Die Situation? Ein neu eingestellter CTO hatte eine "verbaute Anwendung" geerbt – ein 6 Jahre alter Python-Monolith, der in der Startup-Phase schnell gewachsen war und mit jedem Feature-Request weiter gepatcht wurde. Das Ziel war klar, aber ambitioniert: Daraus eine skalierbare Plattform bauen.

Nicht durch einen riskanten Big-Bang-Rewrite. Sondern pragmatisch, schrittweise, ohne das laufende Geschäft zu gefährden. Und gleichzeitig: Eine moderne Tech-Organisation aufbauen, Cloud-Infrastruktur etablieren, Finanzdienstleister-Integrationen umsetzen, und den CTO im Vorstand verankern.

18 Monate. 5 kritische Transformations-Bereiche. Unzählige Lessons Learned.

In diesem Artikel teile ich die Herausforderungen, Strategien und praktischen Learnings aus dieser Board-Advisory-Rolle – für CTOs, die vor ähnlichen Herausforderungen stehen, und Vorstände, die verstehen wollen, was Technology-Transformation wirklich bedeutet.

Der Kontext: Warum Board-Advisory im Finanzsektor besonders ist

Die Ausgangslage

Das Unternehmen:

  • Junger Finanzdienstleister mit 6 Jahren Marktpräsenz (Post-Startup, Scale-up-Phase)
  • Fokus: Digitale KMU-Finanzierung (Kredite €50k-€500k für kleine und mittlere Unternehmen)
  • Tech-Team: 22 Entwickler, keine dedizierte DevOps/Infrastructure

Das technische Erbe:

  • Monolithischer Python-Stack (Django 2.x, gewachsen über 6 Jahre)
  • PostgreSQL mit 800GB Daten (Kreditanträge, Bonitätsdaten, Transaktionen)
  • Hosting mit shared VMs, keine Container/Orchestrierung
  • Deployment: Alle 4-6 Wochen, semi-manuell (shell scripts + manual verification)
  • Testing: Hauptsächlich manuell, minimale Unit-Tests, keine Integration-Tests
  • Dokumentation: Fragmentiert, teilweise veraltet, viel Wissen nur in Köpfen

Der neue CTO:

  • Aus Scale-up-Umfeld kommend (moderne Tech-Stacks)
  • Starke technische Vision, aber neu im regulierten Finanzsektor
  • Ohne etabliertes Netzwerk im Vorstand
  • Vor der Aufgabe: Legacy-System transformieren UND Organisation modernisieren

Meine Rolle als Board-Advisor:

  • Sparring-Partner für CTO und CEO
  • Technology-Verantwortung auf Board-Level
  • Brücke zwischen Vorstand und Tech-Organisation
  • Keine operative Line-Verantwortung, aber strategische Entscheidungshoheit

Warum Finanzsektor anders ist

Die Herausforderungen einer Plattform-Transformation im Finanzsektor unterscheiden sich fundamental von anderen Branchen:

Regulatorische Komplexität:

  • BaFin-Aufsicht: Jede Architektur-Änderung dokumentations- und genehmigungspflichtig
  • Audit-Trails: Lückenlose Nachverfolgbarkeit aller Transaktionen
  • Outsourcing-Regulierung: Cloud-Nutzung erfordert BaFin-Anzeige

Finanzdienstleister-Integration:

  • Partner-Banken für Kreditauszahlung (3 Banken, unterschiedliche APIs)
  • Bonitätsprüfungs-Provider (SCHUFA, Creditreform, Custom-Scoring)
  • Buchhaltungssystem-Anbindungen (DATEV, lexoffice für KMU-Daten-Import)
  • KYC/AML-Compliance-Tools (Identity-Verification)

Business-Continuity-Anforderungen:

  • Kreditantrags-Prozess: 24/7 verfügbar (KMUs beantragen außerhalb Geschäftszeiten)
  • Disaster-Recovery-Zeit: < 8 Stunden (regulatorische Anforderung)
  • Data-Loss-Tolerance: 0 Kreditanträge (jeder Antrag ist Geschäft)
  • High-Availability: 99.5% SLA (weniger kritisch als Trading, aber wichtig)

In diesem Umfeld eine Plattform-Transformation durchzuführen? Das erfordert mehr als technische Exzellenz. Es erfordert Board-Level-Navigation, regulatorisches Verständnis, und die Fähigkeit, Risiko gegen Innovation abzuwägen.

Transformations-Bereich 1: Aufbau einer modernen Tech-Organisation

Das Problem: Strukturelle Bottlenecks

Als ich die Organisation das erste Mal analysierte, sah ich ein klassisches Pattern:

Organisationsstruktur (Vorher):

CTO (neu)
  └── Tech-Lead (seit 10 Jahren, kennt System in/out)
        ├── 4 Teams à 5-7 Entwickler (funktional: Backend, Frontend, DB, Ops)
        ├── Keine klaren Ownership-Grenzen
        ├── Alle Entscheidungen laufen über Tech-Lead
        └── CTO hat keinen direkten Zugang zu Teams

Die Symptome:

  • Single Point of Failure: Tech-Lead ist Bottleneck für alle Entscheidungen
  • Fehlende Ownership: Keiner ist für End-to-End-Features verantwortlich
  • CTO-Isolation: Neu eingestellter CTO hat kaum Einblick in operative Realität
  • Silos: Backend-Team wartet auf DB-Team, Frontend wartet auf Backend
  • Lange Lead Times: Feature-Requests dauern 3-6 Monate
  • Knowledge-Hoarding: Kritisches Wissen in wenigen Köpfen konzentriert

Für den Vorstand war das unsichtbar – solange Features (irgendwann) geliefert wurden, schien alles zu funktionieren. Aber für den CTO war es ein strategisches Risiko.

Die Lösung: Product-orientierte Team-Topologie

In den ersten 8 Wochen meiner Advisory-Rolle arbeitete ich eng mit dem CTO an einer neuen Organisations-Strategie. Orientierung: Team Topologies nach Skelton & Pais.

Neue Struktur:

CTO
  ├── VP Engineering (promoviert aus Tech-Lead)
  │     ├── Stream-Aligned-Team 1: Trading-Plattform (7 Entwickler)
  │     ├── Stream-Aligned-Team 2: Portfolio-Management (6 Entwickler)
  │     └── Stream-Aligned-Team 3: Reporting & Analytics (5 Entwickler)
  │
  ├── Platform-Team (8 Entwickler)
  │     ├── Cloud-Infrastruktur
  │     ├── CI/CD-Pipelines
  │     └── Developer-Experience-Tools
  │
  └── Enabling-Team (2 Entwickler, rotierend)
        ├── Architecture-Guidance
        └── Best-Practices-Coaching

Key Changes:

1. Stream-Aligned-Teams mit End-to-End-Ownership:

  • Jedes Team verantwortlich für komplette Wertströme (von User-Request bis Production)
  • Cross-functional: Backend, Frontend, Testing innerhalb eines Teams
  • Product-Owner embedded (aus Fachbereich)
  • Autonomie: Teams entscheiden über Tech-Stack innerhalb definierten Rahmens

2. Platform-Team als Enabler:

  • Baut interne Plattform-Services (Self-Service-CI/CD, Monitoring, Secrets-Management)
  • Reduziert Cognitive Load für Stream-Teams ("Ihr baut Features, wir bauen Plattform")
  • KPI: Developer-Productivity (gemessen via DORA-Metriken)

3. Tech-Lead wird VP Engineering:

  • Statt Bottleneck: Enabler und Coach
  • Fokus: Team-Entwicklung, Hiring, Performance-Management
  • Technische Entscheidungen delegiert an Stream-Teams

4. CTO bekommt direkten Zugang:

  • Wöchentliche 1:1s mit Stream-Team-Leads
  • Monatliche All-Hands mit gesamtem Tech-Team
  • Transparenz: OKRs, DORA-Metriken, Architecture-Decision-Records öffentlich

Der Rollout: Change-Management in der Praxis

Woche 1-2: Stakeholder-Alignment

  • Pitch an Vorstand: "Warum Reorg notwendig ist" (mit Metriken: Lead Time, Deployment Frequency)
  • Pitch an Tech-Team: "Was sich für euch verbessert" (mehr Autonomie, weniger Bottlenecks)
  • Einzelgespräche mit Tech-Lead: "Du wirst nicht degradiert – du wirst befördert"

Woche 3-4: Pilot mit einem Team

  • Trading-Plattform-Team wird erstes Stream-Aligned-Team
  • 4-Wochen-Experiment: Komplette Ownership für neue Features
  • Messung: Deployment-Frequency (vorher: 1x/6 Wochen → nachher: 2x/Woche)
  • Retrospektive: Was funktioniert? Was nicht?

Woche 5-12: Rollout auf alle Teams

  • Sukzessive Umstellung aller Teams
  • Parallel: Platform-Team aufbauen (2 Entwickler aus jedem Stream-Team rekrutiert)
  • Training: Team Topologies Workshops, Product-Ownership-Training

Monat 4-6: Stabilisierung

  • Teams finden ihre Rhythmen
  • DORA-Metriken etablieren (Lead Time, Deployment Frequency, MTTR, Change Fail Rate)
  • Anpassungen basierend auf Feedback

Die Ergebnisse nach 6 Monaten

Quantitativ:

  • Deployment Frequency: 1x/6 Wochen → 3x/Woche (+1800%)
  • Lead Time: 12 Wochen → 3 Wochen (-75%)
  • Change Fail Rate: 18% → 7% (-61%)
  • MTTR: 4.5h → 1.2h (-73%)

Qualitativ:

  • CTO ist jetzt "Teil des Teams" statt "der neue Chef von oben"
  • Tech-Lead (jetzt VP Engineering) ist zufriedener ("Ich kann endlich coachen statt mikromanagen")
  • Entwickler berichten von höherer Autonomie und Klarheit
  • Vorstand sieht schnellere Feature-Delivery

Das Learning: Organisation ist wichtiger als Technologie. Bevor wir auch nur eine Zeile Code migriert hatten, verdoppelten wir die Velocity – nur durch bessere Struktur.

Transformations-Bereich 2: Cloud-Infrastruktur-Neuaufbau

Das Problem: Lock-in ohne Skalierbarkeit

Die alte Infrastruktur:

  • Dedicated Servers (seit Gründung, 6 Jahre alt)
  • 4 physische Server (shared VMs, keine Container/Orchestrierung)
  • Ubuntu 18.04 (LTS-Support endet bald)
  • Manuelle Deployments (SSH + shell scripts + prayer)
  • Backup: rsync zu zweitem Server (Disaster-Recovery ungetestet)
  • Kosten: €3.500/Monat (€42k/Jahr – günstig, aber limitiert)

Die Risiken:

  • Compliance: BaFin fordert nachweisbare Disaster-Recovery-Konzepte (aktuell nicht vorhanden)
  • Skalierung: Kreditantrags-Peaks (Monatsende) führen zu Slow-Downs
  • Security: Kein WAF, kein DDoS-Schutz, manuelles Patching
  • Recruiting: "Wir hosten bei X ohne Kubernetes" ist kein Selling-Point

Das Vorstand-Dilemma: "Hoster kostet nur €42k/Jahr. Cloud wird €150k+ kosten. Warum sollten wir das machen?"

Die Strategie: Hybrid-Ansatz mit klarem ROI

Phase 1: Cloud-Native für neue Workloads (Monate 1-6)

Statt Big-Bang-Migration: Neue Features werden direkt Cloud-Native gebaut.

Architektur-Entscheidung:

  • AWS als Cloud-Provider (Gründe: Python/Django-Ökosystem, BaFin-Compliance, Frankfurt-Region, mature FinTech-Services)
  • Hybrid-Connectivity: VPN zwischen X und AWS (während Transition)
  • Identity: AWS Cognito für User-Auth, IAM für Service-Auth

Erste Cloud-Workloads:

1. Credit-Scoring-Service (neu gebaut):

  • AWS Lambda + API Gateway (Serverless, Event-driven)
  • Amazon RDS PostgreSQL (Managed, automatisches Patching, Multi-AZ)
  • S3 für Dokumenten-Storage (Kreditantrags-PDFs)
  • Ergebnis: Feature in 5 Wochen live (alte Welt: 4 Monate)
  • Kosten: €800/Monat (skaliert automatisch mit Load)

2. CI/CD-Pipeline:

  • GitHub Actions (Git, Pipelines, Artifacts)
  • Self-Service-Deployments für Entwickler (Push to main → auto-deploy to staging)
  • Automatische Tests bei jedem Commit (pytest, coverage-check)
  • Ergebnis: Deployments von 3h (manuell) auf 8min (automatisiert)

3. Monitoring & Observability:

  • Datadog (APM, Logging, Metrics – FinTech-Standard)
  • CloudWatch für AWS-native Services
  • PagerDuty für On-Call-Management
  • Ergebnis: MTTR von 3.5h auf 45min (siehe oben)

Phase 2: Containerisierung des Monoliths (Monate 7-12)

Nachdem Cloud-Kompetenz etabliert war: Legacy-Django-Monolith containerisieren und nach AWS migrieren.

Ansatz: Strangler-Fig-Pattern

  • Nicht alles auf einmal, sondern Modul für Modul
  • Zuerst: Read-Only-Workloads (Reporting, Dashboard)
  • Dann: Write-Workloads (Kreditantrags-Processing)
  • Zuletzt: Core-System (Credit-Scoring, Payment-Processing)

Pilot: Reporting-Modul migrieren

Vorher:

  • Django-Monolith auf VM
  • 8h Batch-Job jede Nacht (Aggregation von Kredit-Performance-Daten)
  • Bei Fehlern: SSH rein, manuell debuggen

Migration (4 Wochen):

  • Woche 1: Dockerize Reporting-Modul, RDS PostgreSQL provisionieren
  • Woche 2: Data-Migration (Initial Load + pg_logical Replication für Delta-Sync)
  • Woche 3: Deploy zu ECS Fargate (Managed Container Service)
  • Woche 4: Cutover (Feature-Flag: 10% → 50% → 100%)

Nachher:

  • ECS Fargate (Managed Container, Auto-Scaling)
  • Batch-Job läuft auf AWS Batch (Serverless Compute)
  • Kosten: €1.800/Monat (vs. €1.200/Monat Hoster anteilig, aber mit Auto-Scaling)
  • Performance: 8h → 2.5h (bessere Parallelisierung)

Phase 3: Hoster-Exit (Monate 13-18)

Nach 12 Monaten: 70% der Workloads in AWS. Hoster kann in 6 Monaten gekündigt werden.

Finale Migration:

  • Restliche Django-Apps containerisieren und nach AWS migrieren (weitere 6 Monate)
  • VPN zwischen Hoster und AWS kann abgebaut werden
  • Hoster-Vertrag kündigen (€42k/Jahr gespart, aber €95k/Jahr AWS-Kosten → Netto: +€53k/Jahr, aber mit Auto-Scaling und BaFin-Compliance)

Die BaFin-Perspektive: Cloud-Compliance

Herausforderung: BaFin-regulierte Unternehmen müssen Cloud-Nutzung anzeigen und nachweisen, dass:

  1. Daten in EU bleiben
  2. Verschlüsselung (at-rest, in-transit)
  3. Disaster-Recovery getestet
  4. Ausstiegsstrategie existiert (falls Cloud-Provider ausfällt)

Unsere Lösung:

  • BaFin-Anzeige: 3 Monate vor Migration eingereicht, genehmigt
  • Datacenter: Ausschließlich AWS Region "eu-central-1" (Frankfurt)
  • Verschlüsselung: RDS-Encryption at-rest, S3-Encryption (AES-256), TLS 1.3 für Transit
  • DR-Tests: Quartalsweise Disaster-Recovery-Übungen (dokumentiert, automatisiert via AWS Backup)
  • Exit-Strategie: IaC (Terraform), sodass Workloads notfalls zu Azure/GCP portierbar

Vorstand-Präsentation (nach 12 Monaten):

Cloud-Migration: ROI-Update

Investition (Jahr 1):       €220k
  - AWS-Kosten:             €75k (erste 12 Monate)
  - Migration-Aufwand:      €120k (Entwickler-Zeit)
  - BaFin-Compliance:       €25k (Audit, Dokumentation)

Zusätzliche Kosten (ab Jahr 2): €53k/Jahr
  - Bisheriger Hoster entfällt:       €42k/Jahr
  - AWS laufend:            €95k/Jahr
  - Netto: +€53k/Jahr

Break-Even: Jahr 4 (über Skalierungs-Benefits)
ROI (über 5 Jahre): €180k (82% – primär durch Velocity-Gains)

Nicht-monetäre Benefits:
  ✅ Deployment-Geschwindigkeit: 3h → 8min
  ✅ BaFin-Compliance: Disaster-Recovery getestet (quartalsweise)
  ✅ Auto-Scaling: Kreditantrags-Peaks ohne Performance-Issues
  ✅ Recruiting: "AWS + Python + FinTech" ist starker Selling-Point

Vorstand-Reaktion: "Warum haben wir das nicht schon vor 3 Jahren gemacht?"

Transformations-Bereich 3: Finanzdienstleister-Integration

Das Problem: KMU-Finanzierungs-Ökosystem ist fragmentiert

Eine Plattform für digitale KMU-Finanzierung muss mit einem komplexen Ökosystem von Finanzdienstleistern integriert sein:

Partner-Landschaft:

  • 3 Partner-Banken (für Kreditauszahlung, jeweils eigene API)
  • 2 Bonitätsprüfungs-Provider (SCHUFA, Creditreform)
  • 4 Buchhaltungssystem-Anbindungen (DATEV, lexoffice, sevDesk, Billomat)
  • 2 Payment-Provider (SEPA-Lastschrift via FinAPI, Stripe für Kartenzahlung)
  • 1 KYC/AML-Compliance-Provider (IDnow für Video-Ident)

Technische Realität:

  • Kein einheitliches Protokoll: Jeder Partner hat eigene API (REST, SOAP, CSV-over-SFTP)
  • Legacy-Formate: SCHUFA liefert XML, DATEV hat proprietäres Format, Banken haben teilweise nur SFTP
  • Asynchronität: Bonitätsprüfung dauert 2-30 Sekunden (Webhook-basiert)
  • Fehlerbehandlung: Bank-API down → Kreditauszahlung muss queued werden (nicht scheitern)

Alte Architektur:

  • Point-to-Point-Integrationen (Django-Monolith spricht direkt mit jedem Partner)
  • Code-Duplikation (jede Integration ist ein Silo, 3 Partner-Banken = 3x ähnlicher Code)
  • Keine Abstraktion (wenn SCHUFA-API ändert → Core-System-Änderung nötig)
  • Fragile: Ein Partner-Outage → Kreditantrags-Prozess bricht ab (statt zu queuen)

Die Lösung: Integration-Layer mit Domain-Events

Architektur-Prinzip: Anti-Corruption-Layer (aus Domain-Driven Design)

Neue Architektur:

┌────────────────────────────────────────────────────────┐
│        Core-Plattform (Kredit-Business-Logik)          │
│   (Keine Kenntnis von Partner-spezifischen Formaten)  │
└─────────────────┬──────────────────────────────────────┘
                  │ Domain-Events (Internal)
                  │ (z.B. "CreditApplicationSubmitted",
                  │       "CreditScoreReceived",
                  │       "LoanDisbursed")
┌─────────────────▼──────────────────────────────────────┐
│              Integration-Layer (Adapter)               │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐            │
│  │ Bank-A   │  │ SCHUFA   │  │ DATEV    │            │
│  │ Adapter  │  │ Adapter  │  │ Adapter  │            │
│  │ (REST)   │  │ (XML/HTTP│  │ (SFTP)   │            │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘            │
└───────┼─────────────┼─────────────┼────────────────────┘
        │             │             │
┌───────▼─────┐ ┌────▼──────┐ ┌────▼────────────┐
│  Bank-A     │ │  SCHUFA   │ │  DATEV          │
│  (REST API) │ │  (XML)    │ │  (SFTP/CSV)     │
└─────────────┘ └───────────┘ └─────────────────┘

Key Components:

1. Domain-Events (Internal API):

  • Plattform spricht nur in Domain-Begriffen: CreditApplicationSubmitted, CreditScoreReceived, LoanDisbursed
  • Event-Schema ist stabil und dokumentiert
  • Keine Partner-spezifischen Details (z.B. SCHUFA-XML-Format ist abstrahiert)

2. Adapter pro Partner:

  • Jeder Adapter übersetzt zwischen Domain-Events und Partner-Protokoll
  • z.B. CreditApplicationSubmitted → SCHUFA-XML-Request
  • z.B. SCHUFA-XML-Response → CreditScoreReceived Domain-Event

3. Message-Bus (AWS SQS + SNS):

  • Asynchrone Kommunikation (Bonitätsprüfung kann 30 Sekunden dauern)
  • Retry-Logik bei Partner-Outages (exponential backoff)
  • Dead-Letter-Queue für fehlgeschlagene Requests (manuelles Review nötig)

4. Circuit-Breaker-Pattern:

  • Wenn Bank-A down ist → Adapter schließt Circuit
  • Kreditauszahlung wird zu Bank-B geroutet (Fallback)
  • Monitoring: PagerDuty-Alert bei Circuit-Open

Konkrete Integration: Neue Partner-Bank-Anbindung

Anforderung: Neue Partner-Bank-C anbinden für bessere Konditionen bei Krediten €100k-€500k.

Alte Welt (Monolith-Integration):

  • 3 Monate Entwicklung (Core-System-Änderungen nötig, da Bank-API direkt im Business-Logik-Layer)
  • Risiko: Core-System-Änderungen können Kreditauszahlung für existierende Banken brechen
  • Testing: Manuell, 2 Wochen, mit echtem Geld (Staging-Konto bei Bank)

Neue Welt (Adapter-Pattern):

Woche 1-2: Adapter-Entwicklung

  • Neuer Bank-C-Adapter implementieren (REST API mit OAuth2)
  • Übersetzt LoanApproved → Bank-C-API: POST /disbursements
  • Übersetzt Bank-C-Webhook (disbursement.completed) → LoanDisbursed Domain-Event

Woche 3: Testing

  • Unit-Tests für Adapter (Mocked Bank-API-Responses)
  • Integration-Tests gegen Bank-C-Sandbox
  • Compliance-Tests (SEPA-XML-Format, Anti-Money-Laundering-Checks)

Woche 4: Deployment

  • Adapter deployen (kein Core-System-Change!)
  • Feature-Flag: Aktiviere Bank-C für Kredite €100k-€500k (erst 10% Traffic)
  • Monitoring: Latenz, Error-Rate, Disbursement-Success-Rate

Ergebnis:

  • 4 Wochen statt 3 Monate (Faktor 3x schneller)
  • Zero Impact auf existierende Bank-Integrationen
  • Parallel-Testing: Neuer Bank-Adapter läuft parallel zu alten, Vergleich der Konditionen möglich

Das Board-Level-Argument: Strategic Flexibility

In meiner Rolle als Board-Advisor war es entscheidend, die Business-Value dieser Architektur-Änderung zu artikulieren:

Vorstand-Präsentation:

Finanzdienstleister-Integration: Strategic Flexibility

Alte Architektur:
  ❌ Neue Partner-Integration: 4-6 Monate
  ❌ Vendor-Lock-in: Wechsel ist 12-Monate-Projekt
  ❌ Risiko: Core-System-Änderungen bei jeder Integration

Neue Architektur (Integration-Layer):
  ✅ Neue Partner-Integration: 4 Wochen
  ✅ Multi-Broker-Support: Beste Konditionen für Kunden
  ✅ Resilience: Partner-Outage → Auto-Fallback

Business-Impact:
  📈 Time-to-Market für neue Services: -75%
  📈 Verhandlungsposition gegenüber Brokern: "Wir sind nicht abhängig"
  📈 Customer-Satisfaction: Bessere Execution-Quality durch Multi-Broker-Routing

Investition: €180k (6 Monate Entwicklung)
ROI: Break-Even nach 1. neuer Broker-Integration (1 Jahr)

CEO-Reaktion: "Das bedeutet, wir können schneller auf Markt-Chancen reagieren?" Meine Antwort: "Ja. Und wir können unseren Kunden bessere Konditionen bieten, weil wir nicht mehr an einen Broker gebunden sind."

Transformations-Bereich 4: CTO-Etablierung im Vorstand

Das Problem: CTO als "IT-Chef" wahrgenommen

Initial-Situation:

  • Neuer CTO ist formal Mitglied der Geschäftsführung
  • Aber: Wird als "der IT-Chef" wahrgenommen, nicht als strategischer Partner
  • Vorstand-Meetings: CTO präsentiert nur auf Nachfrage ("Wie steht's mit dem IT-Projekt?")
  • Budget-Diskussionen: "IT ist ein Cost-Center, kein Revenue-Driver"
  • Strategische Initiativen: CTO wird nicht früh eingebunden

Das Resultat:

  • CTO ist frustriert: "Ich bin nur Befehlsempfänger, kein Gestalter"
  • Tech-Strategie ist reaktiv: "Umsetzen, was Business verlangt"
  • Innovation passiert nicht: "Wir haben keine Zeit für neue Ideen"

Für mich als Board-Advisor war klar: Ein CTO, der nicht im Vorstand verankert ist, kann keine Transformation treiben.

Die Strategie: Technology als Strategic Enabler positionieren

1. Sprache ändern: Von "IT-Kosten" zu "Technology-Investments"

Alte Sprache (CTO in Vorstand-Meeting):

"Wir brauchen €500k für Cloud-Migration. Es wird 12 Monate dauern."

Neue Sprache (nach Coaching):

"Wir investieren €500k, um Time-to-Market für neue Services um 75% zu reduzieren. Das ermöglicht uns, 3-4 zusätzliche Revenue-Opportunities pro Jahr zu realisieren. ROI: Break-Even nach 18 Monaten."

Der Unterschied:

  • Fokus auf Business-Outcome, nicht auf Technologie
  • ROI-Kalkulation (Vorstand denkt in Zahlen)
  • Opportunity-Enablement (nicht nur Cost-Reduction)

2. Technology-Strategie als Teil der Business-Strategie

Vorher:

  • Business-Strategie wird im Vorstand definiert
  • IT bekommt Anforderungen: "Wir brauchen Feature X"
  • CTO reagiert: "OK, dauert 6 Monate"

Nachher:

  • Quartalsweise Strategy-Sessions mit gesamtem Vorstand
  • CTO präsentiert: "Welche Technology-Trends könnten unser Business transformieren?"
  • Beispiel: "Embedded Finance ist Trend. Wir könnten unsere Plattform als White-Label anbieten."
  • Vorstand diskutiert: "Ist das eine Chance für uns?"

Konkrete Initiative: Lending-as-a-Service-Plattform

Der CTO identifizierte eine strategische Chance:

  • Trend: E-Commerce-Plattformen, Buchhaltungssoftware, ERPs wollen ihren KMU-Kunden Finanzierung anbieten (Embedded Finance)
  • Unsere Stärke: Wir sind BaFin-reguliert, haben KMU-Finanzierungs-Lizenz, 6 Jahre Domain-Expertise
  • Idee: Unsere Credit-Decision-Engine + Partner-Banken-Anbindung als White-Label-API für Plattformen

Meine Rolle als Board-Advisor:

  • Sparring mit CTO: "Wie groß ist der Markt? Wer sind Wettbewerber? (Crosslend, Iwoca)"
  • Business-Case entwickeln: €1.5M Investment (API-Plattform), €6M Revenue-Potential (5 Jahre, Commission-based)
  • Vorstand-Pitch vorbereiten: Nicht technisches Pitch, sondern Business-Pitch ("B2B2B-Model")

Vorstand-Entscheidung: Grünes Licht. Budget genehmigt.

Das Resultat:

  • CTO wird als Strategic Thinker wahrgenommen (nicht nur "IT-Umsetzer")
  • Technology ist jetzt Teil der Wachstumsstrategie
  • Revenue-Forecast: €6M über 5 Jahre (komplett neue B2B-Einnahmequelle, margin-stärker als B2C)

3. DORA-Metriken als Vorstand-KPIs etablieren

Ein konkreter Wendepunkt: CTO-Performance wurde vorher an "Projekt-Deadline-Einhaltung" gemessen.

Mein Argument im Vorstand: "Projekt-Deadlines sind Vanity-Metric. Was wirklich zählt: Wie schnell können wir Value liefern?"

Neue KPIs (DORA-Metriken):

  • Deployment Frequency: Wie oft liefern wir Features? (Ziel: täglich)
  • Lead Time for Changes: Wie schnell von Idee bis Production? (Ziel: < 1 Woche)
  • Mean Time to Restore (MTTR): Wie schnell beheben wir Incidents? (Ziel: < 1h)
  • Change Fail Rate: Wie oft brechen Deployments etwas? (Ziel: < 5%)

Vorstand-Präsentation (quartalsweise):

Technology Performance (Q3 2024)

Deployment Frequency:     ━━━━━━━━━━ 3.2x/Woche (↑ 180% vs. Q2)
Lead Time for Changes:    ━━━━━━━━━━ 2.8 Wochen (↓ 65% vs. Q2)
MTTR:                     ━━━━━━━━━━ 1.1h (↓ 75% vs. Q2)
Change Fail Rate:         ━━━━━━━━━━ 6.8% (↓ 62% vs. Q2)

Business-Impact:
  ✅ 14 neue Features delivered (vs. 5 in Q2)
  ✅ 2 strategische Initiativen gestartet (Lending-as-a-Service, Document-OCR-Pipeline)
  ✅ Customer-Reported-Bugs: -45% (bessere Quality durch Testing)

Vorstand-Reaktion: "Diese Metriken zeigen echten Fortschritt. Besser als 'Projekt X ist zu 73% fertig'."

Das Learning: Wenn Sie als CTO im Vorstand ernst genommen werden wollen, sprechen Sie die Sprache des Business: ROI, Revenue-Enablement, Risk-Mitigation.

Transformations-Bereich 5: Modernisierung durch Strangler-Pattern

Das Problem: Der Monolith-Umbau

Nach 12 Monaten hatten wir:

  • ✅ Moderne Tech-Organisation
  • ✅ Cloud-Infrastruktur
  • ✅ Finanzdienstleister-Integrationen modernisiert
  • ✅ CTO im Vorstand etabliert

Aber: Der Kern der Plattform war immer noch der 6 Jahre alte Python-Monolith.

Der Monolith:

  • 420.000 Zeilen Python (Django 2.x, gewachsen seit Gründung)
  • 280 Tabellen in PostgreSQL
  • 6 Jahre gewachsene Business-Logik (Credit-Scoring, Antragsprozess, Payment-Processing)
  • Deployment: Monolithisch (alles oder nichts, 3h Downtime bei Deploy)
  • Skalierung: Vertikal (größere Server, nicht horizontal)

Die Herausforderung:

  • Big-Bang-Rewrite? Zu riskant (wir hatten aus meinem Fintech-Background gelernt: 72% scheitern)
  • Nichts tun? Nicht akzeptabel (Technical Debt wächst, neue Features dauern Monate)

Die Lösung: Strangler-Fig-Pattern (für Details siehe meine ausführliche Publikation).

Die Strategie: Schrittweise Extraktion

Prinzip:

  1. Identifiziere eine Business-Capability im Monolith (z.B. "Credit-Decision-Engine")
  2. Baue neuen Microservice für diese Capability (Cloud-Native, Python FastAPI oder AWS Lambda)
  3. API-Gateway (AWS ALB) routet Traffic schrittweise vom Monolith zum neuen Service
  4. Wenn 100% Traffic beim neuen Service: Lösche Code aus Monolith
  5. Wiederhole für nächste Capability

Architektur:

                   ┌─────────────────┐
                   │  AWS ALB        │
                   │ (Feature-Flags) │
                   └────┬───────┬────┘
                        │       │
         ┌──────────────┘       └──────────────┐
         │                                     │
    ┌────▼────────┐                  ┌────────▼────────┐
    │  Monolith   │                  │  Microservices  │
    │  (Django)   │                  │  (FastAPI/Lambda│
    │             │                  │   Python 3.11)  │
    │ - CreditApp│                  │ - CreditScore✅ │
    │ - Users ✅  │◄────Sync────────►│ - Reporting ✅  │
    │ - Payment🔄 │                  │ - Analytics 🔄  │
    └─────────────┘                  └─────────────────┘

Konkrete Extraktion: Credit-Decision-Service

Schritt 1: Analyse (3 Wochen)

  • Welcher Code gehört zu "Credit-Decision-Engine"?
  • Welche Datenbank-Tabellen werden genutzt?
  • Welche Dependencies zu anderen Modulen (Bonitätsprüfung, Risk-Scoring)?

Ergebnis:

  • 35.000 Zeilen Python-Code identifiziert (Django-Models + Business-Logic)
  • 22 Tabellen involviert (Antragsdaten, Scoring-Modelle, Entscheidungs-Logs)
  • 4 kritische Dependencies (SCHUFA-Adapter, Risk-Scoring-Modell, Fraud-Detection, Limit-Management)

Schritt 2: API-Design (1 Woche)

  • Definiere saubere API für Credit-Decision-Service
  • REST-Endpoints: POST /credit-decisions, GET /credit-decisions/{id}
  • Event-Schema: CreditApplicationEvaluated, CreditDecisionMade (approved/rejected)

Schritt 3: Implementierung (7 Wochen)

  • Neuer Microservice in Python FastAPI (moderne Async-API)
  • RDS PostgreSQL (eigenes Schema, entkoppelt von Monolith)
  • Data-Sync: Debezium CDC (Change-Data-Capture) vom Monolith → Credit-Decision-Service
  • Testing: pytest (Unit-Tests), Contract-Tests (gegen SCHUFA-Mock), Load-Tests (Locust)

Schritt 4: Parallel-Betrieb (5 Wochen)

  • Deploy Credit-Decision-Service zu ECS Fargate (Production)
  • AWS ALB: Route 5% Traffic zum neuen Service (Feature-Flag via LaunchDarkly)
  • Monitoring: Vergleiche Entscheidungen (Monolith vs. Microservice, müssen identisch sein!)
  • Bei Divergenzen: Debug (meist unterschiedliche Rundung oder Daten-Inkonsistenzen)

Schritt 5: Cutover (3 Wochen)

  • Feature-Flag: 5% → 15% → 30% → 50% → 100%
  • Bei jedem Schritt: 3-4 Tage Monitoring, dann nächster Schritt
  • Nach 100%: Monolith-Code für Credit-Decision löschen (35.000 Zeilen weniger!)

Schritt 6: Data-Migration (4 Wochen)

  • Historische Credit-Decisions vom Monolith → Credit-Decision-Service migrieren (für Audit-Zwecke)
  • Debezium CDC abschalten
  • Monolith-Tabellen (für Credit-Decisions) können archived werden (BaFin-Compliance: 10 Jahre Aufbewahrung)

Total: 19 Wochen für eine vollständige Capability-Extraktion

Die Roadmap: 18 Monate, 5 Services

Priorisierung:

  1. Credit-Decision-Engine (hoher Business-Value, mittlere Komplexität) ✅
  2. Reporting & Analytics (hohe Performance-Gains, niedrige Komplexität) ✅
  3. User-Management & KYC (niedrige Komplexität, Enabler für SSO) 📋
  4. Document-Processing (OCR für Kreditanträge, ML-basiert) 📋

Status nach 18 Monaten:

  • 2 Services vollständig extrahiert (Credit-Decision, Reporting)
  • 1 Service in Production (Payment-Processing, 40% Traffic)
  • Monolith: 420k Zeilen → 290k Zeilen (-31%)
  • Neue Services: 95k Zeilen (Cloud-Native, Python FastAPI/Lambda)

Performance-Verbesserungen:

  • Credit-Decision: 12s → 2.1s (-82% Latenz durch Async-Processing)
  • Reporting: 8h Batch → 1.5h (könnte weiter optimiert werden zu Real-Time Streaming)
  • Deployment-Frequency: Monolith 1x/Monat, Microservices 4x/Woche

Das Board-Level-Learning: Transformation ist Marathon, kein Sprint

In meiner letzten Vorstand-Präsentation vor Ende meines Advisory-Mandats:

"Was haben wir in 18 Monaten erreicht?"

Technisch:

  • ✅ Tech-Organisation modernisiert (Team Topologies)
  • ✅ Cloud-Infrastruktur aufgebaut (On-Premise → Azure)
  • ✅ Finanzdienstleister-Integrationen entkoppelt (Adapter-Pattern)
  • ✅ Strangler-Migration gestartet (2 Services extrahiert, 4 in Pipeline)
  • ✅ DORA-Metriken etabliert (Deployment Frequency +1800%, MTTR -73%)

Organisatorisch:

  • ✅ CTO im Vorstand etabliert (von "IT-Chef" zu Strategic Partner)
  • ✅ Technology-Strategie als Teil der Business-Strategie
  • ✅ Neue Revenue-Streams identifiziert (Embedded Finance: €8M über 5 Jahre)

Business-Impact:

  • ✅ Time-to-Market: -75% (12 Wochen → 3 Wochen)
  • ✅ IT-Kosten: -15% (trotz Cloud-Migration, durch Effizienzgewinne)
  • ✅ BaFin-Compliance: Modernisiert und zukunftssicher
  • ✅ Recruiting: 8 neue Entwickler eingestellt (Cloud-Native-Skills attraktiv)

Was noch zu tun ist:

  • 📋 Weitere 4 Microservices extrahieren (24-36 Monate)
  • 📋 Embedded-Finance-Plattform ausrollen (12 Monate bis First Customer)
  • 📋 DORA-Metriken weiter verbessern (Deployment Frequency → täglich)

Vorstand-CEO-Zitat:

"Vor 18 Monaten hatten wir einen neuen CTO und ein Legacy-Problem. Heute haben wir einen strategischen Technology-Partner und eine Plattform, die wachsen kann. Das hätten wir ohne Board-Advisory nicht geschafft."

5 kritische Lektionen aus 18 Monaten Board-Advisory

Lektion 1: Board-Advisory ist anders als CTO-Rolle

Als CTO habe ich operative Entscheidungen getroffen. Als Board-Advisor war meine Rolle:

  • Sparring-Partner: Fragen stellen, Perspektiven einbringen, Risiken aufzeigen
  • Coach: CTO befähigen, selbst Entscheidungen zu treffen (nicht Entscheidungen abnehmen)
  • Board-Navigator: CTO helfen, Vorstand zu überzeugen (Sprache, Metriken, ROI)
  • Honest Broker: Zwischen Vorstand und Tech-Team vermitteln (beide Seiten verstehen)

Key Insight: Als Board-Advisor bin ich am effektivsten, wenn ich unsichtbar bin – wenn der CTO erfolgreich ist, nicht wenn ich der Held bin.

Lektion 2: Technologie-Transformation ist 30% Technik, 70% Mensch

Die größten Challenges waren nicht technisch:

  • Change-Resistance: "Das alte System funktioniert doch" (Vorstand)
  • Angst vor Bedeutungsverlust: "Ich bin der einzige, der das alte System versteht" (Tech-Lead)
  • Kulturwandel: Von "Wir warten auf Spezifikation" zu "Wir nehmen Ownership"

Success-Faktoren:

  • Quick Wins: Frühe Erfolge zeigen (Portfolio-Service in 6 Wochen)
  • Involvement: Mitarbeiter sind Teil der Lösung (nicht Betroffene)
  • Transparenz: OKRs, DORA-Metriken, Roadmaps öffentlich machen
  • Celebration: Erfolge feiern (nicht nur Probleme besprechen)

Lektion 3: ROI-Kommunikation ist entscheidend

Vorstand denkt in Zahlen. Jede Technologie-Investition braucht Business-Case:

Schlechtes Pitch:

"Wir müssen zu Microservices migrieren, weil Monolithen nicht skalieren."

Gutes Pitch:

"Wir investieren €450k über 12 Monate, um Time-to-Market um 75% zu reduzieren. Das ermöglicht uns 8-10 zusätzliche Features pro Jahr. Bei durchschnittlich €120k Revenue-Impact pro Feature: €960k zusätzlicher Revenue. ROI: 113% im ersten Jahr."

Die Formel:

  1. Investment: Was kostet es? (€, Zeit, Risiko)
  2. Outcome: Was bringt es? (Revenue, Cost-Savings, Risk-Mitigation)
  3. Timeline: Wann Break-Even? Wann ROI?

Lektion 4: Regulatorik ist Feature, nicht Bug

Im regulierten Finanzsektor ist Compliance oft als "Bremse" wahrgenommen.

Meine Perspektive: Regulatorik ist Competitive Advantage.

Beispiel: BaFin-Regulierung

  • Fintechs scheuen Regulierungs-Aufwand
  • Wir sind bereits BaFin-reguliert
  • → Wir können Embedded-Finance-Services anbieten (Fintechs können nicht)

Das Argument im Vorstand: "Unsere Compliance-Infrastruktur ist nicht nur Kosten – sie ist Markteintrittsbarriere für Wettbewerber und Enabler für neue Geschäftsmodelle."

Lektion 5: Erfolgreiche Transformation braucht "Zeit & Geduld"

18 Monate klingen lang. Aber für Enterprise-Transformation: Das ist schnell.

Typische Fehler:

  • Zu schnell wollen: "Wir migrieren in 6 Monaten alles" → Scheitert
  • Zu vorsichtig sein: "Wir warten, bis alles perfekt geplant ist" → Analyse-Paralyse

Der richtige Ansatz: Iterativ & Inkrementell

  • Startet mit Pilot (Portfolio-Service, 19 Wochen)
  • Lernt daraus
  • Wiederholt
  • Nach 18 Monaten: Momentum ist da, Teams sind kompetent, Vorstand ist überzeugt

Quote aus meinem Abschlussbericht:

"Transformation ist kein Projekt mit Enddatum. Es ist eine kulturelle Bewegung. Nach 18 Monaten haben wir die Flughöhe erreicht. Jetzt kann das Team selbstständig weiterfliegen."

Fazit: Board-Advisory als Katalysator für Technology-Transformation

Als ich mein Board-Advisory-Mandat nach 18 Monaten beendete, war die Plattform-Transformation nicht "fertig" – aber sie war unaufhaltsam geworden.

Was wir erreicht haben:

  • Ein CTO, der im Vorstand als Strategic Partner etabliert ist
  • Eine Tech-Organisation, die in Wochen liefert (nicht Monaten)
  • Eine Cloud-Infrastruktur, die skaliert und BaFin-compliant ist
  • Eine Integrations-Architektur, die Flexibilität ermöglicht
  • Eine Modernisierungs-Roadmap, die über 3-5 Jahre läuft (und akzeptiert ist)

Was ich gelernt habe:

  • Board-Advisory ist nicht Consulting: Es ist Sparring, Coaching, Enabling
  • Technology ist Mittel, nicht Zweck: Der Fokus muss auf Business-Outcome liegen
  • Transformation ist Marathon: Quick Wins ja, aber realistische Timelines
  • Menschen > Technologie: Organisatorisches Change-Management ist kritisch
  • ROI-Kommunikation: Vorstand braucht Zahlen, keine Technologie-Predigten

Für CTOs, die vor ähnlichen Herausforderungen stehen:

Wenn Sie eine Legacy-Plattform haben und transformieren wollen:

  1. Holen Sie sich Sparring: Jemand, der diese Reise schon gemacht hat
  2. Überzeugen Sie den Vorstand früh: Mit Business-Case, nicht Tech-Vision
  3. Starten Sie klein: Pilot, Learnings, dann skalieren
  4. Bauen Sie Organisation parallel: Technologie ohne Organisation scheitert
  5. Messen Sie Fortschritt: DORA-Metriken, ROI, Customer-Satisfaction

Für Vorstände, die Technology-Transformation erwägen:

Ein Board-Advisor kann der Katalysator sein – wenn:

  • Sie bereit sind, zu investieren (Zeit, Geld, Geduld)
  • Sie Technology als Strategic Enabler sehen (nicht nur Cost-Center)
  • Sie Ihrem CTO Raum geben, zu gestalten (nicht nur umzusetzen)

Legacy-Plattformen sind nicht Ihr Problem. Sie sind Ihre Chance – wenn Sie sie richtig transformieren.

Weitere Ressourcen

Plattform-Transformation pragmatisch angehen?

Bereit für Ihre Transformation? Ich habe 18 Monate als Board-Advisor im Finanzsektor verbracht und CTOs bei ähnlichen Herausforderungen begleitet. Lassen Sie uns über Ihre spezifische Situation sprechen.

← Zurück zu allen Publikationen