Ein Münchner SaaS-Anbieter für Kundencommunity-Plattformen musste seine Architektur unter pandemiebedingtem Nachfragedruck modernisieren, ohne die modulare Produktdifferenzierung zu gefährden.

Die Herausforderung

Die Plattform des Unternehmens war auf einer bestehenden Codebasis aufgebaut, die dem frühen Kundenstamm gute Dienste geleistet hatte. Genau die Modularität, die das Produkt kommerziell auszeichnete, machte es architektonisch komplex: Jede Kundeninstallation war eine eigene Konfiguration, sodass sich keine einzelne Änderung gegen eine generische Baseline testen ließ. Mit der Pandemie im Jahr 2020 verdichteten sich Jahre der digitalen Umstellung auf wenige Monate. Die Plattform sah sich einem Nachfrageschub gegenüber, für den sie nie ausgelegt worden war: mehr gleichzeitige Nutzer, mehr parallele Datenströme und mehr aktive Integrationen zugleich. Die bestehende Architektur zeigte die Belastung deutlich, die Leistung sank unter der Last, es traten Engpässe bei der Datenverarbeitung auf, und das Risiko von Ausfallzeiten stieg. Verschärft wurde das Problem durch die Natur des Geschäfts: Ein herkömmlicher Neubau, der das bestehende System komplett ersetzt hätte, hätte die modulare Konfigurationsebene zerstört, auf die sich die Kundenverträge stützten. Jede Optimierung musste die Logik der bestehenden Architektur respektieren und gleichzeitig ihre Leistungsmerkmale wesentlich verbessern.

Der Ansatz

Gradions Vorgehen setzte auf gezielte Präzision statt auf Ersatz. Das Team begann mit einer sorgfältigen Prüfung der bestehenden Codebasis, kartierte die Leistungsengpässe, verstand die modulare Abhängigkeitsstruktur und identifizierte, an welchen Stellen ein Eingriff den größten Nutzen bringen würde, ohne Folgerisiken auszulösen. Zuerst wurde die Frontend-Toolchain modernisiert: Bower wurde durch Webpack und npm ersetzt, nicht aus Trendgründen, sondern weil das bestehende Build-Werkzeug eine konkrete Einschränkung für Bereitstellungsgeschwindigkeit und Zuverlässigkeit einer Plattform war, die sich fortlaufend weiterentwickeln musste. Der bestehende Code wurde unter der ausdrücklichen Vorgabe überarbeitet, die Modularität zu erhalten. Ziel war keine architektonische Neufassung, sondern eine gezielte Optimierung: Leistungsengpässe entfernen, die Build-Pipeline straffen und den Spielraum für Skalierbarkeit vergrößern, ohne die Konfigurationslogik zu verändern, auf die sich die Kundeninstallationen stützten. Die DevOps-Härtung adressierte die Stabilitätsrisiken, die unter Last entstanden waren. Jenkins erhielt eine Basisauthentifizierung, und ein Echtzeit-Monitoring wurde eingerichtet, damit die Plattform Verschlechterungen erkennen konnte, bevor sie für Endnutzer oder Kunden sichtbar wurden. Die Teamstruktur spiegelte die Effizienzziele wider: Der anfängliche Auftrag lief mit fünf Spezialisten, einem Projektmanager, Senior-Entwicklern und einem DevOps-Engineer. Als sich das Werkzeug etablierte und die Plattform stabilisierte, konzentrierte sich die operative Verantwortung auf einen einzigen Gradion-Entwickler in mehreren Rollen, der die Plattform seither fortlaufend betreut.