SaaS Kunden-Community-Plattform: 75–80 % Kostenreduktion. Einrichtungszeit von zwei Wochen auf sechs Stunden verkürzt. Modulare Plattform für Skalierbarkeit neu aufgebaut, ohne ihre Kernstärken zu ve…

Die Herausforderung

Die Plattform des Unternehmens basierte auf einer älteren Codebasis, die dem anfänglichen Kundenstamm gut diente. Die Modularität, die das Produkt kommerziell einzigartig machte, führte jedoch auch zu architektonischer Komplexität: Jede Kundenimplementierung war eine einzigartige Konfiguration, was bedeutete, dass keine einzelne Änderung gegen eine generische Baseline getestet werden konnte. Dann kam das Jahr 2020. Die Pandemie komprimierte Jahre der digitalen Adoption in Monate. Die Plattform sah sich einem Nachfrageschub gegenüber, für den sie nie konzipiert worden war: mehr gleichzeitige Nutzer, mehr parallele Datenströme und mehr aktive Integrationen gleichzeitig. Die Altsystemarchitektur begann, die Belastung zu zeigen: Die Leistung verschlechterte sich unter Last, Datenengpässe traten auf und das Risiko von Ausfallzeiten stieg. Das Problem wurde durch die Art des Geschäfts des Kunden noch verschärft. Ein konventioneller Neuaufbau, der das Altsystem vollständig ersetzt hätte, hätte die modulare Konfigurationsschicht zerstört, auf der die Kundenverträge basierten. Jede Optimierung musste die Logik der bestehenden Architektur respektieren und gleichzeitig ihre Leistungsmerkmale erheblich verbessern. Die Frage, die Gradion beantworten sollte: Wie modernisiert man ein komplexes, kundenspezifisches Altsystem unter operativem Druck, ohne die Produktdifferenzierung zu zerstören, die es wertvoll macht?

Der Ansatz

Gradions Ansatz setzte auf gezielte Präzision statt eines kompletten Austauschs. Das Team begann mit einer sorgfältigen Prüfung der bestehenden Codebasis. Dabei wurden Leistungsengpässe identifiziert, die modulare Abhängigkeitsstruktur analysiert und Bereiche bestimmt, in denen Eingriffe den größten Nutzen bei minimalem Risiko erzielen würden. Zuerst wurde die Front-End-Toolchain modernisiert. Bower wurde durch Webpack und npm ersetzt. Dies geschah nicht aus Trendgründen, sondern weil die bestehenden Build-Tools die Geschwindigkeit und Zuverlässigkeit der Bereitstellung einer Plattform, die sich kontinuierlich weiterentwickeln musste, konkret einschränkten. Der Legacy-Code wurde unter der expliziten Bedingung refaktorisiert, die Modularität zu erhalten. Ziel war keine komplette Neuentwicklung der Architektur, sondern eine gezielte Optimierung: Leistungsengpässe beseitigen, die Build-Pipeline straffen und die Skalierbarkeit verbessern. Dies erfolgte ohne Änderung der Konfigurationslogik, von der Kundenimplementierungen abhingen. Die DevOps-Härtung begegnete den Stabilitätsrisiken, die unter Last aufgetreten waren. Jenkins wurde um eine Basisauthentifizierung erweitert. Echtzeit-Monitoring wurde konfiguriert, um Leistungsabfälle zu erkennen, bevor sie für Endnutzer oder Kunden sichtbar wurden. Ziel war ein selbstüberwachendes System, das den operativen Aufwand für das Entwicklungsteam reduziert und dem Unternehmen Freiraum für die Produktentwicklung verschafft. Die Teamstruktur spiegelte die Effizienzziele wider. Der initiale Einsatz umfasste fünf Spezialisten: einen Projektmanager, Senior-Entwickler und einen DevOps-Ingenieur. Mit der Reifung der Tools und der Stabilisierung der Plattform konsolidierte sich die Betriebsverantwortung auf einen einzigen Gradion-Ingenieur mit mehreren Rollen, der die Plattform nun kontinuierlich betreut.