Home > Services > Migration

Migration zu BICsuite und schedulix Workload Automation

Hohe Kosten, schlechter Support, fehlende Features: Es gibt viele Gründe, ein bestehendes Enterprise Job Scheduling System auf das BICsuite Workload Automation System migrieren zu wollen. Eine Hürde für die Entscheidung zur Migration ist oft die Unsicherheit darüber, wie eine Migration im laufenden Betrieb möglich ist und wie der Prozess gestaltet wird. Diese Fragen beantworten wir in dem Whitepaper zu unserer Migrationsmethode. Das Dokument beschreibt eine in der Praxis bewährte Methodik, die den Prinzipien des bekannten Compilerbaus folgt.

Laden Sie das Whitepaper Migrationsmethode (PDF) herunter.

Einführung

Bei der Beurteilung der Möglichkeit, eine Workflow-Implementierung von einem Quellsystem nach BICsuite zu migrieren, ist es ein weit verbreiteter Irrglaube zu glauben, dass der Aufwand von der Anzahl der Objekte im Quellsystem abhängt. Natürlich klingt es plausibel anzunehmen, dass bei einer Million Objekten im Quellsystem der Migrationsaufwand höher ist als bei nur zehntausend Objekten im Quellsystem. Und ja, bis zu einem gewissen Grad stimmt das auch. In einem großen Quellsystem ist die Wahrscheinlichkeit von unsoliden Lösungen höher. Es wird auch schwieriger sein, die Ergebnisse einer Migration zu testen. Ein sehr wichtiger Aspekt ist das Vorhandensein von Abhängigkeitszyklen, die in einem großen System viel schwieriger zu lösen sind als in einem kleinen System. Dennoch wächst der erforderliche Aufwand sicherlich nicht linear. Es handelt sich eher um eine logarithmische Skala.

Um dies zu verstehen, muss man sich vergegenwärtigen, dass zwar die Zahl der Objekte wächst, nicht aber die Zahl der Speziallösungen, oder zumindest in weit geringerem Maße. Da die grundlegende Strategie während der Migration darin besteht, ein System zu entwickeln, das die Migration automatisiert, kann das gesamte Projekt mit dem Schreiben eines Compilers oder eines Interpreters verglichen werden. Ein Compiler für sehr kleine Programme wie das berühmte "hello world" wäre sehr einfach zu schreiben. Wenn die Programme größer werden, werden mehr syntaktische Konstrukte verwendet, was wiederum einen komplexeren Compiler erfordert. Große Systeme können sogar zusätzliche Funktionen wie die Code-Optimierung erfordern, was die Komplexität des Compilers ebenfalls erhöht. Der Code des Compilers wird immer noch deutlich weniger wachsen als die Größe der Softwaresysteme, die er kompilieren kann.

Der Unterschied zwischen einer Migration und der Erstellung von Compiler-Software besteht darin, dass der Input nicht genau bekannt ist. Im Falle eines Compilers gibt es eine formale Beschreibung der Syntax der Programmiersprache. Im Falle von Systemen zur Automatisierung der Arbeitsbelastung gibt es keine vergleichbare starre Beschreibung der Daten, die als Eingabe für eine Migration verwendet werden können, oder sie ist zumindest schwer zu finden.

Skizze des Migrationsverfahrens

Es wird davon ausgegangen, dass das Quellsystem über die Möglichkeit verfügt, eine Art Export der Definitionsschicht zu erstellen. Die Definitionsschicht enthält alle Daten, die das implementierte System beschreiben. Im Wesentlichen beschreibt sie, welche Jobs zu welcher Zeit laufen, welche Abhängigkeiten zwischen den Jobs bestehen und vieles mehr. Die Migration ist ein iterativer Prozess, der wie folgt aussieht:

1. Exportieren und Laden

Der Export wird in eine relationale Datenbank geladen. Die Schemadefinition wird aus den Daten selbst abgeleitet, muss aber nicht 100%ig genau sein, solange die Struktur der Daten erhalten bleibt.

2. Analyse

Der nächste Schritt besteht darin, die resultierende Datenbank zu analysieren und eine Art Dokumentation der verwendeten Tabellen und Spalten zu erstellen. Es ist wichtig, die Primärschlüssel und natürlich auch die entsprechenden Fremdschlüssel zu finden.

3. Grafische Darstellung

Die Daten in der Datenbank werden dann (teilweise) in eine Zwischendatenstruktur geladen. Es hat sich als nützlich erwiesen, eine Art Graphdarstellung der Datenbank zu verwenden. Es ist nicht notwendig, alles auf einmal zu laden, sondern es werden zunächst nur die wichtigsten Strukturinformationen wie die Aufträge und Abhängigkeiten geladen. In weiteren Schritten werden diese Informationen mit weiteren Details aus der ursprünglichen Datenbasis verfeinert.

4. Code-Generierung

Der BICsuite-Quellcode wird aus der Zwischendarstellung generiert und in ein BICsuite-System geladen. Während der Codegenerierung ist es möglich, dass Fehler in der Eingabe, also dem Quellsystem, aufgedeckt werden. In diesem Fall müssen sie innerhalb des Quellsystems behoben werden (ohne die Semantik zu verändern), und der Prozess wird mit einem neuen Export neu gestartet. Natürlich muss der Analyseschritt nicht wiederholt werden. Verglichen mit der Analogie der Erstellung eines Compilers würde dies der Situation von Syntaxfehlern im zu kompilierenden Code entsprechen.

5. Manuelle Anpassungen

Manchmal müssen seltene komplexe Situationen oder Ausnahmen manuell migriert werden, weil die Abdeckung innerhalb der generischen Engine eine sehr komplexe, schwer zu implementierende Logik erfordern würde. Für diese Situationen ist jeweils ein eigenes Skript erforderlich.

6. Test

Das bis dahin migrierte System wird nun getestet. Im Falle von Fehlern wird die Codegenerierung und/oder der Schritt der manuellen Korrektur verfeinert und wiederholt. Wenn alles wie erwartet funktioniert, werden weitere Details aus der ursprünglichen Datenbank berücksichtigt. Es sei denn, es gibt keine weiteren Details zu berücksichtigen, dann ist die Migration abgeschlossen und das Verfahren kehrt zu Schritt 3 zurück. Manchmal stellt sich heraus, dass das ursprüngliche Verständnis der Daten nicht korrekt ist; in diesem Fall kehrt das Verfahren zu Schritt 2 zurück. Es ist auch möglich, dass strukturelle Fehler wie zyklische Abhängigkeiten gefunden werden. In diesem Fall muss die Eingabe, d. h. das Ausgangssystem, geändert werden (unter Beibehaltung der Semantik), um die Fehler zu beseitigen. Der Prozess beginnt dann wieder mit einem neuen Export.

Die folgende Abbildung zeigt eine grafische Darstellung des Prozesses:

Der Migrationsprozess

Harte und weiche Anforderungen

Die offensichtliche harte Anforderung besteht darin, dass sich das System nach der Migration genau so verhalten muss wie das System vor der Migration. Das heißt, dass beide Systeme bei gleicher Eingabe die gleiche Ausgabe produzieren müssen. Dieses Kriterium wird in der Testphase des Workflows geprüft. Etwaige Abweichungen müssen analysiert und beseitigt werden. Es gibt aber auch eine Reihe von weichen Anforderungen. Das Betriebsteam muss in der Lage sein, mit dem neuen System zu arbeiten. Das Entwicklungsteam muss in der Lage sein, das System zu ändern oder zu erweitern. Und vielleicht muss ein Überwachungsteam in der Lage sein, den Fortschritt bei der täglichen Bearbeitung zu interpretieren.

Auch wenn dies durch Schulungen abgedeckt werden kann, ist es dennoch wünschenswert, dass die alten Arbeitsabläufe intakt bleiben. Jede Änderung der Arbeitsabläufe erhöht das Risiko, Fehler zu machen.

Ein weiterer Aspekt ist die Verwendung einer strengen Namenskonvention, so dass Objekte im migrierten System leicht auf das Ursprungsobjekt im Quellsystem abgebildet werden können. Dies wird sowohl das Verständnis als auch die Akzeptanz des migrierten Systems erheblich verbessern.

Da eine 1:1-Kopie des Quellsystems in der Regel nicht erreicht werden kann, werden diese Anforderungen als weiche Anforderungen bezeichnet. Es wird ein "So viel wie möglich"-Ansatz sein. Andererseits ist es nicht verboten, Arbeitsabläufe zu modifizieren, wenn dies zu weniger oder leichterer Arbeit führt und es dadurch schwieriger wird, Fehler zu machen.

Unterm Strich wird es also keinen richtigen oder falschen Weg geben. In vielen Fällen werden Entscheidungen im Dialog mit den Nutzern des Systems getroffen werden müssen. Es ist gut möglich, dass mehrere verschiedene Darstellungen getestet werden müssen, um die Darstellung zu finden, die den Benutzern am besten gefällt.

Exportieren & Laden

Das Ergebnis eines Exports des Quellsystems ist extrem abhängig vom Quellsystem selbst und kann sich sogar zwischen verschiedenen Versionen desselben Quellsystems erheblich unterscheiden. Ein Control-M wird ein völlig anderes Format erzeugen als ein Autosys, ein CA Workload oder ein Automic. Manchmal liegt ein Export in Form eines XML-Dokuments vor, manchmal besteht er aus einer Liste von Anweisungen, die im Ausgangssystem ausgeführt werden können, oder es handelt sich um eine Reihe von CSV-Dateien. Es ist sogar möglich, dass das Quellsystem keine Möglichkeit zum Export bietet, sondern seine Daten in einer Datenbank oder an einem genau definierten Ort im Dateisystem speichert.

Einige der Exportformate sind einfach zu verarbeiten (XML- oder CSV-Format sowie in einer Datenbank gespeicherte Daten), während andere Tools erfordern, um die Informationen aus dem Export zu extrahieren (Anweisungen, Rohdaten).

Theoretisch wäre es möglich, Bibliotheken zu entwickeln, die einen willkürlichen Zugriff auf die exportierten Informationen ermöglichen, aber das wäre eine komplexe Aufgabe und der Zugriff wäre nicht sehr leistungsfähig. Die bessere Idee ist, Werkzeuge zu entwickeln, die die Informationen extrahieren und in eine relationale Datenbank laden. Der Zugriff auf die Daten erfolgt dann über Standard-SQL, das eine einfach zu bedienende Schnittstelle bietet. Ein weiterer Vorteil dieses Ansatzes ist, dass das Datenwörterbuch des verwendeten Datenbanksystems eine komprimierte Liste von Datenelementen enthält.

Analyse

Genau diese Liste von Datenelementen wird im nächsten Schritt analysiert. Einige Elemente werden eine offensichtliche Bedeutung haben, während andere Elemente möglicherweise weitere Untersuchungen erfordern. Diese Analyse kann nicht ohne die Hilfe eines erfahrenen Anwenders des Systems durchgeführt werden. Zugleich ist diese Liste von Datenelementen im Grunde eine TO-DO-Liste. Wenn jedes Datenelement in der Liste in den nachfolgenden Schritten korrekt behandelt wird, muss das Ergebnis korrekt sein. Dies beweist auch, dass die Migration ein endlicher Prozess ist, dessen Dauer weitgehend von der Komplexität des Ausgangssystems abhängt.

Selbst mit dem Input eines erfahrenen Anwenders des Ausgangssystems werden Fehler gemacht werden. Aus diesem Grund ist der Analyseschritt Teil des iterativen Prozesses.

Grafische Darstellung

Aufgrund der Natur des Problems kann jede Implementierung eines Systems in einem Workload-Automatisierungstool als Graph dargestellt werden, in dem die Knoten Jobs oder ganzen Sets von Jobs (vielleicht sogar Sets von Sets) entsprechen und die Kanten den Vorgänger-Nachfolger-Beziehungen zwischen den Knoten entsprechen.

In BICsuite wird die Vorgänger-Nachfolger-Beziehung als Abhängigkeit bezeichnet, wobei der Nachfolger voraussetzt, dass der Vorgänger mit einem bestimmten Exit-Status beendet wurde. Ein Job (Definition) ist ein Objekt, das eine Befehlszeile ausführt, während ein Batch eine Art Container für Jobs und/oder andere Batches ist. Andere Workload-Automatisierungstools haben ähnliche Konzepte, die sich nur im Detail unterscheiden.

Die Hierarchie der Batches und Jobs ist ebenfalls ein Graph, genauer gesagt ein Baum. Das bedeutet, dass es in dem gesamten Graphen zwei Arten von Kanten gibt. Der erste Typ ist die Abhängigkeit und der zweite Typ ist die Eltern-Kind-Beziehung.

Der Graph ohne die Abhängigkeiten ist immer ein Wald (eine Ansammlung von Bäumen). Die Kanten sind von den Eltern zu den Kindern gerichtet. Es gibt keine Zyklen (sonst wäre es keine Sammlung von Bäumen). Der Graph ohne die Eltern-Kind-Beziehungen sieht wie ein Netzwerk aus. Auch hier sind die Kanten vom Vorgänger zum Nachfolger gerichtet.

Die Eltern-Kind-Hierarchie beeinflusst den Abhängigkeitsgraphen. Abhängigkeiten auf der Ebene der Eltern werden implizit auf die Ebene der Kinder vererbt. Dies lässt sich sehr schön anhand des (nicht planaren) Utility-Graphen veranschaulichen. Drei Vorgängeraufträge P1, P2 und P3 werden alle von drei Nachfolgeraufträgen S1, S2 und S3 benötigt:

Bei Verwendung der impliziten Abhängigkeiten, die sich aus den Abhängigkeiten auf der übergeordneten Ebene ergeben, sieht das Bild viel besser aus:

Es ist auf einen Blick zu erkennen, dass die Jobs S1, S2 und S3 auf die Fertigstellung der Jobs P1, P2 und P3 warten. Im ersten Diagramm ist dies nicht so deutlich. Die Eltern-Kind-Hierarchie macht es also einfacher, komplexe Beziehungen zu verstehen (und zu definieren). Der Nachteil ist, dass die Zyklen nicht so leicht zu erkennen sind. Ein Pfeil, der von S1 nach P3 zeigt, sieht im zweiten Bild ziemlich harmlos aus. Tatsächlich aber erzeugt er einen Zyklus, was sofort deutlich wird, wenn wir denselben Pfeil im ersten Bild einzeichnen.

Dennoch überwiegen die Vorteile einer Eltern-Kind-Hierarchie die Nachteile deutlich. Das ist wahrscheinlich ein Grund, warum alle Tools zur Automatisierung der Arbeitsbelastung sie auf die eine oder andere Weise anbieten.

Der implizite Abhängigkeitsgraph sollte azyklisch sein, da sonst ein Deadlock die Folge wäre. Wenn A auf B wartet und umgekehrt, wird nicht viel passieren. Die Definition der impliziten Abhängigkeiten ermöglicht die Umwandlung des gemischten Graphen mit den beiden Arten von Kanten in einen eindeutigen alleinigen Abhängigkeitsgraphen. Die Graphenbibliothek kann dann verwendet werden, um Zyklen zu finden.

Wenn Zyklen gefunden werden, müssen sie analysiert und beseitigt werden. Letztendlich ist die Automatisierung der Arbeitslast das Ziel, und ein Zyklus erlaubt es nicht, die Anwendung laufen zu lassen, ohne in eine Sackgasse zu geraten, die dann manuell gelöst werden muss. Nehmen wir an, dass ein Zyklus wie in der Abbildung unten gefunden wurde:

Ein möglicher Grund für diesen Graphen ist, dass A in der Tat auf ein E vom Vortag wartet. In diesem Fall ist es wahrscheinlich, dass A die Ergebnisse von E nicht wirklich benötigt, aber es ist einfach unerwünscht, dass die tägliche Verarbeitung beginnt, bevor die Verarbeitung des Vortages abgeschlossen ist (oder zumindest ein bestimmter Meilenstein innerhalb der Verarbeitung erreicht wurde). Eine solche Bedingung wird in der BICsuite anders modelliert. Eine Ressource kann verwendet werden, um zu signalisieren, dass der Lauf des Vortages noch nicht beendet ist. Auf diese Weise verliert die Abhängigkeit zwischen A und E ihre Bedeutung und kann eliminiert werden. Ein azyklischer Graph ist das Ergebnis.

Es kommt auch vor, dass eine solche Definition im Quellsystem nie in einer Sackgasse endet, weil mindestens einer der Jobs nicht jeden Tag ausgeführt wird. Damit ist das Problem im Quellsystem zwar gelöst, aber es bleibt ein bitterer Beigeschmack. Die Bedeutung der Abhängigkeiten ist unzureichend definiert.

Wenn A am ersten Tag fehlt, dann haben wir eine transitive Abhängigkeit von B zu E, und E ist ein Nachfolger von B. Wenn C am nächsten Tag fehlt, dann haben wir eine transitive Abhängigkeit von E zu B. Es ist schwer zu glauben, dass dies logisch korrekt ist. An einem Tag brauchen wir Daten, um einen Bericht zu erstellen, und am nächsten Tag erstellen wir den Bericht, um die zugrundeliegenden Daten erzeugen zu können?

In vielen Fällen definieren diese Vorgänger-Nachfolger-Definitionen keine Abhängigkeiten, sondern werden (willkürlich) hinzugefügt, um eine gleichzeitige Ausführung zu verhindern oder eine bevorzugte Reihenfolge der Ausführung zu definieren. Und auch hier bietet BICsuite eine andere Methode, wiederum ressourcenbasiert, um eine gleichzeitige Ausführung zu verhindern. Falls nötig, können Prioritäten verwendet werden, um das System eine bevorzugte Reihenfolge der Ausführung anstreben zu lassen.

Die Verwendung von Abhängigkeiten, um eine bevorzugte Ausführungsreihenfolge zu definieren, verschlechtert die Gesamtleistung. Wenn B auf die Fertigstellung von A warten muss, weil es bevorzugt wird, dass A zuerst ausgeführt wird, könnte B anfangen, auf A zu warten, noch lange bevor A überhaupt ausgeführt werden darf. B könnte während der Zeit, in der A noch auf seine Vorgänger wartet, ausgeführt werden. Durch die Verwendung von Prioritäten wird die bevorzugte Reihenfolge dokumentiert, und das System wird entsprechend handeln, wenn sowohl A als auch B bereit sind, ausgeführt zu werden, aber es würde B nicht warten lassen, wenn A noch nicht bereit ist.

Eine Graphenbibliothek wie die weit verbreitete Python-Bibliothek NetworkX bietet ein umfangreiches und leistungsstarkes Toolset. Vor allem, wenn die Graphen sehr groß werden, ist es wichtig, leistungsfähige und gleichzeitig korrekte Werkzeuge verwenden zu können. Eine große Anzahl von vordefinierten, mathematisch geprüften Algorithmen steht zur Verfügung. Besonders wenn Probleme wie Zyklen auftauchen, können solche Algorithmen effektiv zur Untersuchung der Graphen eingesetzt werden.

Es ist wichtig zu beachten, dass die NetworkX-Bibliothek in der Lage ist, beliebige Datenstrukturen als Eigenschaften von Knoten und Kanten zu speichern. Das bedeutet, dass alle im Export gefundenen Informationen innerhalb der Graphendarstellung der Daten gespeichert werden können.

Code-Generierung

Aus der Graphdarstellung lassen sich leicht Anweisungen generieren, die die entsprechenden Objekte in BICsuite erzeugen. Da jedes Objekt innerhalb von BICsuite mit Hilfe der Kommandosprache erstellt und/oder modifiziert werden kann, ist es möglich, jede Funktion des Systems anzusprechen.

Die verbleibende Aufgabe besteht also darin, eine Übersetzung der Quelldaten in eine Repräsentation innerhalb von BICsuite zu finden, die die gleiche Semantik wie im Originalsystem aufweist. Frühere Migrationsprojekte haben gezeigt, dass es immer möglich war, eine solche Übersetzung zu finden. In vielen Fällen gab es sogar mehrere Alternativen.

Die Kriterien für die Auswahl einer bestimmten Implementierung waren durch die weichen Anforderungen vorgegeben. In einigen Fällen wurden einige der Alternativen durch Implementierung und Tests bewertet.

Aufgrund der Unterschiede in den Quellsystemen und den weichen Anforderungen ist der Schritt der Codegenerierung für jedes Projekt spezifisch. Obwohl Teile der Codegeneratoren früherer Projekte verwendet werden konnten, ist es oft aufwendiger, den projektspezifischen Code zu entfernen, als ganz neu zu beginnen. Die Implementierung des Grundgerüsts (Erstellen von Aufträgen und Abhängigkeiten) kostet weniger als einen Tag. Der Vorteil eines Neubeginns ist, dass es keine unerwünschten Nebeneffekte gibt.

Wenn eine ganze Reihe ähnlicher Systeme migriert werden muss (z. B. ein Entwicklungssystem, ein Testsystem und ein Produktionssystem), ist es natürlich sinnvoll, den Generator wiederzuverwenden. Aber in diesem Fall werden sowohl das Quellsystem als auch die weichen Anforderungen entweder gleich oder zumindest sehr ähnlich sein. Am besten fängt man mit dem einfachsten System an, in diesem Beispiel wahrscheinlich das Entwicklungssystem, und migriert den Rest in der Reihenfolge der Komplexität. Die Codegenerierung erfolgt dann auf demselben Weg. Der Basisgenerator, der für die Migration des Anfangssystems verwendet wird, wird dann schrittweise verfeinert, um die Anforderungen der nachfolgenden Systeme abzudecken.

Manuelle Anpassungen

Es gibt keine Regel ohne Ausnahme. Wenn der Codegenerator das Werkzeug der Wahl ist, um das regelbasierte Mapping vom Quellsystem auf BICsuite zu implementieren, wird es nicht sinnvoll sein, die Behandlung jedes Sonderfalls ebenfalls zu implementieren. Oft ist es schneller und einfacher, ein Stück Code zu erstellen, das die Ausnahmen nach der Codegenerierung behandelt, als dies in den Generator zu integrieren.

Auch hier drängt sich der Vergleich mit einem Compiler auf. Der Kompiliervorgang wird oft in mehreren separaten Schritten durchgeführt. Zunächst wird die Eingabe geparst und auf Syntaxfehler geprüft. Das Ergebnis dieses Schrittes ist ein Parse-Baum. Im nächsten Schritt wird ein Zwischencode erzeugt, der von der Zielhardwarearchitektur unabhängig ist. Dieser Zwischencode wird dann in Maschinencode für die Zielarchitektur übersetzt. Zu guter Letzt wird dieser Maschinencode optimiert, um die bestmögliche Leistung zu gewährleisten.

Vergleicht man diesen Ansatz in der Compilertechnik mit dem Migrationsverfahren, so fallen die Parallelen ins Auge:

Compiler	Migration
Parser	Exportieren und Laden
Zwischenzeitlicher Code	Graphische Darstellung
Maschineller Code	Generator
Optimierter Code	Manuelle Anpassungen

Wenn sich herausstellt, dass einige der manuellen Anpassungen generischen Regeln folgen, ist es sinnvoll, sie in den Generatorcode zu integrieren. Dies ist besonders vorteilhaft, wenn mehrere ähnliche Systeme migriert werden. Je mehr Code generiert wird, desto weniger fehleranfällig wird die Migration sein. Der große Vorteil von generiertem Code ist, dass er entweder immer richtig oder immer falsch ist. Ersteres ist in Ordnung, aber wichtiger ist, dass Letzteres leichter zu erkennen ist.

Test

Wenn die ausgeführten Befehlszeilen und die Reihenfolge der Ausführung gleich sind, kann man davon ausgehen, dass bei gleicher Eingabe auch die Ausgabe gleich sein muss. Da die von den Jobs ausgeführten Befehlszeilen innerhalb des Prozesses kopiert werden, ist die erste Bedingung erfüllt. Beim Testen ist also nur zu zeigen, dass die Ausführungsreihenfolge in beiden Systemen gleich ist.

Es muss natürlich auch gezeigt werden, dass keine Jobs ausgelassen und keine zusätzlichen Jobs ausgeführt werden. Außerdem ist die Ausführungsreihenfolge wegen der parallelen Ausführung von Aufträgen nicht 100%ig strikt. Die folgende Abbildung veranschaulicht diese Behauptung.

Die Reihenfolge der Ausführung im Quellsystem ist J1-2, J1-1, J2-2, J2-1, J3-2, J3-1, J4-2, J4-1, während die Reihenfolge der Ausführung im migrierten System J1-1, J1-2, J2-1, J2-2, J3-1, J3-2, J4-1, J4-2 ist.

Dennoch sollten beide Ausführungsreihenfolgen als gleich angesehen werden, da jede Kette in der gleichen, korrekten Reihenfolge ausgeführt wird. Wenn es Abhängigkeiten zwischen den Aufträgen in beiden Ketten gäbe, müssten diese Abhängigkeiten im Quellsystem modelliert worden sein und wären dann auch Teil des migrierten Systems. Tatsächlich könnten solche Unterschiede entstehen, wenn zwei Läufe innerhalb des Quellsystems miteinander verglichen werden. Zu viele unkontrollierbare Faktoren wie die Prozessplanung des Betriebssystems, die gleichzeitige Verarbeitung, der Netzwerkdurchsatz und die Latenzzeit spielen eine Rolle für den genauen Zeitpunkt der Prozessstarts und deren Dauer.

Der größte Teil der Tests muss die "echten" Befehlszeilen gar nicht ausführen. In vielen Fällen genügen Dummy-Programme, die nur eine Zeit lang schlafen oder einfach einen Erfolg zurückgeben. Dies beschleunigt die Tests und ermöglicht es dem Migrationsteam, die Tests in einer Art simulierten Umgebung durchzuführen, z. B. auf dem Computer des Generatorentwicklers.

Erst wenn alle Funktionen implementiert wurden und alle anderen Tests zufriedenstellend sind, müssen einige echte Tests in einer ernsthaften Testumgebung durchgeführt werden. Wenn diese Tests erfolgreich verlaufen, kann das Go-Live geplant werden.

Zeitplanung

Bei jeder Migration ist die Zeitplanung ()welcher Job wann laufen soll) ein Thema für sich. Das Zeitplanungsmodul von BICsuite ist extrem leistungsfähig und unterstützt stark regelbasiertes Scheduling.

Anstatt eine Liste von Ausführungsdaten (und -zeiten) auf jährlicher Basis zu erstellen, ist es viel besser, eine allgemeine Regel zu erstellen. Wenn die Gehälter der Mitarbeiter am vorletzten Arbeitstag des Monats überwiesen werden, ist es natürlich eine Option, herauszufinden, welche Tage das sind, und eine Liste davon zu erstellen. Aber BICsuite erlaubt es dem Benutzer, eine Regel zu erstellen, die genau das tut. Die einzige Arbeit, die BICsuite noch macht, ist, jedes Jahr eine neue Liste von Feiertagen zu erstellen. Anhand dieser Liste der Feiertage und der Wochenenden kann BICsuite berechnen, welcher Tag der vorletzte Arbeitstag des Monats ist.

Die Möglichkeiten des Zeitplanungsmoduls sind natürlich nicht darauf beschränkt. Selbst scheinbar harte Anforderungen wie der 10. Tag des Monats, sofern es sich nicht um ein Wochenende oder einen Feiertag handelt, der dann der nächste Arbeitstag sein muss, stellen für das System keine Herausforderung dar. Gleichzeitig erlaubt das System dem Benutzer, die allgemeine Regel außer Kraft zu setzen, ohne die Regel selbst zu beeinflussen.

Der Vorteil dieses Ansatzes ist, dass er praktisch wartungsfrei ist. Die manuelle Erstellung von Listen mit Ausführungsdaten ist ziemlich fehleranfällig. Abgesehen davon, dass es eine Menge Arbeit ist, es richtig hinzubekommen, kann auch die tiefere Logik hinter den Listen verloren gehen.

Aber genau wie die Liste der Feiertage kann auch jede andere Liste von Terminen (und Zeiten) erstellt werden. Der Benutzer hat also die Möglichkeit, entweder das alte System mit Datumslisten zu verwenden oder zu einem eher regelbasierten Ansatz überzugehen. Welche Option die beste ist, hängt von den weichen Anforderungen ab.

Unabhängig davon, welche Option gewählt wird, wird dieser Teil der Migration in der Regel als separater Schritt durchgeführt. Im Grunde geht es um die Trennung dessen, was zu tun ist und wann es getan wird. Diese Trennung führt zu zwei Perspektiven der Workload-Automatisierung. Eine Gruppe von Systemen ist daran interessiert, was wann zu tun ist, und die anderen Systeme sind daran interessiert, wann sie was tun sollen. Mit anderen Worten, die einen sind zeitorientiert und die anderen aufgabenorientiert. Diese Verschiebung der Perspektive führt oft zu Unverständnis oder zumindest zu Verwirrung.

Dienstprogramme

Um einen größeren Teil der weichen Anforderungen abzudecken, ist es oft notwendig, Hilfsprogramme zu entwickeln. Die Gründe dafür können von der Vereinfachung von Bedieneraktionen über die Nachahmung alter Arbeitsabläufe bis hin zum Hinzufügen von Nicht-Standard-Funktionalität (Nicht-Standard in dem Sinne, dass sie nicht Teil des BICsuite-Systems ist) reichen.

Da BICsuite über eine leistungsfähige und einfach zu bedienende API verfügt, ist es in der Regel kein wirklicher Aufwand, leistungsfähige Tools zu erstellen, die die Leute glücklich machen. In vielen Fällen ist die genaue Spezifikation des Tools der schwierige Teil, und die anschließende Implementierung ist oft sehr einfach.

Bildung

Die Schulung der Teammitglieder ist aus zwei Gründen wichtig. Der erste Grund ist offensichtlich. Da sie planen, in Zukunft mit dem neuen System zu arbeiten, müssen sie wissen, wie sie damit arbeiten können. Obwohl BICsuite nicht schwer zu bedienen ist, hat es viele Konzepte, die sich von den Konzepten des Ausgangssystems unterscheiden. Es wird wichtig sein, die neuen Konzepte zu verstehen.

Der zweite Grund für die Ausbildung hängt mit dem Migrationsprozess selbst zusammen. Ein großer Teil der Kommunikation zwischen den Benutzern und dem Migrationsteam ist für den Erfolg des Projekts entscheidend. In vielen Fällen müssen Lösungen, die eine Funktionalität im Quellsystem auf eine Implementierung in BICsuite abbilden, diskutiert werden. Dies ist viel einfacher, wenn die BICsuite-Terminologie (zumindest) verstanden wird.

Vor allem der zweite Grund zeigt, dass das Projekt mit der Ausbildung beginnen muss. Gleichzeitig können sich die Benutzer während der Migration Know-how im Umgang mit dem System aneignen, so dass sie zum Zeitpunkt des Go-Live bereits über die nötigen Kenntnisse verfügen.

Schlussfolgerung

Das vorliegende Dokument beschreibt eine in der Praxis bewährte Methodik, die sich an den Prinzipien des bekannten Compilerbaus orientiert. Es zeigt auch, dass der Aufwand vor allem durch die Komplexität des Quellsystems und der verwendeten Workflows bestimmt wird und nicht durch die Größe der implementierten Anwendung.

Die Liste der Eingabedaten garantiert die zeitliche und finanzielle Begrenztheit des Prozesses und gibt Aufschluss über den erzielten Fortschritt. Der iterative Charakter des Prozesses ermöglicht es, die Korrektheit jeder Verfeinerung zu beweisen, was letztlich die Korrektheit des Ganzen garantiert.

Ein großer Teil der Migration, einschließlich der Tests, kann auf einem einzigen isolierten Rechner durchgeführt werden. Ein anspruchsvolleres Setup ist nur für die Praxistests erforderlich. Die Risiken für das Projekt sind daher begrenzt und ein Abbruch des Projekts, aus welchen Gründen auch immer, bleibt immer eine Option.

Da die gesamte Migration als automatisierter Prozess durchgeführt wird, sind gleichzeitige Änderungen am Quellsystem jederzeit möglich. Es wird jedoch sinnvoll sein, das Quellsystem zwischen dem letzten erfolgreichen Praxistest und dem Go-Live des migrierten Systems einzufrieren.

BICsuite Highlights

Mehr erfahren

Stöbern Sie in unserer wachsenden Sammlung von Artikeln, Erklärvideos und Tutorials, um praktische Einblicke und Best Practices für die Workload-Automatisierung mit schedulix und BICsuite zu entdecken.

Mehr erfahren

Haben Sie noch Fragen?

Bitte zögern Sie nicht, sich mit uns in Verbindung zu setzen, wenn Sie irgendwelche Fragen haben oder weitere Informationen benötigen. Unser Team steht Ihnen gerne zur Verfügung.

Kontaktieren Sie uns

↑ Nach oben