Der Kunde stand vor einer schwierigen Gratwanderung: Ein Altsystem musste dringend aktualisiert werden, allerdings darf dabei der Betrieb keinesfalls gestört werden, da es sonst zu kritischen Ausfällen in der Infrastruktur käme.
Es war schnell klar, dass eine Big-Bang-Umstellung auf ein komplett neues System mit großen Risiken verbunden wäre. Daher entschied sich das Transportunternehmen dazu, den IT-Monolithen bzw. das Altsystem nach und nach zu erneuern.
Diese „Salamitaktik“ erlaubt ein sukzessives Herausschneiden von Funktionen. Damit können Verbesserung und Portierung auf eine neue Technologie gewährleistet werden, bei einem gleichzeitig zuverlässigen Gesamtsystem und funktionierenden Prozessen: Das Hauptaugenmerk für Kritis-Betreiber.
Bei einem solchen grundlegenden Umbau der digitalen Architektur, nutze das Verkehrsunternehmen dazu die Chance, um eine neue zukunftsorientierte IT-Strategie auszuarbeiten.
Es war schnell klar, dass eine Big-Bang-Umstellung auf ein komplett neues System mit großen Risiken verbunden wäre. Daher entschied sich das Transportunternehmen dazu, den IT-Monolithen bzw. das Altsystem nach und nach zu erneuern.
Diese „Salamitaktik“ erlaubt ein sukzessives Herausschneiden von Funktionen. Damit können Verbesserung und Portierung auf eine neue Technologie gewährleistet werden, bei einem gleichzeitig zuverlässigen Gesamtsystem und funktionierenden Prozessen: Das Hauptaugenmerk für Kritis-Betreiber.
Bei einem solchen grundlegenden Umbau der digitalen Architektur, nutze das Verkehrsunternehmen dazu die Chance, um eine neue zukunftsorientierte IT-Strategie auszuarbeiten.
Herausforderung
Die Software des Transportunternehmens wird hauptsächlich für die Personaleinsatzplanung der Fahrzeugführer verwendet. Dazu kommen noch angrenzende Fremdsysteme innerhalb der kritischen Infrastruktur. Dabei bildet das seit 20 Jahren laufende System alle für den Betrieb notwendigen Bereiche ab (z.B. Personal- und Arbeitszeitverwaltung, Fahr- und Auftragsplanung sowie -bearbeitung, Arbeitszeiterfassung- und nachweise, etc.).
Eine der größten Herausforderung liegt selbstverständlich im über Jahrzehnte organisch gewachsenen IT-Monolithen selbst: Die Prozesse des Systems sind derart verwoben, dass es schwierig ist, sie zu sezieren. Das ist aber notwendig, um gegebenenfalls einzelne Funktionen abzutrennen und ggf. in moderner Technologie umzusetzen. Dazu kommt, dass bei einem Altsystem oft nicht alles dokumentiert ist oder veraltet. Das hat zur Folge, dass nicht genau vorhersehbar ist, was beim „Sezieren“ einzelner Funktionen passiert. Wird ein Service abgeschnitten, fällt irgendwo an anderer Stelle unter Umständen etwas raus und geht schlicht kaputt. Auch dem muss methodisch, präzise und vor allem mit teils automatisierten Testen vorgebeugt werden. Dabei gilt es, das verloren gegangene Silowissen der vergangenen Jahrzehnte neu aufzubauen und einen guten Wissenstransfer zu ermöglichen.
Eine der größten Herausforderung liegt selbstverständlich im über Jahrzehnte organisch gewachsenen IT-Monolithen selbst: Die Prozesse des Systems sind derart verwoben, dass es schwierig ist, sie zu sezieren. Das ist aber notwendig, um gegebenenfalls einzelne Funktionen abzutrennen und ggf. in moderner Technologie umzusetzen. Dazu kommt, dass bei einem Altsystem oft nicht alles dokumentiert ist oder veraltet. Das hat zur Folge, dass nicht genau vorhersehbar ist, was beim „Sezieren“ einzelner Funktionen passiert. Wird ein Service abgeschnitten, fällt irgendwo an anderer Stelle unter Umständen etwas raus und geht schlicht kaputt. Auch dem muss methodisch, präzise und vor allem mit teils automatisierten Testen vorgebeugt werden. Dabei gilt es, das verloren gegangene Silowissen der vergangenen Jahrzehnte neu aufzubauen und einen guten Wissenstransfer zu ermöglichen.
Alle Herausforderungen im Überblick
- Eine veraltete Technologie und historisch organisch gewachsene IT-Architektur, die einen monolithischen „Big Ball of Mud“ zur Folge hat: Die Codebasis und damit die Prozesse und Funktionalitäten sind technisch so miteinander verwoben, dass es schwierig ist, einzelne Funktionalitäten abzutrennen. Dazu leidet die IT-Sicherheit, auch weil es schwierig ist, das System auf einen aktuellen Stand zu bringen.
- Innerhalb der letzten Jahre sind die Größe und Komplexität des Systems enorm angewachsen. Das System muss verschlankt werden.
- Der Kunde wünscht sich Fachwissen und Expertise in IT-Prozessen eines externen Spezialisten; die dokumentierten Fachprozesse orientieren sich an den Systemfunktionen.
- Es ist kein (sofortiger) Komplettumstieg möglich (kein „Big Bang“-Umstieg).
- Der „veraltete“ Monolith muss weiterhin gewartet und stets verfügbar sein.
- Stete Weiterentwicklung und Anpassungen von Funktionen sind dennoch notwendig (aufgrund von gesetzlichen und betrieblichen Anforderungen).
- Projektsteuerung, Projektmanagement und Anforderungserhebung lag beim bisherigen Entwicklerteam, was eine große Abhängigkeit in fachlicher als auch technischer Sicht vom bisherigen Softwareunternehmen zur Folge hat.
- Das heißt auch, dass inhouse personelle Ressourcen für die Softwareentwicklung- sowie Wartung für das komplexe System nicht vorhanden sind.
- Der Kunde verfügt nicht über ausreichend Expertise im PM-Methodenwissen, um eine neue Lösung angehen zu können.
- Zusätzlich sind ein guter Support und Testing nötig.
Das Ziel
Für Kritis-Betreiber gilt immer das eine Ziel: Aufrechterhaltung der Systemverfügbarkeit. Die Kernaufgabe ist also, den Fortbestand des Systems zu härten sowie Schwachstellen auszumerzen sowie Prozesse und Funktionalitäten zu verschlanken. Langfristig soll das System auf einer moderne IT-Architektur fußen. Alle Ziele können nur im Verbund zu einer erhöhten Resilienz beitragen und das System langfristig effektiv, effizient und krisensicher machen.
Die Lösung
Spotlight: Domain driven Design
Um in einem sehr komplexen System Struktur zu schaffen, entschieden wir uns für das Strategische Domain Driven Design als Lösung für die Softwareentwicklung. Das funktioniert im Grunde ganz simpel: Wir definieren Domänen und arbeiten die Kernprozesse heraus. Das Gute dabei ist: Wir bauen damit Domainwissen auf und befähigen Entwickelnde, die Fachprozesse zu verstehen und eine einheitliche Projektsprache zu sprechen - sowohl in der Softwareentwicklung als auch in der Dokumentation. Das gewährleistet nachhaltigen Wissenstransfer.
Der Ansatz des DDD kommt daher von der Fachlichkeit her, weniger von den technischen Voraussetzungen. Wir wollen vermeiden, dass sich Nutzer:innen den technischen Gegebenheiten eines Systems anpassen müssen, was nicht intuitiv ist. Domain Driven Design ist das Hilfsmittel unserer Wahl, um technische und fachliche Aspekte präzise zu entflechten, zu identifizieren und ggf. zu ersetzen.
Spotlight: Steigerung der IT-Resilienz
Ein IT-System auf dem aktuellsten Stand zu halten, ist innerhalb einer IT-Resilienz sehr wichtig. Durch die „Salamitaktik“ aktualisieren wir das IT-System auf moderne Technologien oder Warten entsprechend den Monolithen, sodass das System auf dem aktuellen Stand gehalten werden kann und gemäß der IT-Strategie auch zukunftsfähige Prozesse etabliert werden können.
Aber auch die Komplexität wird verringert, ein ebenfalls wichtiger Punkt in der IT-Resilienz. Denn das System ist weniger anfällig durch unnötige Funktionen und unnötigen Code, der dazu noch schwer wartbar ist. Aber auch die Einarbeitung von Mitarbeitenden geht schneller.
Spotlight: IT-Strategie & Methoden
Assecor unterstütze bei der Formulierung der IT-Strategie sowie der Projektmanagement-Methode.
Bei der Projektmanagement-Methode wählt man eine agile Vorgehensweise für die Weiterentwicklung: Angelehnt an das Framework Scrum und dazu Kanban-Boards mit Priorisierung für Wartungsarbeiten. So können wir das Beste aus beiden Welten für den Kunden bereitstellen.
Dies soll gerade in einem Projekt mit einem solch hohen Komplexitätsgrad und zahlreichen Stakeholdern die Koordination und Planung optimieren und für einen regelmäßigen Austausch sorgen.
Um in einem sehr komplexen System Struktur zu schaffen, entschieden wir uns für das Strategische Domain Driven Design als Lösung für die Softwareentwicklung. Das funktioniert im Grunde ganz simpel: Wir definieren Domänen und arbeiten die Kernprozesse heraus. Das Gute dabei ist: Wir bauen damit Domainwissen auf und befähigen Entwickelnde, die Fachprozesse zu verstehen und eine einheitliche Projektsprache zu sprechen - sowohl in der Softwareentwicklung als auch in der Dokumentation. Das gewährleistet nachhaltigen Wissenstransfer.
Der Ansatz des DDD kommt daher von der Fachlichkeit her, weniger von den technischen Voraussetzungen. Wir wollen vermeiden, dass sich Nutzer:innen den technischen Gegebenheiten eines Systems anpassen müssen, was nicht intuitiv ist. Domain Driven Design ist das Hilfsmittel unserer Wahl, um technische und fachliche Aspekte präzise zu entflechten, zu identifizieren und ggf. zu ersetzen.
Spotlight: Steigerung der IT-Resilienz
Ein IT-System auf dem aktuellsten Stand zu halten, ist innerhalb einer IT-Resilienz sehr wichtig. Durch die „Salamitaktik“ aktualisieren wir das IT-System auf moderne Technologien oder Warten entsprechend den Monolithen, sodass das System auf dem aktuellen Stand gehalten werden kann und gemäß der IT-Strategie auch zukunftsfähige Prozesse etabliert werden können.
Aber auch die Komplexität wird verringert, ein ebenfalls wichtiger Punkt in der IT-Resilienz. Denn das System ist weniger anfällig durch unnötige Funktionen und unnötigen Code, der dazu noch schwer wartbar ist. Aber auch die Einarbeitung von Mitarbeitenden geht schneller.
Spotlight: IT-Strategie & Methoden
Assecor unterstütze bei der Formulierung der IT-Strategie sowie der Projektmanagement-Methode.
Bei der Projektmanagement-Methode wählt man eine agile Vorgehensweise für die Weiterentwicklung: Angelehnt an das Framework Scrum und dazu Kanban-Boards mit Priorisierung für Wartungsarbeiten. So können wir das Beste aus beiden Welten für den Kunden bereitstellen.
Dies soll gerade in einem Projekt mit einem solch hohen Komplexitätsgrad und zahlreichen Stakeholdern die Koordination und Planung optimieren und für einen regelmäßigen Austausch sorgen.
Die Lösung im Überblick
- Aufbau einer Wissensbank: Das bestehende System vollständig dokumentieren und Silowissen abbauen durch Analyse und vollständige Fachdokumentation der vorhandenen Legacy-Systeme sowie Aufnahmen und Evaluierung aller Fremdsysteme und Schnittstellen.
- Erstellung eines IT-Bebauungsplans für Teile der Architektur sowie Dokumentation der Datenflüsse (das umfasst auch das Aufzeigen von IST- & SOLL-Zuständen).
- Gemeinsam mit dem Kunden und seinem Fachwissen Anforderungen aufnehmen und dokumentieren, sodass im Projekt eine einheitliche Sprache gesprochen werden kann. Insbesondere ist es wichtig, gemeinsam am Aufbau von Domänen- und Systemwissen zu arbeiten, um Prozesse und Funktionen optimal entflechten zu können. Hierfür haben wir den Ansatz des Strategischen Domain Driven Designs gewählt.
- Beratung und Sensibilisierung des Kunden für Risiken und IT-Sicherheit.
- Gemeinsame Erarbeitung einer IT-Strategie und Projektvorgehen.
- Etablieren von zukunftsfähigen Prozessen mit moderner Technologie.
- Wartung des Altsystems.
- Durch das Gesamtprojekt hindurch braucht es stetes Testmanagement. Die Devise: Testen, testen, testen. Da die Technologien unterschiedlich sind, gibt es verschiedene Teststrategien. Diese umfasst: Unit-Tests, statischer Codeanalyse mit Tools wie Sonarqube zum Auffinden von Fehlern im Altsystem, sogenannte „Code-Smells“ für Wartbarkeit, Aufdecken von kritischen Sicherheitslecks, Code-Review, Manuelles Testen durch Tester (Integrationstests), etc.
- „Weiterentwicklung“ des Monolithen mit Augenmaß --> so wenig wie irgend möglich im bestehenden System erweitern/ändern.
- Modularer Aufbau mit Salamitechnik fördern: Bei größeren Funktionsänderungen die betroffenen Funktionen aus dem Monolithen „herausschneiden“, neu implementieren und per Schnittstelle an den Monolithen anbinden. Das macht den Monolithen „kleiner“ und weniger komplex. Damit wird er ein Teil eines neuen modularen Gesamtsystems.
Das Projekt auf einen Blick
Branche: Transportunternehmen
Nutzer:innen: ca. 1.200 Mitarbeitende
Projektdauer insgesamt: 2018 bis heute
Teammitglieder: Assecor stellt 5 Teammitglieder in verschiedenen Rollen
Nutzer:innen: ca. 1.200 Mitarbeitende
Projektdauer insgesamt: 2018 bis heute
Teammitglieder: Assecor stellt 5 Teammitglieder in verschiedenen Rollen
Photo by lan deng on Unsplash
