Den nächsten Abschnitt widmen wir dem der Frage inkrementelles Vorgehen.
Das ist ja etwas, was Sie schon überall kennen, überall hergehört haben.
Und ich möchte es aber hier im Zusammenhang mit Migration
nochmal betonen, wie es aus dieser Gesichtspunkt aussieht.
Sie kennen Scrum, Sie kennen den Rechner Unified Process vielleicht ein bisschen.
Sie hören bei Herrn Gritzern im Vorlesungsteil etwas über Vorgehensmodelle.
Überall arbeiten wir inkrementell, das heißt in kleinen Schritten.
Das ist ein Vorgehen, was eine ganze Reihe von Vorteilen
hat, aber natürlich auch einen Preis.
Und darüber wollen wir sprechen. Und die Frage 5,
bezieht sich ja besonders auf die Risiken.
Sie sollten also in der Lage sein, zu erklären,
was sind die Vorteile, Nachteile,
was sind die Eigenschaften einer solchen inkrementellen Vorgehens.
Ich möchte mal betonen, dass ich hier vor allen Dingen
um Re-Engineering reingineeren behandeln möchte. Für Vorwärtsentwicklung,
für Entwicklung auf der grünen Wiese sozusagen, Greenfield Development Neudeutsch.
Gibt es noch weitere Vorteile? Aber hier möchte ich gegenüberstellen,
den inkrementellen Entwicklungsansatz und den Ansatz Big Bang,
das heißt mit einer großen Änderung
alles neu machen
Das ist der klassische Ansatz. Das hat,
den macht man vor allen Dingen dann, wenn man ganz viele Abhängigkeiten hat,
wenn man Teile hat, die viel zusammenhängen.
Und natürlich ist so ein Vorgehen alles Neumachen, alles umtauschen,
alles mit einem Schritt machen, hat auch etwas,
hat auch große Vorteile. Es ist komplett alles mit einmal
. Ja, also ich brauche nicht viele kleine Zwischenschritte.
Vielleicht stellen wir das erstmal gegenüber, worum es denn geht.
Big Bang und inkrementell. Dass das inkrementelle Arbeiten sieht ja so aus,
dass wir, wenn wir von einem Schritt 1 Zustand 1
Meins zu einem Zustand 2 kommen wollen oder sagen wir mal hier alt und hier neu,
dass wir nicht mit einem Schritt das machen.
Ja, das wäre, das wäre Big Bang,
sondern wir machen ganz viele Zwischenschritte.
Ja, und diese ganz vielen Zwischenschritte,
das ist das,
was wir jetzt als inkrementell besprechen
Diese kleinen Zwischenschritte führt man deswegen durch, insbesondere wegen des Risikos. Ja,
also das Risiko steht beim Re-Engineering im Vordergrund,
weil diese kleinen Schritte halt erlauben,
dass sich einen Schritt auch mal wieder zurück machen kann,
weil ich halt von dem einen Schritt zum vorhergehenden nicht so viele Veränderungen habe.
Natürlich können sie auschecken, einchecken, aber vergessen sie mal
nicht, das ist nicht nur um den Quellcode geht.
Es geht immer auch darum, dass wir Datenbestände haben, die wir mitnehmen müssen. Ja,
dass wir andere Nachbarsysteme haben, dass wir Adapter brauchen,
zu den Adaptern kommt es später noch mehr,
aber vielleicht schon einfach nur so Übergangslösungen, Brücken zwischen dem alten Teil,
die alten Teile ringsherum mit dem einen, dass wir verändert haben.
Also jedes Teil braucht wieder Brücken zu den ganzen anderen Teilen. Und wenn wir uns vorstellen,
dass jedes, dass wir ein System haben,
was sehr komplex miteinander Zusammenhänge hat zwischen den Teilen,
dann brauchen wir zwischen jedem Teil, was wir austauschen,
vielleicht fünf bis sieben Übergangslösungen zu Nachbarteilen, die noch die alte Schnittstelle anbieten.
So, also das heißt, wir haben die Möglichkeit,
leichter zurückzugehen, wenn wir nicht so viele Transformationen gemacht haben
Insbesondere dann, wenn wir merken, etwas funktioniert nicht,
wie vorhergesehen. Und das ist ja normal,
weil wir bei einem Re-Engineering-System, bei einem System,
was schon älter ist, wo wir nicht die komplette Dokumentation haben,
wo wir nicht das komplette Wissen haben,
da gibt es immer Überraschungen.
Wir können nicht wissen, was nach jedem Schritt passiert.
Und wenn wir also rückkehren können, ist das Risiko deutlich geringer.
Das Gleiche trifft zu zu, dem für die Möglichkeit,
Nacharbeiten zu machen. Wenn wir feststellen,
die eine Schnittstelle passt zwar von den Datentypen,
aber die Initialisierung läuft doch in Wirklichkeit ganz anders,
dann können wir
diese kleine Änderung doch erkennen
Leichter erkennen, weil es wir haben nicht so viel geändert.
Und wir führen das dann nochmal durch. Das Gleiche mit
den kleinen Änderungen hatten wir für Reflektorinnen ja auch schon besprochen.
Da waren das letztlich die gleichen Punkte, dass wir die
kleinen Schritte leichter rückgängig machen können, dass wir leichter nachtunen können.
Und dieses Nachtunen, manche sagen auch dazu, optimieren,
das war mir ein bisschen zu abgehoben. Wir möchten,
wir haben festgestellt, wir wollen die Schnittstelle so und so verändern.
Das ist ein kleiner Schritt. Und dann merken wir,
oh, die Veränderung, das passt dort und dort nicht.
Dann machen wir den nächsten Schritt ein bisschen anders als vorher geplant.
Wir haben die Möglichkeit, die in jeweiligen Folgeschritt anzupassen auf
das, was wir in dem Moment haben
Wenn wir Big Bang machen, also einen großen Schritt von allzu neu,
gibt es meistens keinen Möglichkeit des kompletten Rückwegs.
Vor vielen Jahren schon mal hat ein Kollege von mir
in einem Projekt gearbeitet, als für einen Paketdienstleister,
den es heute nicht mehr gibt, genau aus diesem Grund.
Für diesen Paketdienstleister sollte es eine Umstellung des Systems geben.
Man wollte das System umstellen von alten Telefonleitungen,
von einem Modem basierten System auf ein Internet basiertes System.
Ja, früher waren also jede, sie können sich vorstellen,
bei so einem Logistikdienstleister gibt es Die Fahrzeuge haben etwas,
damals gab es noch nicht ein Handheld für jeden Fahrer,
sondern der hat Listen abgearbeitet.
Also es ist schon eine ganze Weile her,
aber jedes Depot hat Sortierstationen, die Repos haben,
eine Bestandsnachnachführung in dem Depots, ist bekannt, welche Sendung geht wohin.
Und es muss eine Übergabe passieren, eine Ankündigung,
der Fahrer bringt jetzt so und so viele Kisten für dort,
für dort, für dort mit, damit das schon vorbereitet werden kann.
Und für jedes Paket, für jede Sendung muss letztlich auch klar sein,
wo ist sie gerade, wo geht sie als nächstes hin,
Was ist der Standard, mit der Kunde das erfahren kann?
Also insgesamt ein komplexes System, einfach teilt das System mit vielen Standorten.
Und man wollte dieses System ablösen. So,
man hat hier den Big Bang-Ansatz gewählt, ich bang deswegen,
ja, es ist auf den ersten Blick, ist das auch überzeugend gewesen.
Die Manager haben sich das sicherlich gut ausgedacht,
weil man muss die ganze Telefoninfrastruktur, die Kommunikationsinfrastruktur, die Hardware umtauschen.
Also die von der Telefonleitung weg, die Leitungen wurden benötigt
für Netzwerkverbindungen. Das heißt, man hat über ein Wochenende
hinweg zunächst die Leitungen ausgetauscht oder die Leitungen,
besonders auch die Endstellen der Leitungen
Diese elektrischen Geräte letztlich geht es um elektrische Verbindungen, die die Signale übertragen.
Von den Telefonverbindungen auf Netzwerkverbindungen umgewechselt. Dann die Netzwerkgeräte installiert,
die Rechner installiert und auf den Rechnern lief dann die neue Software.
Hat zur Folge, dass es keinen Rückweg gibt.
Also das, was wir hier machen können,
diese Möglichkeit gab es nicht. Wenn man also dann,
sagen wir mal, Freitag um 16 Uhr anfängt und möchte Sonntagabend
16 Uhr fertig sein und noch ein bisschen Puffer zu haben,
damit es am Montag losgehen kann.
Und man stellt fest, das funktioniert nicht wie geplant,
dann kann man nicht
alles zurückbauen
Ja, so, das ist ein typischer Risiko von Big Bay.
Sie müssen nicht viel von Zuverlässigkeit wissen, um zu wissen,
dass eine Summe von vielen Fehlern anfälligen Teilen,
umso fehleranfälliger in der Gesamtwahrscheinlichkeit des Ausfalls ist,
je mehr Teile es sind.
Also wenn wir drei Teile haben,
dann wird die Fehlerwahrscheinlichkeit natürlich deutlich höher sein,
als wenn wir nur einen Teil haben, was wir mit dem gleichen Fehlerwahrscheinlichkeit.
Aber wenn wir 10.000 Teile haben,
dann steigt die Fehlerwahrscheinlichkeit insgesamt so stark an,
dass es eigentlich schon ziemlich sicher ist,
dass es
nicht funktionieren wird
Und genau das ist das Problem beim Big Bang, bei komplexen Systemen.
Es kann eigentlich nicht mehr funktionieren. Diese Kurve,
Anzahl der Teile versus Fehlerwahrscheinlichkeit, Gesamtausfallwahrscheinlichkeit ist nicht linear.
Das heißt, je mehr Teile wir haben,
desto steiler steigt die Kurve an und es gibt eine bestimmte Kurve,
einen bestimmten Anteil von Elementen ab, den kann es eigentlich nicht mehr funktionieren.
Deswegen ist dieser Big Bang-Ansatz kaum machbar. Dann hatten wir
deswegen versuchen, alle über kleine Zwischenschritte, das zu machen.
Das heißt, dass man zum Beispiel im Fall dieses Logistikdienstleisters
hätte man das vielleicht erstmal probiert.
Erstmal mit einem Standort. Das wäre zum Beispiel auch ein inkrementelles Vorgehen,
dass dieser eine Standort die neue Software bekommt,
den neuen Anschluss bekommt und dann steht man fest,
läuft überhaupt diese Hardware mal.
Läuft die Software mit der Zentrale. Aber da muss man natürlich
eine Brücke bauen. Eine Zwischenlösung zwischen der neuen Software und
der alten Zentrale, weil die Zentrale ist ja noch alt.
Und dann hätte man aber, weiß man, okay,
da macht man das für einen,
dann macht man es für zehn und dann macht man es vielleicht für tausend.
Das gleiche trifft zu auf Änderungen der Softwareänderung der Handhelds
und so weiter
Immer mit Zwischenlösungen, ja, diese Zwischenlösung können sein,
ich tausche aus Notel A aus und dann Teil B und dann Teil C. Es kann auch sein,
dass ich erst mal Station 1 austausche,
dann Station 2 bis 9 und deine Stationen,
was weiß ich, 10 bis 30 und dann erst den Rest.
Das wäre auch denkbar, um die Fehlerwahrscheinlichkeit zu verringern.
Ja, das inkrementelle Vorgehen hat auch noch einen weiteren Vorteil,
da wir nur kleine Schritte machen, kann auch der Schaden nicht so riesengroß sein.
Ja, also in dem Fall unserer Paketdepots,
wenn ein Depot nicht geht, dann könnte man das immer noch reparieren,
indem man dort drei Aushilfskräfte hinschickt, die dann die Pakete halt von Hand sortieren.
Das dauert zwar dann ein bisschen länger,
aber das Desaster insgesamt deutschlandweit ist nicht so groß,
in dem Fall ist es schiefgegangen, das System hat nicht funktioniert,
weil so und so viel,
es gab ganz viele Fehler, aber ganz unterschiedliche Fehler,
also bei ein paar hat einfach die Telekommunikation nicht funktioniert,
die elektrische Datenübertragung, sage ich mal,
weil es gab Fehler im Zusammenspiel der Software,
die auch nie in dieser Form getestet worden war und dass am Ende das Gesamtsystem überhaupt nicht spielen konnte.
Ja, also hier gab es den großen Schaden bei
inkrementellen Sachen wird es kleine Schweden geben
Aber es gibt ganz klar Nachteile. Diese Nachteile,
das steht hier unten, das müssen wir ganz klar,
dass wir viele Zwischenlösungen brauchen.
Zwischenlösungen nach jedem Schritt, den wir hier ändern,
brauchen wir Zwischenlösungen zu allzu der Umgebung,
die ja noch ist wie vorher.
Dann ist ein hoher
Planungs- und Vorbereitungsaufwand
Und aber das höchste, der höchste Aufwand ist durch diese vielen Zwischenlösungen.
Zwischenlösungen bedeutet ja nicht nur, ich baue einen Adapter,
sondern ich muss auch die Daten konvertieren.
Ich muss auch für Datenabgleich immer Zwischenlösungen bauen.
Und diese Zwischenlösung schmeiße ich nach dem schlimmsten Schritt weg.
Die sind wirklich verloren. Die brauche ich nur für das
Vorhandensein von Zwischenlösungen. Also ich brauche immer ganz viele Provisorien.
Ja, und das ist natürlich hier drüben der Vorteil.
Ich brauche all diese Zwischenlösungen nicht. Ich habe die Möglichkeit
gleich mit einem Mal alles neu zu machen und dann
hoffentlich funktioniert es
Ich kann kurz berichten, dass ich kürzlich einen Vortrag gehört
habe über diese Umstellung des Kernbankensystems der Schweizer Postbank.
Die Schweizer Postbank ist eine sehr große Bank in der Schweiz
mit sehr vielen Filialen, sehr vielen Zahlungsvorgängen.
Und man kann sagen, systemrelevant. Das durfte nicht schiefgehen,
aber durch die vielen Verknüpfungen sah man sich außerstande,
dass man diese ganz, so ganz viele Zwischenlösungen macht.
Die Verknüpfungen waren so viel gestaltig, dass man sich
außerstande gesehen hat zwischen Lösungen für alle Schritte zu machen.
Das heißt, ein inkommentelles Vorgehen wurde entschieden,
geht nicht
War diese Bank mit all ihren Verknüpfungen.
Ich weiß nicht, wie viele tausend Systeme dazu gehörten.
Ich habe da keine Zahlen vorliegen. Auf jeden Fall so groß,
jenseits der Grenze, wo ich, von der ich vorhin sagte,
die Gesamtwahrscheinlichkeit des Scheiterns ist so, dass es ganz sicher scheitert.
Also dieses System hätte eigentlich nicht funktionieren können.
Trotzdem hat man es am Ende geschafft. Wie hat man
es geschafft? Man hat viermal diese Migration,
dieser Wechsel, das System wechselt das Kernbankensystems vorher probiert.
Man hat es alles fertig gemacht. Man hat einen kompletten Entwicklungs alle Entwicklungsarbeiten eingefroren,
außer den aller, aller Notwendigsten, sodass es keine Endsoftwareänderungen mehr gab,
für einen Zeitraum von, ich glaube, vier oder fünf Jahren.
Da also fünf Jahre, vier bis fünf Jahre vor dieser
eigentlichen Umstellung war die Software unverändert, wurde eingefroren.
Und dann hat man mit dieser Software versucht,
einmal einen kompletten Umlauf zu machen,
aber nur mit Testdaten, nur mit Testsystemen,
hat die komplette Bankenhardware nochmal aufgebaut und hat versucht,
das durchzuführen, diese Migration durchzuführen nach Big Bang.
Erster Versuch. Man hat genau versucht zu ermitteln,
was ist alles schiefgegangen, Wo hätte etwas nicht funktioniert,
die Datenmigration nicht funktioniert?
Die Schnittstellen haben nicht gepasst. Da gab es Softwarefehler,
da gab es Missverständnisse. Da gab es einfach Punkte,
wo die Menschen nicht das Richtige gemacht haben.
Und man hat versucht, das beim zweiten Mal besser zu machen.
Da hat man wieder versucht, daraus zu lernen.
Da war auch noch das komplette Desaster. Beim dritten Mal
war auch noch ganz, ganz viel, was schief ging.
Aber beim vierten Mal muss das Herz laufen,
weil das gerade ein Wochenende war, was besonders günstig war.
Es war Quartalsend, es war Feiertag,
fünf Tage die Banken zumachen konnten, weil Ostern war,
da hat man einfach noch vorne und hinten dran einen Tag drangehängt.
Das war also ideal und man musste deswegen diesen Termin schaffen
So, und tatsächlich hat es auch geklappt. Erstaunlich für
mich, aber das war ein gigantischer Aufwand von vielen,
vielen Leuten. Und das fünf Jahre lang keine Softwareänderung,
muss auch erstmal in der Bank akzeptieren. Gut,
also ich wollte Ihnen damit sagen, Big Bang scheitert aus als Vorgehensweise,
weil die Gesamtwahrscheinlichkeit für Fehler zu hoch ist und die inkrementellen Schritte tragen dazu bei,
das Fehlerrisiko zu verringern.
Es kamen halt noch andere Ziele,
nämlich auch noch den Nutzer mit einzuziehen,
das haben wir hier weggelassen,
weil das hier nicht so eine starke Rolle spielt,
bei inkrementeller Entwicklung von Systemen mitzukommen
Agile Entwicklung spielt auch noch eine Rolle,
dass man dem Auftraggeber zeigt, das ist das,
was ich baue, ist es wirklich das, was du willst.
Und da kann der Auftraggeber nochmal seine Informationen nachliefern.
Das spielt hier nicht so eine große Rolle. Hier spielt
er eine Rolle, dass wir ganz viele Zwischenlösungen brauchen.
Und die kosten natürlich ganz viel Aufwand.
Soweit dazu. Und dann kommt der nächste Abschnitt