🔀
Doppelter Entwicklungsaufwand — zwei Teams
Seit 2022 muss jedes neue Feature für Desktop (CCA9) und Web (CCA Online) separat entwickelt werden. Zwei Codebases, zwei Deployments, doppelte Bugs — und zwei Entwicklungsteams, die jemand bezahlen muss.
❓
„Wo kommt das Feature hin?"
Jede Entwicklungsdiskussion beginnt mit der Grundsatzfrage: Desktop oder Web? Diese Architekturfrage verlangsamt Entscheidungen und fragmentiert das Produkt.
🐌
CCA Online zieht nicht
Trotz 14 Jahren Entwicklung nimmt der Markt CCA Online nur schleppend an. Manch renommierter Kunde möchte es „nicht mal geschenkt" — ein klares Signal, das gehört werden muss.
🎭
Zwei Produkte, zwei Welten
CCA9 und CCA Online sollen das Gleiche tun — fühlen sich aber völlig verschieden an. Unterschiedliche Bedienlogik, unterschiedliche Workflows, unterschiedliches Look & Feel. Wer zwischen beiden wechselt, muss umlernen. Schulungen müssen doppelt gehalten werden.
🧭
Daten vor Prozessen — keine Führung für den Anwender
Keine Übersicht, was gerade wichtig ist. Keine Aufgabenliste, keine Priorisierung, keine prozessgesteuerte Führung. Der Anwender muss selbst wissen, was heute zu tun ist. Daten werden angezeigt — aber nicht kontextualisiert.
📊
Produktregistrierung per Excel-Sheet (Jahrgang 2000)
Die zentrale Verwaltung der Produktlizenzen läuft über ein Excel-Sheet aus dem Jahr 2000. Kein API, kein Self-Service. Die „Registrierung in der Cloud" wurde nie realisiert. BrokerCloud integriert stattdessen Stripe für automatisierte Abrechnung.
💸
Betriebskosten: ~1–2 Mio. € p.a. am Markt
Der Betrieb der Desktop-Architektur ist teuer: entweder brauchen Endgeräte hohe Rechenleistung — oder Kunden setzen auf kostspielige virtuelle Maschinen. Dieser Overhead multipliziert sich über den gesamten Maklermarkt.
💿
MSI-Upgrades: teuer, langsam, fragmentiert
Jedes Update muss als MSI-Paket ausgerollt und manuell eingespielt werden — kostspielig, wenn ein Dienstleister das übernimmt. Installierte Versionen sind häufig 6 bis 24 Monate hinter der aktuellen Version. All diese Altstände wollen trotzdem supported werden.
🐢
Deployment dauert bis zu 6 Wochen
Sprint-Durchlaufzeiten von 6 Wochen, Deployment CCA9 nochmals 2 Wochen, CCA Online 4 Wochen. Neue Features brauchen Monate, bis sie beim Endkunden ankommen — Wettbewerber ziehen davon.
☁️
host-it: Hosting ohne die Vorteile des Hostings
Seit 2025 gibt es eine „Cloud-Lösung" — aber nur der SQL-Server wird gehostet. Der Fat-Client läuft weiterhin lokal. Performance hängt vollständig vom Endgerät und der Internetverbindung ab. Der Anwender ist Admin auf seinem Rechner — sicherer Support de facto unmöglich. VPN als kritische Abhängigkeit.
🔌
OMDS-Manager Dualität
Gleicher Dienst, unterschiedliches Verhalten — je nach Laufzeitumgebung. Localhost vs. Webserver, abweichende Benutzernamen-Logik. Schwer zu warten, schwer zu erklären.
📋
Zwei völlig verschiedene Logging-Welten
CCA9 schreibt Freitext-Logbucheinträge direkt aus der Applikation. CCA Online schreibt strukturierte XMLs via Audit-Trigger in die Datenbank. Ein Logbucheintrag sieht im einen System komplett anders aus als im anderen — Support, Auswertung und Compliance werden dadurch massiv erschwert.
🧩
Gewachsene Komplexität: 5 Anwendungen
CCA9, CCA5/OMDS Browser, DataCenter, DocumentMaintenanceTool, UserReport.DLL — unterschiedliche Technologiegenerationen, inkonsistente Verhaltensweisen, kein gemeinsamer Nenner.
⚙️
VB6 lebt noch
CCA5/OMDS Browser und die UserReport.DLL sind 2025 noch immer in VB6. Eine Technologie aus den 90ern, für die kaum noch Entwickler am Markt sind.
🧬
FecherLibrary: .NET mit VB6-Seele
Bei der C#-Migration (2020) wurde die VB6-Logik nicht neu gedacht — sie wurde übersetzt. Die FecherLibrary lebt im C#-Projekt, denkt aber in VB6-Strukturen. Technisch moderner Code, konzeptionell Legacy.
📦
Dependency-Zoo: 14 UI-Komponenten-Bibliotheken
ComponentOne v4.5.2, DevExpress v11.2 (2011!), Crystal Reports v13, COM-Interop für WIA-Scanner, SHDocVw (Internet Explorer Embedded) — und Microsoft.VisualBasic als direkte Referenz. Jede Abhängigkeit ist ein Upgrade-Blocker.
🪟
Prefer32Bit · .NET 4.7.2 · WinForms/WPF gemischt
Prefer32Bit=true — die zentrale App läuft 2025 im 32-Bit-Modus. Legacy .NET Framework statt .NET 8+. WPF und WinForms gleichzeitig im selben Projekt. WarningLevel=1 — Compiler-Warnungen werden großteils ignoriert.
🗄️
Datenbankdesign aus 1999 (SQL 7.0)
Das Schema wurde für SQL Server 7.0 entworfen — inzwischen auf SQL Server 2014 (EOL seit 2019) gehoben. Kein modernes Historisierungskonzept, kaum noch erweiterbar.
🕸️
230 Trigger · 1.900 Stored Procedures · 2.000+ Views
Über 25 Jahre gewachsen: extrem verschachtelte SPs, 230 Trigger, 2.000+ Views. Berechtigungssystem auf Basis suser_sname() — kein RBAC. Massenhaft Redundanzen, Performance super-zäh. Jede Änderung ist ein Blindflug.
🩹
Standards nachträglich aufgepfropft
OMDS entstand um 2010 — über 10 Jahre nach dem Datenbankdesign. Individuelle Tabellen wurden nachträglich mit Standardfeldern „aufgefettet" statt neu strukturiert. Jede OMDS-Erweiterung kostet überproportional viel Aufwand.
🔢
Extrem normalisiert — alles ist eine ID
Orte, KFZ-Marken, Berufe, akademische Titel — alles steckt in eigenen Lookup-Tabellen, mehrsprachfähig, vollständig ID-referenziert. Jeder Datenimport wird zur Qual: dutzende Auflösungsschritte, Mapping-Aufwand bei jeder Schnittstelle.