Ich möchte diese Probleme, die durch Änderungen entstehen,
die unverständlich sind, gerne in einen Zusammenhang stellen mit Wartbarkeit,
mit Wartung und mit geschäftskritischen Systemen.
Dieses Stage-Model, was ich Ihnen bei der Gelegenheit vorführen möchte,
hat hier an dieser Stelle einen Punkt, Verlust an Wartbarkeit.
Und das ist genau das, was wir eben hatten im letzten Abschnitt,
die Wartbarkeit verschlechtert sich, höherer Aufwand an Änderungen.
Deswegen möchte ich diesen Begriff Technical Debt noch einmal ein bisschen
genauer betrachten. Wir springen ein paar Folien nach von.
Dort haben wir etwas zum Begriff Technical Debt
Ja, wie schon gesagt, sind das kurzfristige Lösungen,
aber Dinge, die irgendwie langfristig Nachteile halten.
Sowas können wir nicht immer vermeiden. Wir haben Unvorhergesehenes,
was länger dauert. Wir müssen aber Termine einhalten,
weil der Auftraggeber darauf wartet. Und solche kurzfristigen Lösungen können
ganz verschiedener Sachen sein. Das können kleine Sachen sein,
dass wir irgendwo unsere Entwurfsprinzipien mal kurz vergessen und enge Kopplungen machen,
obwohl wir das eigentlich nicht wollen,
dass wir mit irgendwelchen Tricks arbeiten oder dass wir eine technische Entscheidung fällen,
die zwar schnell eine Lösung verspricht,
aber eigentlich nicht
so richtig ins Konzept passt
Ja, die zum Beispiel ein Framework, was Nachteile mit sich bringt,
vielleicht für Security oder für Performance oder für Skalierbarkeit,
aber wir haben es schnell verfügbar,
wir kennen es damit aus und wir können erstmal eine Lösung ausliefern.
Wir wissen schon ganz genau,
dass es eine kurzfristige Lösung, wir sparen jetzt Aufwand,
wir müssen irgendwie schneller sein, um einen Termin zu erreichen.
Die Lösung ist schnell verfügbar, schnell auch mit geringem Aufwand,
aber wir haben langfristige Nachteile, weil das in irgendeiner Form,
also wie gesagt, schon Performance-Sicherheit irgendwas sein kann.
Es muss nochmal gemacht werden, es muss nochmal richtig gemacht werden.
Und solange dieses Problem nicht gelöst ist, solange dieses noch nicht
richtig gemacht ist. So lange haben wir etwas Schlechtes.
Schlecht ist jetzt im Sinne vor allen Dingen im Sinne von Wartbarkeit.
Wir betrachten ja hier gerade, wir wollen Änderungen weitermachen.
Änderungen am geschäftskritischen System sind notwendig. Und diese Änderungen sind dann
nur möglich, wenn wir hohe Kosten in Kauf nehmen.
Und das ist das, wo dieser Begriff aus der Finanzwelt
Technical Dead herkommt. Wir haben so ähnlich wie einen Kredit,
ja, wir haben kurzfristig, wenn sie das übersegen,
niemand will eine Fabrikhalle bauen, damit er mehr Produkt,
mehr Maschinen aufstellen kann.
Ja, dann hat er kurzfristig Vorteile.
Ja, er hat schnell die Maschinen,
kann schnell produzieren
Weil jetzt ist gerade die Nachfrage, alle Leute wollen jetzt gerade,
was weiß ich, ich will mir Impuls kaufen,
ja, und er kann sich Geld bei der Bank holen.
Ja, wenn er das aber macht, hat er zwar eine schnelle Lösung,
aber nachteilig, langfristig muss er Geld an die Bank zurückzahlen.
Er wird also versuchen, möglichst schnell eine Schulden loszuwerden.
Und so ist das hier auch, wir sollten versuchen,
möglichst schnell diese schlechten Sachen loszuwerden, weil wir haben langfristig Probleme,
die Änderungen durchzuführen. Ja, so,
ich habe hier auf der nächsten Folie mal ein Zitat gebracht,
wo jemand sagt, was ein Technical Depp ist, ja,
also irgendwie schlechter Code und Man nimmt in den Schulden auf.
Und man muss sie aber möglichst schnell zurückzahlen.
Und wenn man das nicht macht, dann kostet das eben
ein Interest, also Zinsen kostet das.
Und das kann tatsächlich ganze Organisationen dazu bringen, dass sie
ihre geschäftskritischen Anwendungen nicht mehr machen können und nicht mehr benutzen können.
Und das ist ja genau das, was wir als Problem haben.
Wir hatten hier diese vier Koordinaten
Also, wenn wir sagen, es gibt etwas Positives,
so in etwas Negatives sichtbar, unsichtbar, einfach nur Problemen,
dann wäre Technical Debt etwas, was negativ ist und was nicht sichtbar ist.
Um die anderen Koordinaten noch, die anderen Quadranten noch zu benennen,
ja, also wenn wir ein neues Feature eingebaut haben und dann ist es da,
und das ist das, was der Kunde möchte,
dann ist das ein neues Feature und das ist was Positives.
Ja, es gibt auch Dinge,
die positiv sind und man sieht sie nicht,
wir haben eine tolle Architekturänderung vorgenommen,
die in der Zukunft Erweiterbarkeit ermöglicht oder wir haben Sicherheitslöcher geschlossen,
das sieht man nicht unmittelbar, ja,
und es gibt natürlich auch Sachen, die sind sichtbar,
weil sie sie sich auswirken,
wie zum Beispiel ein Fehler bezüglich, also Fehlverhalten,
ja, aber es ist negativ.
Das gibt es auch noch. Und da ist Technical Dead
etwas, was negativ ist und nicht sichtbar.
Das Ganze ist ja die Überleitung dazu,
um zu sagen, wir können wir uns das leisten.
Und da möchte ich jetzt dieses Schema einführen, staged model.
Stage model vielleicht erstmal einen Fehler, den ich hier noch in den Folien habe.
Hier muss noch ein Haar ran, der heißt Rollig,
Raulig, das Watzlar-Fraulich, ist ein ursprünglich ein gebürtiger Tscheche,
der seit ganz vielen Jahren USA lebt.
Ich glaube jetzt mittlerweile Rente gegangen, ein sehr, ein sehr netter Mensch.
Ich habe ihn mal kennengelernt. Also der hat dieses nette Modell erstellt,
das möchte ich Ihnen gern nahebringen,
weil ich es gut finde zur Kommunikation, worum geht es überhaupt?
Zunächst, dass man sieht es aus wie ein Wasserfallmodell,
es ist am Ende tatsächlich ein Zustandsmodell.
Ja, also wir haben hier, das sind jeweils Durchstände und
die Pfeile sind jeweils Zustandsübergänge. So, dieses Zustandsmodell beschreibt,
das, was wir als Lebenszyklus nennen können, ja.
Und alles, was wir normalerweise in Lebenszyklusmodellen haben,
nämlich Anforderungsanalyse, Entwurf, Implementierung, in Betriebnahme,
das ist alles hier vorne drin bei Initial Development.
Man hat das einfach zusammengefasst. Wir konzentrieren uns auf das,
was danach kommt, nämlich nach der Inbetriebnahme, das ist das hier.
Dieser Zustandsübergang ist die Inbetriebnahme, wir haben eine lauffähige Version
und ab jetzt ist dieses System das System in Betrieb.
Wie wir schon gesagt hatten, die Welt ändert sich.
Die Welt ändert sich ständig, alles Mögliche muss geändert werden
von technischen Änderungen an der technischen Plattform.
Wir hatten ja hier so ein Bit,
ich gehe nochmal zurück, Was für Änderungen haben wir?
Ja, wir wollen vor Qualitätseigenschaften verbessern, Technologievideos verändern.
Natürlich auch Fehler beheben. All diese Änderungen im Moment,
ich möchte wieder zurück zu diesem hier,
all diese Änderungen wollen wir so einbauen,
dass wir das System weiterhin ändern können.
Und das sind evolutionäre Veränderungen.
Evolutionäre Veränderungen sind solche Mitstrukturanpassungen
Diese Strukturanpassungen haben zur Folge, also Struktur an Personen,
meine ich so, zum Beispiel, wenn wir eine Klasse erweitern,
erweitern, erweitern, wird sie irgendwann zu groß.
Wir sollten sie trennen nach Zuständigkeiten. Wenn wir einen Dialog
haben, da kommt was hinzu, hinzu, hinzu.
Irgendwann wird ja über und unübersichtlich, wir sollten ihn aufteilen.
Wenn wir an der Datenbank was ändern,
irgendwann haben wir da Sachen drin zusammen in einer Tabelle,
die nicht zusammengehören, dann sollten wir die anpassen.
Ja, wenn wir irgendwie Sicherheit mehr brauchen,
dann sollten wir ein Framework austauschen.
Das alles sind Dinge, die ich hier meine mit Strukturanpassungen
und das sind diese evolutionären Veränderungen.
Vielleicht machen wir hier
Weil dann ist Entsprechungszeichen davor. Ja, also das entspricht
solchen Änderungen, wo wir die Struktur tatsächlich anpassen.
Und wir können weiter etwas tun,
Evolution meint jetzt so etwas wie die Hörentwicklung ist möglich.
Revolution wäre wegschmeißen. Den Königköpfen, einen neuen, eine
neue Regierung einführen. Das ist Revolution. Wir meinen Evolution
, wir wollen dieses Taufen weiterentwickeln. Und wir hatten,
was wir vorhin gesagt hatten, für geschäftskritische Systeme,
das ist einfach notwendig.
Wir können uns das nicht leisten, die wegzuschmeißen.
So, das sind die evolutionären Veränderungen.
Und jetzt kommt es zu
diesem Technical Debt
Ja, es kommt dazu, dass wir Sachen machen,
die wir einfach nur schnell machen müssen. Vielleicht auch manchmal Sachen,
die weil wir sie nicht besser können oder Sachen,
weil wir sie vielleicht einfach durchunterlassen, nicht so gut machen.
Dazu kommt es, diese Fehler führen zu Verlust an Wartbarkeit.
Verlust an Wartbarkeit bedeutet auch, Höreraufwand, Veränderungen und kommende Änderungen
werden schwerer. Das ist diese Zinslast. Die Zinsen werden
immer mehr und irgendwann sind wir nur noch am Zinsen zahlen.
Irgendwann sind wir nur noch daran, Reparaturen zu machen.
So, die Welt ändert sich aber weiter. Ach so,
und wir sind dann hier in einem Zustand wo wir keine
evolutionären Änderungen mehr machen können, sondern wir können nur noch Service-Patches machen.
Patch ist ein Flick. Ja, vielleicht kennen Sie solche,
die sind vielleicht jetzt im Moment ein bisschen aus der Mode.
Alle Mode kommt ja wieder. Es gab so Patchwork-Sofa-Decken. Ja,
wo so kleine Stoffstückchen aneinander genäht waren und das Ganze sah
irgendwie schön aus, bis hin zu mit künstlerischen Bildern.
Also Patchwork ist etwas, was aus Flicken gemacht wird.
Ja, ich denke jetzt an den Kupferkessel,
denen die Oma auf dem Herd hat,
der Opa hat den schon ein paar Mal geflickt.
Das ist da wieder dicht. Aber das sieht nicht mehr
schön aus, ist auch nicht so richtig hygienisch
Aber er tut sein Ding noch. Und so ist das mit diesen Service-Patches
. Diese Service-Patches machen die Veränderungen, die wir brauchen.
All diese Veränderungen, die wir hier gerade eben gesagt hatten,
organisatorische Art, gesetzliche, artliche Nugiennung,
die gleichen Änderungen wie hier machen wir hier auch.
Aber hier machen wir sie ohne Strukturanpassung.
Es geht darum, die nur gerade mal lauffähig zu machen
Ohne Strukturanpassung heißt natürlich auch, dass wir Defizite in Kauf nehmen,
dass wir diesen Techniker dort haben und diesen Techniker dort nicht wegrollen.
Ja, und damit wird es immer mehr,
immer mehr, das eine Zitat eben sagte, ja,
da sind schon Firmen dran kaputt gegangen.
Auf jeden Fall kann es dazu kommen, dass unsere Hauptanwendung,
unsere geschätzkritische Anwendung irgendwann nicht mehr geht.
Und was passiert dann? Ja,
dann kommen wir in einen Zustand, wo wir sagen können,
okay, wir unterstützen jetzt leider weitere Änderungen nicht mehr.
Wir können keine weiteren Änderungen mehr machen
Weitere Änderungen sind nicht mehr möglich, und zwar nicht,
weil wir das nicht mehr den Kurt ändern können,
sondern weil wir immer neue Fehler einführen,
weil wir es nicht mehr stabil bekommen.
Und dann kommt es dazu, dass wir in den nächsten Zustand kommen,
der heißt ja Faceout, der ist dadurch gekennzeichnet,
dass die Software schon noch läuft.
Aber sie sehen hier nicht mehr diesen Bogen, wir können
keine Änderungen mehr machen. Die Software kann genauso lange verwendet werden,
wie die Umwelt sich nicht so ändert, dass es nicht mehr geht.
Also mein Beispiel mit diesem Minijob,
wenn die Politik wieder einen neuen Minijob-System einführt,
dann geht unser System kann das nicht,
dann können wir unser System nicht mehr verwenden
Wenn wir nur die Mehrbesteuer sich ändern oder einen Steuersatz sich ändern,
das kriegen wir vielleicht noch durch Parameteränderungen hin.
Aber so eine strukturelle Änderung, eine ganz neue Regel einführen,
das wird vermutlich nicht gehen. Und dann können wir es
nur noch abschalten. Es gibt genügend Beispiele,
wie diese Änderungen der Unterstützung aussieht, während wir,
und zwar wird das häufig, ist es eine häufig eine Mischung zwischen technischer Unmöglichkeit.
Ja, wir können einfach die Software nicht mehr wirtschaftlich unterstützen.
Wir können keine Servicepatches mehr machen in vielen Bereichen.
Oder das Management manchmal auch und das Management entscheidet aus strategischen Gründen,
wir unterstützen diese Software nicht mehr
Letzter, jüngstes Beispiel. Microsoft hat irgendwann verkündet, Windows 7 wird nicht mehr unterstützt.
Alle sollen jetzt Windows 10 benutzen. Da gehört natürlich dazu,
dass man nicht nur, dass die Entwickler,
dass ganz viele gute Entwickler bei Windows 7 noch gebunden sind,
um da irgendwelche alten Fehler zu machen, sondern auch,
man möchte neue Systesysteme einführen,
man möchte neue Schnittstellen führen.
Und man möchte natürlich auch vielleicht mehr Lizenzkritikgebühren kassieren durch so
ein 365-Modell-Software-as-a-Service oder sowas. Also das heißt,
das ist eine bewusste Entscheidung meistens von Entwicklern und Management.
Jedenfalls auf der Provider-Seite
Während das hier eine Entscheidung ist,
ist es dieser Zustandsübergang, ist meistens keine Entscheidung,
die so bewusst passiert, sondern es passiert einfach,
weil wir schlechte Arbeit machen oder weil wir,
die viele von den Sachen, die Techniker dead tysen,
nicht aufnehmen, nicht aufräumen.
So, um noch das fortzusetzen,
also wenn wir dieses System hier haben in dem Zustand Faceout,
es kann nicht mehr geändert werden und dann kommt irgend passiert etwas in der Umwelt,
was verhindert, dass es weiter benutzt wird, dann wird es einfach abgeschaltet.
Diese, wir haben hierzu Fragen zur Wiederholungsfragen, erklären Sie,
Stage Model, das ist diese Frage 4 hier.
Erklären Sie, stellen Sie den Bezug zur Technik,
das ist genau das, was ich jetzt erklärt habe.
Manchmal werde ich gefragt, wie viel muss ich denn davon erklären können? Ja,
also sie dürfen gerne ihre eigenen Begriffe verwenden,
wenn Sie sagen, einfach hier, statt dem Faceout,
dass eben keine Änderungen mehr möglich und Closed Down,
da sagen Sie stattdessen Lockdown, daran wird es nicht scheitern,
sondern sie sollen es gut erklären können.
Das ist eigentlich wichtig, Sie sollen es verstanden haben.
Ja, soweit zu diesem Stage Model. Es erklärt sehr schön,
deswegen erkläre ich so lang und breit hier,
wie sich sich ein Softwaresystem während der Wartung verhält,
wenn er einfach mal den Begriff Softwareerwartung nehmen, ja,
da ist das alles hier irgendwie ein großer Salat.
Und hier haben wir es schon strukturiert.
Und was ich Ihnen gerne unbedingt mitgeben möchte,
ist geschäftskritische Systeme dürfen eigentlich nur auf diesen Zustand Evolution bleiben.
Und wenn immer dieses Technikerletzt sich ansammelt,
wenn wir also solche Entscheidungen haben, die wir eigentlich nicht wollen,
dann müssen wir die so schnell wie möglich aufräumen.
Wir sollten sie nicht als Dauerzustand akzeptieren,
weil dieses Zinszahlen eben dazu führt,
dass wir immer mehr der Arbeit,
so ein Servicepitch ist viel aufwendiger,
also wir haben hier höhere Kosten,
als wenn wir hier das machen
So, Sie sehen, hier gibt es keine Pfeile rückwärts,
der Pfeil rückwärts wäre Refactoring,
dazu kommen wir in einem der folgenden Abschnitte gleich noch.
Ich möchte noch etwas dazu sagen,
dass das hier diesen Zyklus, den wir hier sehen,
nicht das gesamte Softwaresystem betreffen muss, sondern durchaus auch Teile davon.
Es gibt Teile, die sind schlechter, die sind in diesem Zustand
und ein anderer Teil ist nur noch in diesem Zustand.
Wenn die Softwaresysteme insgesamt so ist,
dass wir es nicht mehr weiter betreiben können,
das heißt,
dieser Rückweg Refactoring existiert nicht mehr oder wir sind gar hier
gelandet und müssen es abschalten,
dann bleibt uns
nur noch
die Neuentwicklung
Und dazu möchte ich ein paar Worte noch sagen zur Neuentwicklung.
Da füge ich mal hier eine leere Seite ein und würde
das gern mit Ihnen gemeinsam hier mal aufschreiben.
Und zwar geht es um die Ablösung eines Systems durch neue Entwedern.
Das ist ein anderes Stift hier. Dieses Ablösen durch Neuentwicklung
Er erscheint gerade Leuten mit wenig IT-Verstand,
wie wir Manager meistens haben, als die gute Alternative.
Und ich glaube, wir haben auch eine Frage dazu.
Genau, das ist die Frage. 3 hier,
Risiken der Ablösung eines existierenden Systems durch eine Neuentwicklung.
Das ist das, was wir jetzt hier besprechen wollten.
Das kann sich natürlich nicht nur auf ganzes System,
sondern auch auf Teile des Systems beziehen, aber die Punkte,
die ich jetzt nenne, treffen auf beides zu.
Zunächst müssen wir erstmal sagen, ja,
das Ganze hat Vorteile
Die sind unbestreitbar und die Vorteile sind das frühere Probleme nicht mehr vorhanden sind.
Und sowas wie Fehler, Menge der Wartbarkeit. Sowas wie
eben die schlechte Struktur, diese Strukturmenge Das ist ein Punkt,
oder dass wir die Sachen haben, die nicht zur Umgebung passen.
Vielleicht auch, weil die Umgebung sich verändert hat,
schlechte Person zur Umgebung. Soweit. Und natürlich ist es
so, dass wenn wir neu anfangen,
haben wir auch eine
neu beginnende Nutzungsperspektive
Wir haben also alles frisch entwickelt. Wir haben keine Defizite,
wir haben Cleancode, wir haben super Tests gemacht.
Auch das Look and Feel sieht so aus, wie wir das heute möchten.
Ja, das ist alles toll. Aber leider,
wie Sie wissen, nicht keine Vorteile ohne Nachteile.
Es gibt ein paar Nachteile. Und diese Nachteile sollte man durchaus
in Kauf nehmen, also mit berücksichtigen, sollte man drüber nachdenken.
Zunächst erst mal möchte ich nennen, hohe Kosten und lange Entwicklungsdauer.
Weil wir entwickeln ja ein System, was komplex ist,
Soweit, das ist erst mal ein kritischer Punkt. Ja,
wir entwickeln ja eigentlich nur das Gleiche, was es schon mal gab, neu.
Und wenn ich jetzt noch mal das Stage-Model anschaue,
ja, also wir machen hier das,
was wir hier falsch gemacht haben oder was wir nicht gut gemacht haben,
nämlich diesen Verlust an Wartbarkeit, das machen wir dadurch Löweck,
dass wir noch mal hier oben von vorne anfangen,
also wieder in die Show-Develope mitmachen.
Soweit. Aber wir haben noch zusätzlich neben diesen Nachteilen,
haben wir die typischen Risiken einer Neuentwicklung
Das müssen wir einfach noch mit weiter in Kauf nehmen oder in Betrag ziehen.
Typische Risiken von Neuentwicklung. Und das ist,
dass wir die Gefahr haben, das Budget zu überschreiten.
Es dauert länger, es kostet mehr.
Terminüberschreitung und vor allen Dingen ist es,
dass das System unreif ist und Fehler hat
Ja, also wir haben jetzt ein Jahr investiert,
um einen Teil des zu wesentlichen Teil des Systems neu zu entwickeln.
Wir geben es zu den Nutzern und die stellen fest,
Fehler über Fehler, manche Funktionen fehlen.
Manche Sachen funktionieren nicht, wie sie sollen.
Und das ist natürlich kritisch. Aber den allerkritischsten Punkt,
den möchte ich jetzt noch nennen, das größte Problem.
Manchmal ist das fast unmöglich, weil die Anforderungen nicht bekannt sind.
Weil die Anforderungen an und Leistungen des Software-Systems nicht genau bekannt sind.
Ja, und das mache ich mal rot.
Nicht genau bekannt. Und das ist sozusagen ja,
der Killer. Wir können nicht einfach ein Festpreisprojekt ausschreiben,
weil wir nichts haben, was wir den Leuten geben,
als können als Anforderungsbeschreibung sagen, hier, das sollt ihr bauen.
Das System ist historisch gewachsen. Keiner hat jede Change-Request aufgeschrieben.
Manchmal wissen wir nicht mal, wie genau wichtige Geschäftsregeln implementiert sind.
Wir müssen das alles erst ermitteln. Und dieses erst ermitteln ist halt
sehr aufwendig und ich kann auch dabei Fehler machen. Das heißt,
häufig steht diese Gefahr oder das Risiko besteht nicht nur darin,
dass wir Fehler machen, sondern auch,
dass wir das System entwickeln, was vieles nicht kennt,
nicht kann,
was das alte System kann
Und das ist der Punkt,
was hier die Frage 3 beantworten,
nehmen beantworten Fragen gestellt,
was sind Risiken der Ablösung eines existierenden Systems durch Neuentwicklung