Erfolg­rei­che BS2000-Migration bei ITZBund

Das Infor­ma­ti­ons­tech­nik­zen­trum Bund (ITZBund) ist der zentrale IT-Dienst­­leis­­ter für die deutsche Bundes­ver­wal­tung. Die Digita­li­sie­rung der öffent­li­chen Verwal­tung hat für ganz Deutsch­land große Bedeu­tung. Das ITZBund hat den politi­schen Auftrag der Bundes­re­gie­rung, die Verwal­tung mit moder­ner IT zu unter­stüt­zen und bereit für die digitale Zukunft zu machen.

Die Wirkung von kühlem Bier oder anderen geist­rei­chen Geträn­ken ist allge­mein bekannt. Wir durften im vergan­ge­nen Jahr ganz neue Erfah­run­gen auf diesem Gebiet sammeln. Aller­dings ging es für uns nicht um den Genuss, sondern um die toolge­stützte Migration eines komple­xen Software­pro­jek­tes zur Verwal­tung von Alkoho­lika von BS2000 nach Linux. Wie üblich gab es dabei wieder eine Reihe neuer Heraus­for­de­run­gen. Dieser Bericht vermit­telt Erkennt­nisse und Erfah­run­gen aus der Zusam­men­ar­beit zwischen Infor­ma­ti­ons­tech­nik­zen­trum Bund (ITZBund) und uns, welche in diesem Projekt gewon­nen wurden.

Neue BIBER- und ZEBRA-Gehege

ITZBund ist der IT-Dienst­­leis­­ter des Bundes. 2.400 Mitarbeiter(innen) beraten, unter­stüt­zen und sichern den laufen­den Betrieb sowie die Versor­gung mit Infor­ma­ti­ons­tech­nik und spezi­ell entwi­ckel­ten IT-Lösun­­­gen. Im Projekt sollten zwei IT-Lösun­­­gen (sog. Verfah­ren) zur Festset­zung und Erhebung von Bier- bzw. Alkohol­steu­ern migriert werden. Die Verfah­ren BIBER (Biersteu­er­be­rech­nung) und ZEBRA (Zentra­li­sie­rung des Brennens unter Abfin­dung) sind histo­risch gewach­sen und seit mehr als 30 Jahren im Einsatz. Sie erzeu­gen ca. 220.000 Bescheide mit einem Steuer­auf­kom­men von 740 Millio­nen Euro pro Jahr. Sie wurden auf BS2000 betrie­ben und es kamen typische BS2000-Werkzeuge zum Einsatz. Technisch bestehen beide Verfah­ren aus 60 inter­ak­ti­ven Online-Program­­­men (IFG-Masken) unter der Steue­rung des Trans­ak­ti­ons­mo­ni­tors UTM und aus 300 Batch­pro­gram­men (COBOL), zu deren Steue­rung und Verwal­tung ca. 200 SDF-Jobs einge­setzt werden. Die Daten werden in ca. 220 SAM‑, ISAM- und LEASY-Dateien verwaltet.

Was Du heute kannst besorgen…

Wir verfü­gen über eine firmen­ei­gene Toolbox namens pecBOX (pro et con – Toolbox für die Software-Migration). Mit dieser konnten alle notwen­di­gen Migra­ti­ons­pfade des Projek­tes unter­stützt werden. Die folgende Tabelle dokumen­tiert diese und die einge­setz­ten Migrationswerkzeuge.

Basis­sys­tem (BS2000) Zielsys­tem Migra­ti­ons­werk­zeug
COBOL Java CoJaC
JCL (SDF) Perl S2P
Masken (IFG) HTML, JavaScript MaTriX
Dateien (SAM) Linux-Files FiRe
Dateien (ISAM, LEASY) Oracle FiRe
Middle­ware (UTM) MidaS

Dass quali­ta­tiv gute Migra­ti­ons­werk­zeuge die Projekt­lauf­zeit verkür­zen und Budget schonen, ist nicht neu. Das Projekt konnte nur so im vorge­ge­be­nen, engen Zeitrah­men reali­siert werden. Aber auch die Erfah­rung: “Fertige Werkzeuge gibt es nicht!” wurde bestä­tigt. Konkret mussten z.B. CoJaC und FiRe das “Rückwärts­le­sen” von LEASY-Dateien lernen. Bei diesen Anpas­sun­gen favori­sie­ren wir die Erwei­te­rung unserer Tools gegen­über einer manuel­len Anpas­sung des Source­codes. In frühen Projekt­sta­dien kann nicht einge­schätzt werden, warum und wie häufig schon konver­tierte Programme erneut konver­tiert werden müssen. Die manuelle Anpas­sung müsste dann jedes Mal wieder­holt werden. Da alle Werkzeuge auf deskrip­ti­ven Model­len und Metawerk­zeu­gen basie­ren, ist deren Anpas­sung in einem akzep­ta­blen Zeitrah­men möglich. pecBOX enthält darüber hinaus auch System­kom­po­nen­ten für das Zielsys­tem. Ein Beispiel dafür ist MidaS (Middle­ware als Service). Dieses von uns entwi­ckelte Tool ersetzt den BS2000-Trans­ak­­ti­on­s­­mo­­ni­­tor UTM im Zielsys­tem. Durch einen frühzei­ti­gen Lasttest konnte nachge­wie­sen werden, dass die Perfor­mance von MidaS den prakti­schen Anfor­de­run­gen genügt und deshalb auf den Einsatz von kosten­pflich­ti­ger Standard­soft­ware verzich­tet werden kann.

Wissen ist Macht

Die erste Phase eines Migra­ti­ons­pro­jek­tes beinhal­tet ein toolba­sier­tes Reverse Enginee­ring mit unserem Werkzeug Flow Graph Manipu­la­tor (FGM). Dabei wird ein spezi­el­les Augen­merk auf jene Aspekte gewor­fen, die Risiken für die Migration darstel­len. Im vorlie­gen­den Fall lagen diese vor allem in der Daten­hal­tung. Laut definier­tem Migra­ti­ons­pfad sollten ISAM- und LEASY-Dateien durch FiRe in Oracle-Tabel­­len migriert werden. In der Analyse wurde eine Beson­der­heit identi­fi­ziert: Die dynami­schen Inhalte aus den Dateien werden bei der Programm­aus­füh­rung durch stati­sche Inhalte (Konstan­ten) aus den Program­men angerei­chert und danach über eine Drucker­schnitt­stelle ausge­ge­ben. Schon vor der Migration musste deshalb das Encoding der Daten und Quell­texte (inkl. Konstan­ten) verein­heit­licht werden. Dieser Punkt betraf also nicht nur eine Anpas­sung von FiRe, sondern erstreckte sich auch auf weitere Aspekte der Migration. Je früher solche vermeint­li­chen Kleinig­kei­ten im Projekt erkannt werden, desto gerin­ger ist der Aufwand ihrer Behebung, da eventu­ell schon eine Konfi­gu­ra­tion der Migra­ti­ons­werk­zeuge ausreicht.

Versuch macht klug

Nach einer detail­lier­ten Analyse und ausge­stat­tet mit einem vollen Werkzeug­kas­ten sollte man davon ausge­hen können, dass die eigent­li­che Migration direkt in der Breite gestar­tet werden kann. Unsere Erfah­run­gen belegen etwas anderes. In der erstma­li­gen Kombi­na­tion von Werkzeu­gen und Kunden­an­for­de­run­gen stecken unbekannte Heraus­for­de­run­gen. Aus diesem Grund wurde vor dem Gesamt­pro­jekt ein Pilot migriert, welcher einen verti­ka­len Schnitt durch die Anwen­dung (Maske(n), Programm(e), Jobs, Daten) geboten hat. Dadurch wurden alle Migra­ti­ons­pfade einmal durch­lau­fen und die Tools und Techno­lo­gien (zumin­dest zum Teil) genutzt. Dieses Vorge­hen erwies sich als nützlich, wurden doch wesent­li­che Erkennt­nisse gewon­nen. So erfolgte z.B. die Entschei­dung, das Drucken in ein separa­tes Tool auszu­la­gern und nicht über die in den Laufzeit­sys­te­men existie­ren­den Lösun­gen abzubil­den. Diese hätten den kunden­spe­zi­fi­schen Anfor­de­run­gen nicht genügt. Aufgrund dieses Vorge­hens wurden zusätz­li­che Anfor­de­run­gen erkannt und vor der eigent­li­chen Migration imple­men­tiert. Das reduzierte das Risiko, die Werkzeug­an­pas­sun­gen neben den Aufga­ben der Migration vorneh­men zu müssen.

Divide et impera

Bei einem Migra­ti­ons­pro­jekt, welches alle Facet­ten von Legacy-Syste­­men wider­spie­gelt, besteht die Heraus­for­de­rung, die Komple­xi­tät der Migra­­ti­ons- und Testpro­zesse zu reduzie­ren. Im vorlie­gen­den Projekt wurde dem Rechnung getra­gen, indem unser Partner ITZBund die Anwen­dung in einzelne Pakete aufteilte. Die Basis für die Auftei­lung waren die (Geschäfts-)Prozesse, welche sinnvoll in Pakete zusam­men­ge­fasst wurden. Die dadurch mögli­che Paral­le­li­sie­rung von Migration und Test zeigte im Projekt viele Vorteile. Ein wesent­li­cher Punkt war auch die Kommu­ni­ka­tion zu den Fachleu­ten von ITZBund. Diese kennen ihre Prozesse und konnten valide Testda­ten bereit­stel­len. Diese Daten und die definier­ten Prozesse boten auch die Möglich­keit der Automa­ti­sie­rung. Dazu wurden die Prozesse und die passen­den Daten normiert und in Testfälle überführt, was den Aufwand für den Test enorm vermin­derte. Durch die Auftei­lung in einzelne Pakete blieben Migration und Test zu jeder Zeit beherrsch­bar und es existierte stets ein Überblick über den Projektfortschritt.

Man lernt nie aus

Am 12.09.2016 wurde das Projekt produk­tiv geschal­tet. Erneut wurde mit diesem Projekt bewie­sen, dass der von uns verfolgte, toolba­sierte Ansatz funktio­niert. Das gilt insbe­son­dere für die automa­ti­sche Sprach­kon­ver­tie­rung von COBOL nach Java mit dem Werkzeug CoJaC. Techno­lo­gien und Werkzeuge können noch so erprobt und ausge­reift sein, jedes neue Migra­ti­ons­pro­jekt bietet neue Heraus­for­de­run­gen. Dabei entfällt auch immer ein nicht unwesent­li­cher Aufwand auf unsere Projekt­part­ner. Diesen hat ITZBund durch Fachwis­sen und aktive Mitar­beit vorbild­lich geleis­tet. Nur durch eine so enge Zusam­men­ar­beit können Migra­ti­ons­pro­jekte erfolg­reich verlaufen.