Legacy Modernisierung im laufenden Betrieb – wie aus dem OfficeNet das Social OfficeNet wurde

Die mit ON2 aufgebauten Lösungen reichen dabei von klassischen Intranets, über Extranet-Anwendungen bis hin zu Wissensmanagement-Systemen. Doch die beständige funktionale Erweiterung und die wachsende Zahl der Anwender bringen die gewachsene Architektur des Systems an seine „natürlichen“ Grenzen.

Wenn Architektur an ihre Grenzen stößt – typische Probleme mit Legacy Systemen auch bei ON2

Technologien im Bereich der IT haben sich in den letzten Jahren schnell weiterentwickelt. Waren die damals getroffenen Architekturentscheidungen für Open Source Komponenten, wie das XML-Publishing Framework Cocoon und das integrierte Web-CMS Daisy geradezu zukunftsweisend, so sind sie aus heutiger Sicht technisch vollkommen überholt. Neu zum Entwicklungsteam dazustoßende Entwickler*innen sind zudem mit den Technologien nicht mehr vertraut.

Entscheidend war jedoch, dass sich in der Alltagspraxis zunehmend Schwächen zeigten:

• So bot das System bei hoher Auslastung eine suboptimale Performance.
• Die Benutzeroberflächen waren hinsichtlich Gestaltung und Bedienbarkeit nicht mehr „State-of-the-Art“.
• Die nur teilweise umgesetzte Responsiveness sowie Unvollständigkeit hinsichtlich der Barrierefreiheit erschwerten zusehends das mobile Arbeiten und den vollständigen Zugang für alle Anwendergruppen.

Dementsprechend stieg der Aufwand für die Erweiterung des Funktionsumfangs sowie die Behebung von Fehlern stetig. Auch unter IT-Security-Gesichtspunkten bergen ältere Technologien Risiken, die es zu minimieren galt.

Und nun? Ziele und Anforderungen beim Umbau zu Social OfficeNet (SON) im laufenden Betrieb

Die grundsätzliche Struktur und die Features von OfficeNet hatten sich in der Behördenarbeit super bewährt. Die Lösung erfreute sich trotz aller technischer Schwächen sehr hoher Akzeptanz bei den Kunden. So kamen das BVA als Auftraggeber und die Anwender-Behörden überein, dass die neue Lösung funktional im Wesentlichen eine Re-Implementation der Bestandslösung sein musste.

Nach Ausschreibung und Vergabe des zugehörigen Rahmenvertrages erfolgte als erster Schritt eine genaue Anforderungsanalyse. Besonders in funktionalen Detailfragen konnten die jahrelangen Kundenerfahrungen mit dem System als wertvoller Input in die Produktkonsolidierung mit einfließen. Neben der technischen Neuaufstellung boten sich insbesondere beim Zusammenfassen von ähnlichen Features, dem Neudenken gewachsener Funktionalitäten sowie dem visuellen Re-Design der Oberflächen hervorragende Ansatzpunkte. Auch Barrierefreiheit und die Nutzbarkeit von ON2 auf mobilen Endgeräten spielte bei der Neuentwicklung eine wichtige Rolle.

Die neue Lösung sollte darüber hinaus visuell und funktional in Aspekten wie der Kommentarfunktion, dem Empfehlen von Inhalten oder der Anzeige von Ansprechpartnern den von sozialen Netzwerken gewohnten Nutzungsstandards entsprechen. So werden Anwender*innen zu mehr Vernetzung und Wissensaustausch animiert. Dementsprechend wurde auch „Social OfficeNet“ als neuer Name gewählt. Unter der „Motorhaube“ wurde der Fokus auf beste Performance, die Skalierbarkeit für große Installationen, Modularität, Erweiterbarkeit sowie Sicherheit gelegt.

Der schrittweise Umbau des Systems im laufenden Betrieb stellt die größte technische Herausforderung dar

Die auf technischer Ebene mit Abstand herausforderndste Anforderung jedoch war, und ist immer noch, die schrittweise Ablösung des Altsystems im laufenden Betrieb. Dabei soll(t)en die Features und Module des neuen SON den Anwendern von ON2 schrittweise zur Verfügung gestellt und in die jeweiligen Echtsysteme eingebaut werden - inklusive der voll automatischen Migration der jeweiligen Bestandsdaten. Erschwert wird die Umsetzung dieser Anforderung zusätzlich durch sehr individuell gestaltete Kundensysteme, die in ihrem Umfang stark variieren und die auf verschiedenen Betriebssystemen in der Regel beim Kunden vor Ort (Rechenzentrum) betrieben werden. Hier eine sichere und effiziente Lösung zu finden, war sicher die größte Herausforderung an den technischen Dienstleister SEITENBAU.

Grundsätzliche Überlegungen bei der Festlegung der Reihenfolge der Features – Priorisierung ganz wichtig!

Ein zentraler Faktor für den Erfolg des Projektes war dabei die Entscheidung, in welcher Reihenfolge die alten Features in den Systemen durch die neuen SON-Funktionen abgelöst werden sollten. Die Ziele der dazu durchgeführten konzeptionellen Überlegungen waren:

• Maximierung des Nutzens des jeweiligen „Zwischenprodukts“ für den Kunden
• Minimierung der Aufwände, z.B. durch die Vermeidung von mehr Zwischenlösungen als unbedingt nötig
• Möglichst frühe Ablösung möglichst großer Teile der Bestandsanwendung

Schnell wurde klar, dass der Fokus auf das grundlegende Design und Layout des Portals, auf häufig besuchte Seiten wie der Startseite oder den sogenannten Gruppenräumen sowie häufig benutzten Funktionen, wie der Navigation, gelegt werden musste. Weiter hinten angestellt wurden seltener benutzte Funktionen, wie beispielweise der Redaktionsmodus, der nur von Personen mit entsprechenden Rechten aufrufbar ist.

Mit einem temporären Hybridsystem zu einer flexiblen Microservice-Architektur

Da es aufgrund der Anforderungen der anwendenden Behörden schlicht unmöglich war, die neue Software auf der grünen Wiese zu erstellen und die alte Lösung in einem Schritt abzulösen, musste eine technisch eleganter „Work-Around“ für die schrittweise Ablösung des alten Systems gefunden werden.

Dazu wurden zunächst mit dem Spring-Framework, JPA/Hibernate, RabbitMQ, Node.js, React und Sass fast ausnahmslos moderne Open Source Komponenten als zentrale Technologien gewählt, welche die Anforderungen an Sicherheit, Performanz, Skalierbarkeit, Zukunftssicherheit und Konnektivität erfüllen und deren Einsatz gleichzeitig nicht das Projekt-Budget zu sehr belasten.

Als grundlegendes Architektur-Pattern wurde eine Microservice-Architektur gewählt. Die Bestandssoftware wird dabei wie ein Modul behandelt, das über Schnittstellen angesprochen werden kann, etwa um Daten zu exportieren und automatisiert in das neue System einzupflegen oder um Funktionalitäten weiterzuverwenden, bis sie schließlich durch eine Entsprechung im neuen System ersetzt werden. Da der alte Code irgendwann komplett ersetzt werden soll, muss dabei immer darauf geachtet werden, dass die beiden Systeme nicht zu stark miteinander verwoben werden, man spricht hier von „loser Kopplung“. Diesen Verbund nennen wir Hybrid-System.

Ein zentraler Login-Mechanismus wird durch Keycloak als Open Source Lösung für sogenanntes „Identity and Access Management“ bereitgestellt, sodass alle Anwender*innen nach dem Login automatisch in beiden Systemen angemeldet sind. Bei den Datenbanken können weiterhin die von den jeweiligen Kunden präferierten Komponenten genutzt und auf die aktuellsten Versionen umgestellt werden. Um eine größtmögliche Vereinheitlichung der Services zu erreichen, aus denen SON und ON2 wiederum bestehen, setzen wir auf Virtualisierung in Form von Docker-Containern.

Cross-funktionale Scrum-Teams und orthogonal verzahnte Communitys im Entwicklungsprozess

Um ein solch komplexes Software-Projekt von Anfang an adäquat aufzugleisen, wurde der Fundus an Entwicklern bei SEITENBAU sukzessive aufgestockt. Aus anfänglich einem Entwicklungs-Team wurden mit der Zeit drei cross-funktionale Scrum-Teams aufgebaut. Dadurch können Features von Design und Frontend über Backend bis hin zu betrieblichen Aspekten, vollständig („end to end“) von einem einzelnen Team umgesetzt werden. Auch der nötige Austausch zwischen Support und Entwicklung findet in jedem Team statt.

Zusätzlich dazu wurden je nach Entwicklungsstufe des Systems und speziellem Aufgabenstand temporäre Feature-Teams gebildet. So konnte beispielweise die Lauffähigkeit des Produkts in einem OpenShift-Cluster bei einem Kunden gezielt durch ein eigens dafür formiertes Team vorangetrieben werden.

Im fortlaufenden Entwicklungsprozess kristallisierte sich zudem die Bildung orthogonaler, miteinander verzahnter Communitys bestehend aus PO/PLs, Design, Frontend, Backend, Build/Release-Management, DevOps und Support als wertvolle Maßnahme heraus, da bei der Operation am selben Produkt die Absprache und Kommunikation von Standards essenziell sind. Denn dass die beständig weiterentwickelte Software-Architektur von allen Entwicklern verstanden und getragen wird, kann nur durch regelmäßigen Austausch zwischen den Teams sichergestellt werden.

Agile Zusammenarbeit mit dem Kunden – fortlaufende Roadmap-Planung und ständige Abstimmung

Ein weiterer wichtiger Punkt für den reibungslosen Umbau im laufenden Betrieb ist die konsequente Einbindung des Kunden in den Entwicklungsprozess und die agile Zusammenarbeit über alle Ebenen und mit allen Projektbeteiligten. Einen Baustein bilden hier die sogenannten Fachverbund-Treffen, bei denen sich sämtliche Projektleiter aller Behörden, die bereits ON2 einsetzen und zukünftig SON einsetzen wollen, zusammenfinden. Hier wurden im moderierten Austausch zwischen SEITENBAU und den Behörden die Anforderungen der Anwender*innen in eine Reihenfolge gebracht, die von allen mitgetragen wird und für die meisten sinnvoll ist, z.B. indem mit einem verteilten Punkte-Voting einzelnen Modulen Gewicht verliehen wird.

In kürzeren Zeitintervallen findet eine präzisere, fortlaufende Abstimmung der Roadmap zusammen mit dem BVA als Haupt-Auftraggeber statt. Die gemeinsam priorisierten Anforderungen durchlaufen dann in Form von User Storys den klassischen Zyklus eines Scrum-Sprints, nämlich das Refinement, bei dem ein Team die Aufgabe genau betrachtet sowie Aufwände und Risiken schätzt, dem Planning, der Umsetzung in einem Sprint und schlussendlich der Präsentation der Ergebnisse in der Sprint-Review am Ende jedes zweiwöchigen Sprints.

Nicht alles lief immer reibungslos – (Zwischen-) Fazit und die wichtigsten „Lessons learned“

Ein Projekt wie die Weiterentwicklung von ON2 zu SON, inklusive sukzessivem Umbau von Bestandssystemen im laufenden Betrieb, gänzlich ohne ungeplante Hindernisse zu bewältigen, ist schier unmöglich. Und so stieß das Projektteam immer wieder auf große Herausforderungen.

So war eine ganz wesentliche Erkenntnis, dass ein für den laufenden Umbau notwendiges Hybrid-System mit Microservice-Architektur die betriebliche Komplexität teilweise sehr stark erhöht. Insbesondere im Hinblick auf die heterogenen Betriebs-Plattformen bei Kunden vor Ort, hätte teilweise noch größeres Augenmerk auf Einfachheit von Auslieferung, Installation und Betrieb der Anwendung gelegt werden sollen, z.B. durch weniger und dafür größere Services. Doch auch wenn aus Betriebssicht hier nicht immer alles reibungslos lief: bei der Komplexität einer solchen Anwendung ist letztlich der konsequente Einsatz von Container-Technologie von Anfang an quasi alternativlos, um eine Abstraktion von der Unterschiedlichkeit der einzelnen Services im Betrieb zu schaffen.

Eine der größten Herausforderungen war zudem die Festlegung der Ablösungs-Reihenfolge der Features und Module. Hier die richtige Auswahl zu treffen ist oftmals sehr schwer, da sowohl die fachlichen als auch die technischen Abhängigkeiten der jeweiligen Komponenten sehr komplex und kaum aufzulösen sind. Regelmäßige Absprachen mit den Kunden, vor allem intern mit den Produktmanagern, den Entwicklern und Architekten sind essenziell, um etwaige Fallstricke frühzeitig zu identifizieren. Technische Berater*innen innerhalb des Teams können hier ein sehr wertvolles Bindeglied zwischen Produktplanung und Entwicklung sein.

Ein sehr wichtiger Schritt ist dabei auch die Definition der verschiedenen Übergangs-Architekturen, die jeweils für eine gewisse Zeit den Echtbetrieb tragen und gewährleisten müssen. Auch hierbei ist eine weite Voraussicht der Architekten über bevorstehende Features sowie ein Verständnis der Produktmanager von der Architektur wichtig, was nur durch intensive Kommunikation sichergestellt werden kann. Da sich die Priorität von Kundenseite jederzeit ändern kann, hat sich für uns der Ansatz Agiler Architektur bewährt, d.h. ein grober Fahrplan ist vorhanden, aber genauere (Übergangs-) Architekturen werden erst bei Bedarf entworfen und dann zeitnah umgesetzt.

Eine weitere Lektion ist es, bei der Aufteilung der Features auf die neuen Microservices noch viel stärker nach dem Domain Driven Design (DDD) vorzugehen. Dieses stellt Tools und Methoden, wie dem sog. Context Mapping, bereit, mit deren Hilfe die Fachlichkeit besser durchdrungen, unterteilt und letztendlich auf technische Module abgebildet werden kann. Auch die Notwendigkeit, auf den Einsatz eines Cloud-Frameworks zu setzen, ist eine wesentliche Erkenntnis aus dem Projekt.

Wenn das Ergebnis überzeugt - Social OfficeNet gewinnt mehr und mehr Kunden

Nach nur zwei Jahren ab Start der Weiterentwicklung kam das neue Social OfficeNet bereits in einer ersten Version bei einem großen Neukunden zum Einsatz. Heute, nach vier Jahren und etwas über 100 Sprints, sind bereits diverse Kunden umgestiegen und immer mehr Bestandssysteme werden auf die neue Architektur portiert. Hinzu kommen einige Neukunden, die direkt das neue System einsetzen.

Eine Berührung der Endanwender*innen mit dem alten ON2 wurde weitestgehend reduziert. Eine Ausnahme bildet hier lediglich die übergangsweise Einbindung einiger weniger Module per iFrame. Auch ist die Umstellung auf die neuen User Interfaces der Anwendung im Redaktionsmodus noch nicht vollständig umgesetzt. Ansonsten sind die wichtigsten Use-Cases im neuen, modernen und benutzerfreundlichen Design vollständig responsive und weitestgehend barrierefrei umgesetzt.

Während SON fortlaufend noch um weitere, speziellere Module und Funktionalitäten erweitert wird, wird unter der Oberfläche noch kräftig umgebaut, das neue System weiter optimiert, und vor allem abgelöste Teile werden aus dem alten System sukzessive entfernt.

Beim vollständigen Umbau der Bestandsysteme stehen für die nahe Zukunft noch ein paar Aufgaben an, das System kann aber bereits bei Neukunden vollumfänglich eingesetzt werden, was alle Projektbeteiligten angesichts der Einhaltung von Time, Budget und Funktionsumfang als sehr großen Erfolg sehen.