Digital Business

Dieser Artikel ist Teil einer Serie:

• Teil 1: Stammdatenqualität und Softwareentwicklung
• Teil 2: Entstehung und Auswirkungen von Legacy-Systemen
• Teil 3: Ablösung von COBOL-basierten Legacy-Systemen

Vom Monolithen zur modernen Anwendung - eine Fallstudie

Nach einer ersten Betrachtung der „Entstehung und Auswirkungen von Legacy Systemen” wird im nächsten Schritt anhand einer Fallstudie ein möglicher Ansatz zur Ablösung eines komplexen Altsystems beschrieben.

KLINK - die Wetterdatenbank

In diesem Artikel dient ein fiktives Beispiel als Fallstudie. Ein Unternehmen, das sich auf Klimaauswertungen und Wetteranalysen spezialisiert hat, möchte seine Klimadatenbank modernisieren. Das verwendete System, seit über zwei Dekaden auf einem Mainframe im Einsatz, ist ein in COBOL geschriebener Monolith. COBOL steht für „Common Business Oriented Language“ und ist eine in den 50er Jahren entstandene imperative Programmiersprache. Die Klimadatenbank ist essentiell für den Unternehmenserfolg, viele Online-Wetterdienste und Institute werden durch das Unternehmen mit Daten versorgt, selbst wenige Stunden Ausfall des laufenden Systems bedeuten hohe Kosten für das Unternehmen.

Das System, nennen wir es KLINK (Klimadaten-Nutzungs- und -Kommunikationsprogramm), besteht aus einer Verwaltung diverser archivierter, meteorologischer Informationen. Das System erzeugt statistische Auswertungen und aggregiert Daten weltweiter Messstationen. Dabei importiert es diese Daten aus unterschiedlichsten Quellen. Die Kunden werden direkt im System verwaltet und auch die Bereitstellung der Daten an die Kunden erfolgt durch KLINK über diverse Schnittstellen.

„Big-Bang“ oder kleinschrittiges Vorgehen

Das Team, das mit der Modernisierung des Altsystems beauftragt wurde, muss zunächst die Form der Ablösung klären. Die erste Möglichkeit ist eine „Big Bang“-Ablösung, sprich das System im Ganzen abzulösen und an einem Stichtag das Altsystem abzuschalten und nur noch das neue System zu betreiben. Die Alternative besteht darin, Bestandteile des Systems herauszulösen und das
System Schritt-für-Schritt durch neue kleinere Services abzulösen.

"Das Risiko einer Big Bang-Ablösung ist aufgrund der riesigen Codebasis besonders hoch, sodass die Entscheidung auf ein schrittweises Ablösen einzelner Elemente des Altsystems fällt."

Die Komplexität des Altsystems kann nur schwierig durch das Team eingeschätzt werden. Auch die Expertise der erfahreneren Entwickler von KLINK kann dem Team nur bedingt helfen, da ein Wissenstransfer über das gesamte System sehr aufwändig und schwierig ist. Zudem befürchtet das Team, dass bei einer Komplettablösung nicht der gesamte Funktionsumfang des Systems erfasst wird und so wichtige, nicht auf Anhieb ersichtliche Funktionalität verloren gehen kann. Das Risiko einer Big Bang-Ablösung ist aufgrund der riesigen Codebasis besonders hoch, sodass die Entscheidung auf ein schrittweises Ablösen einzelner Elemente des Altsystems fällt. Dabei holt sich das Team Inspiration bei dem aktuell anhaltenden Trend zu Microservices.

Auswahl der ersten Teilbereiche

Im ersten Schritt versucht das Team Teilbereiche in KLINK zu identifizieren. Diese können durch ein oder mehrere der folgenden Merkmale identifiziert werden:

• die Teilbereiche sind eine fachlich geschlossene logische Einheit
• der Nutzerkreis des Teilbereichs von KLINK ist eindeutig identifizierbar
• der Teilbereich ist im Altsystem quellcode-technisch greifbar und kann dementsprechend separiert werden

Nach einer ersten Analyse des Systems identifiziert das Team mehrere mögliche Sektionen des Altsystems, die sich als eigenständige Teilbereiche eignen. Darunter sind die z.B. „Verwaltung von Kundendaten“, „Verwaltung der Messstationen“, „Rechnungserzeugung für Kunden”, „Bereitstellung von Wettervorhersagen an Online-Portale“ und weitere. Dabei fällt auf, dass diese Teilbereiche in zwei grundlegende Gruppen aufgeteilt werden können:

• Verwaltung von Stammdaten (etc. Kundendaten, Messstationen)
• Verwaltung von Bewegungsdaten (Rechnungserzeugung, Wettervorhersagen)

Da für die Erzeugung und Administration der Bewegungsdaten die Stammdaten benötigt werden und die Stammdaten zum großen Teil voneinander unabhängig sind, entscheidet sich das Team zunächst die Stammdaten herauszulösen. Damit aber die Bewegungsdaten im Altsystem unverändert weiter funktionieren können, ist der Plan des Teams, das Altsystem aus den neuen Systemen weiterhin mit den Stammdaten zu versorgen. Die Verwaltung der Daten wandert also in die neu geschaffenen Systeme, zur Rückwärtskompatibilität werden KLINK die Daten in der Anfangsphase noch bereitgestellt. Dafür ist es essentiell, dass im operativen Betrieb die Datenhoheit bei immer genau einem System liegen muss. D.h. wenn beispielsweise die „Verwaltung von Messstationen“ bereits über einen neuen Service erfolgt, so darf das Altsystem auf diese Werte nur noch lesend zugreifen. Dafür muss bei Livegang eines neuen Systems die alte Verwaltung deaktiviert werden und der aktuelle Stand der Daten über einen regelmäßigen Export dem Altsystem bereitgestellt werden. Dieser kann entweder zeitgesteuert oder nach jeder Änderung ausgeführt werden.

Erstellung geeigneter technischer Schnittstellen

Die Definition geeigneter Schnittstellen zur Gewährleistung einer Rückwärtskompatibilität kann auf zwei Wegen erfolgen:

• Implementierung neuer Schnittstellen, dabei entsteht Entwicklungsaufwand auf beiden Seiten
• Wiederverwendung von bereits existierenden, internen Schnittstellen des Altsystems als externe Interfaces

Die zweite Variante setzt ein Format voraus, das von beiden Systemen verstanden wird. Entweder existiert bereits ein möglicher Standard, der von beiden genutzt werden kann oder einem System muss ein Format des Gegenübers beigebracht werden.

KLINK arbeitet mit Daten in Flat Files mit fester Spaltenbreite. Diese Dateien verwenden eine COBOL Schema Struktur, die sich als mögliches Schnittstellenformat anbietet. Auch wenn die Kommunikation über derartige Files eher antiquiert erscheint, hat sie den großen Vorteil, dass wenig bis kein Entwicklungsaufwand im Altsystem für die Dateierstellung/-import anfällt. Die Anzahl der Entwickler, die in der Lage sind, Anpassungen am bestehenden System vorzunehmen, ist begrenzt und demnach bleibt dem Team nichts anderes über, als diese Schnittstelle zu wählen.

Ablösung mit COBOL Schnittstellen

Die Struktur der genutzten Schnittstelle lässt sich gut an einem Beispiel erklären: Das Team ist mittlerweile bei der Ablösung des Systems zur „Verwaltung von Durchschnittstemperaturen pro Standort“ angelangt. In der Vergangenheit hatte das Unternehmen immer wieder Probleme mit der Granularität der Daten, das Altsystem importiert die Daten aus diversen Messdaten externer Schnittstellen und speichert diese. Leider passiert das in einem einmaligen täglichen Lauf, der die Daten nach Tag und Stadt aggregiert speichert. Die Fachabteilung wünscht sich aber eine deutlich genauere Speicherung der Daten - minutengenaue Persistierung und detailliertere Standortinformationen. Diese Anpassung soll aber nur im neuen System erfolgen.

Im KLINK ist das Format der Daten in einer COBOL-Datenstruktur (vgl. IBM oder Wikipedia) gespeichert, die durch das folgende Schema beschrieben wird.

*** MEAN TEMPERATURE BY CITY
   01  CITY                     PIC X(30).
   01  MEAN-TEMPERATURE         PIC 9(3).9(2).
   01  DATE-YYYYMMDD            PIC 9(8)
   01  NUMBER-OF-MEASUREMENTS   PIC 9(3).

Dieses Format ist ein COBOL-Standard. „PIC X“ steht für eine String-„Spalte” der Zahlenwert in Klammern steht für die Länge. „PIC 9“ beschreibt einen numerischen Wert. Der Wert „PIC 9(3).9(2)” beschreibt eine Kommazahl mit 3 Vor- und 2 Nachkommastellen.

Eine Datei im beschriebenen Format sieht wie folgt aus:

Münster                       00320160225200
Dortmund                      00220160225260
Frankfurt                     02620150601260

Das Team hat eine Bibliothek entwickelt, der die COBOL-Schemabeschreibungen interpretiert, und in Ruby-Objekte umwandelt. Der Adapter interpretiert das obige Format zu den folgenden Werten:

frankfurt = MeanTemperatureByCity.new(
  city: 'Frankfurt', 
  mean_temperature: 26.1, 
  date_yyyymmdd: Date.parse('2015-06-01').strftime('%Y%m%d').to_i, 
  number_of_measurements: 260
)
dortmund = MeanTemperatureByCity.new(
  city: 'Dortmund', 
  mean_temperature: 2.7, 
  date_yyyymmdd: Date.today.strftime('%Y%m%d').to_i, 
  number_of_measurements: 260
)
muenster = MeanTemperatureByCity.new(
  city: 'Münster', 
  mean_temperature: 3.5, 
  date_yyyymmdd: Date.today.strftime('%Y%m%d').to_i, 
  number_of_measurements: 200
)

Der Export der Objekte „frankfurt“, „dortmund“ und „muenster“ wiederum hätte die obige Datei zur Folge. Der Wrapper stellt sicher, dass die Formate des COBOL Schemas bei Import und Export eingehalten werden und kümmert sich um das Schreiben und Lesen der Schnittstellendatei.

Struktur des Exports

Die neuen Systeme sollen möglichst unabhängig von der Datenstruktur des Altsystems sein, daher muss die neue Struktur im Export auf die beschrieben Schnittstellen gemappt werden. Die Bereitstellung dieser Daten ist im Vorhinein für eine befristete Lebenszeit ausgelegt. Sobald die COBOL-basierte Anwendung nicht mehr in Betrieb ist, wird die Schnittstellen-Logik nicht mehr benötigt. Aus diesem Grund sollte dieser möglichst eigenständig und von der operativen Anwendung getrennt sein.

Die grundsätzliche Datenstruktur der neu erstellten Anwendung wird im Export der neuen Systeme auf die COBOL-Struktur projiziert. Sind einzelne Datenfelder oder Bereiche nicht 1-zu-1 auf das alte Format zu übertragen, helfen dedizierte Konverter bei Format-Umwandlungen oder Aggregationen. Ein simpler Konverter, der das Datum in das Format des Altsystems bringt kann wie folgt aussehen:

class DateConverter
  attr_reader :legacy_date_format
  def initialize(legacy_date_format:)
    @legacy_date_format = legacy_date_format
  end

  def to_legacy_format(date)
    Date.parse(date).strftime(legacy_date_format).to_i
  end

  def from_legacy_format(date)
    date.strptime(legacy_date_format)
  end
end

In den Konvertern können alle Sonderregelungen oder Einschränkungen des Altsystems gekapselt werden, die nach der Komplettablösung nicht mehr gelten. Wie schon erwähnt wünscht sich die Fachabteilung eine detailliertere Speicherung der Messdaten. Daher können im neuen System die Werte minutengenau und inklusive GPS-Koordinaten gespeichert werden. Das Altsystem kann in regelmäßigen Exporten über einen entsprechenden Konverter mit aggregierten Werten versorgt werden. So bleibt die Datenstruktur im alten System unverändert und bestehende Statistiken oder weitere Schnittstellen können ohne Anpassungen im Bestandssystem zunächst unverändert weiterlaufen.

Da die Datenmenge der Durchschnitts-Temperaturen über die Zeit immer größer wird, wurden die Daten der Systeme durch initiale Importe/Exporte abgeglichen. Danach sorgen tägliche Delta-Exporte aus der neuen Verwaltung für einen synchronen Datenstand der Programme.

Vergleich von Schnittstellendateien

Ein Vorteil der dateibasierten Schnittstelle zu KLINK sind mögliche Vergleichsmechanismen, die auf Dateiebene oder auch auf Ruby-Ebene durchgeführt werden können. So können in einer Testphase das Altsystem und das neue parallel laufen und beide erzeugen die Schnittstellendatei. Auf Dateiebene können die erzeugten Werte verglichen werden. So kann sichergestellt werden, dass das neue System rückwärtskompatibel arbeitet und die korrekten Werte liefert.

Quintessenz

Anhand dieser Fallstudie zur Ablösung eines COBOL-basierten Systems soll eine mögliche Herangehensweise an die Aufgabe der Modernisierung komplexer Systeme beschrieben werden. Insbesondere die Rückwärtskompatibilität bei einer schrittweisen Vorgehensweise ist eine Herausforderung. Das neue System muss während der Übergangsphase auf die neue Architektur durch Schnittstellen rückwärtskompatibel bleiben. Wie beschrieben, muss die Datenhoheit immer bei einem System liegen, während der jeweils andere Part nur lesend auf die Daten zugreift. Durch die Ablösung wandert nach und nach immer mehr Verantwortung in die neuen Systeme, sodass die Existenzberechtigung des alten Systems immer weiter schwindet.

"Das neue System muss während der Übergangsphase auf die neue Architektur durch Schnittstellen rückwärtskompatibel bleiben."

Durch die Auswahl kleinerer Teilbereiche soll die Komplexität für das Team besser greifbar werden. So kann auch ein jahrzehntelang gewachsenes COBOL-System durch das Team besser verstanden und abgelöst werden.

(Dieser Artikel wurde erstmals am 29.03.2017 veröffentlicht. Er wurde am 02.03.2021 aktualisiert.)