FOLGE 036 - Technical: Wie gehe ich mit technischen Schulden um?

Michael Seidl: Willkommen zu einer neuen Ausgabe des Get Shit Down an IT Podcast. Mein Name ist Michael Seidel und das heutige Thema dreht sich technische Schulden und wie man damit umgeht. Zum Beginn, was sind denn überhaupt diese technischen Schulden? Und da gibt, würde ich jetzt mal behaupten in der IT aktuell ein paar einfache Beispiele. Also wenn bei euch noch immer irgendwelche Windows XP Rechner oder Windows 2000 Server oder Windows R2 Server laufen, dann würde ich stark behaupten, das sind technische Schulden. Ja, wenn es nicht eine wirklich... Nein, es gibt keinen Grund. Also wenn irgendeine Software diese alte Maschinen braucht, dann muss man wahrscheinlich diese Software einfach mal killen. Aber das sind einfach technische Schulden. Oder... In der Zeit von heute, wenn noch immer nicht MFA auf alle Mitarbeiter ausgerollt wurde oder jeder IT-Ladomen-Admin-Rechte hat, dann sind das meines Erachtens einfach technische Schulden. Sprich, technische Gegebenheiten, nicht Stand der Dinge sind. Da geht es jetzt nicht darum, jedes Jahr die neueste Hardware zu haben oder was auch immer, aber einfach wirklich ... Stand der Dinge, also MFA ist security technisch Stand der Dinge. Das sollte man eigentlich nicht mehr diskutieren müssen. Keine Windows XP oder Server 2.12 R2 betreiben sollte Stand der Dinge sein, dass das einfach nicht mehr aktuell ist. Ob es jetzt 2.19 Server, 2.22 Server oder 2.25 Server dass ich das Wort raus bekomme. Darüber kann man wahrscheinlich diskutieren, da gibt es Gründe. Aber alles, älter ist, würde ich behaupten, sind technische Schulden. Also über das geht es heute. Und da ist auch die Frage, wie man damit am besten umgeht. Und das Erste ist wahrscheinlich einfach mal die Identifikation von diesen technischen Schulden und die Dokumentation. Das heißt, wo bin ich denn nicht am Stand der Zeit? Wo habe ich denn technisch irgendwas verabsäumt?

Michael Seidl: Und wo muss ich irgendwie nachbessern? Da gibt es auch den Unterschied zwischen der Erkennung oder Definition von diesen technischen Schulden, weil da gibt es diese, die bewusst oder versehentlich gemacht worden sind. Bewusst wäre dann die Geschichte, wir mussten einen Meilenstein erreichen, wir mussten ein Projekt abschließen bis zum Tag X, deshalb haben wir das und das nicht machen können. Und unbewusst oder versehentlich ist einfach die Geschichte, wir wussten es nicht besser. Man hat vielleicht irgendwie ein Software, Programm, irgendwas eingeführt, neue Netzwerkinfostruktur, was auch immer und wusste einfach nicht, was denn hier vielleicht Stand der Dinge ist oder welche Best Practices man machen muss. Das heißt, es gibt die bewussten oder die versehentlich gemachten technischen Schulden. Die bewusst gemachten technischen Schulden Ist natürlich relativ einfach, man weiß ja, wo man so quasi hinterherhinkt, das heißt diese Niederschreiben, Dokumentieren und bei dem Unbewussten oder Versehentlichen ist die Frage, habe ich mittlerweile das Know-how, dass ich das beurteilen kann oder hole ich mir da einfach externe Leute, die mir da helfen? Da geht es in erster Linie mal einfach zum Identifizieren dieser technischen Schulden. Wie man sie dann behebt ist dann dementsprechend eine andere Frage, aber da würde ich definitiv, wenn das Know-how nicht vorhanden ist, jemanden externen holen, der sich wahrscheinlich täglich damit beschäftigt und denen einfach so quasi einen Systemcheck machen, was es auch immer geht, der mir dann so quasi einen Katalog erstellt, was denn so quasi zum Stand, zum aktuellsten Stand fehlt, dass man das zumindest hat. in erster Linie einmal identifizieren von diesen technischen Schulden. Was fehlt, wo hapert und dementsprechend das mal niederschreiben. Der zweite Punkt ist natürlich dann dementsprechend die Planung der Zeit und der Ressourcen, eben diese technischen Schulden zu beheben. Da wahrscheinlich auch dementsprechend natürlich priorisiert, je nachdem wie groß die technische Schuld ist oder welche Auswirkungen sie hat.

Michael Seidl: Jetzt würde ich mal behaupten, alles was so Richtung Security geht, wahrscheinlich aktuell am wichtigsten. Es hat wahrscheinlich jeder mitbekommen, in letzten Jahren gab es immer mal wieder Firmen, die gehackt wurden. Ich habe es auch mitbekommen, das Budget für Security wurde dann dementsprechend erhöht. Vielleicht hier präventiv Budgetplanen, Anfragen erhöhen. Weil komisch, es ist immer dann Zeit und Geld und Ressourcen da, wenn irgendein Problem auftaucht. Das kann man alles beheben. Das heißt, mit den aufgelisteten Schulden so quasi planen, was ist am wichtigsten, was ist weniger wichtig. Also wahrscheinlich ist es nicht so wichtig, sage ich jetzt mal, Server 2.19 auf 2.25 oder 2.22 zu heben im Vergleich zu ich muss MFA ausrollen auf alle meine Mitarbeiter. vom Gefühl her wahrscheinlich sagen, MFA wäre hier wichtiger, weil das ist doch security-technisch höher anzusiedeln als von Server 2.19 auf 2.25 oder 2.22. heißt, einfach mal dann dementsprechend mit der Liste, die man hat, definieren, was ist denen am wichtigsten und dann dementsprechend Zeit, Ressourcen und natürlich auch Budget planen. Also es wird definitiv was kosten, keine Frage. Und somit muss dementsprechend Zeitressourcen und Budget dafür geplant werden. das dann umzusetzen. Und der dritte Punkt wäre dann natürlich, solche technischen Schulden dementsprechend nicht mehr zu machen. Natürlich gibt es nach wie vor bewusste technische Schulden, wie wir es vorher gesagt haben. Es gab irgendeinen Abgabetermin oder irgendein Projekt musste zum Tag X fertig gemacht werden, wo dann vielleicht irgendwas nicht richtig implementiert wurde mit dem Wissen. dass man es nachziehen muss. heißt, da muss man dementsprechend das dann auch wieder dokumentieren und dementsprechend auch gleich danach einplanen und präventiv eben versuchen, keine Schulden mehr zu machen. Sprich, vielleicht auch bei Themen oder definitiv bei Themen entweder die internen Leute so weit zu schulen, dass sie Systeme ohne technischen Schulden umsetzen können oder auch hier dementsprechend externe Berater, externe Consultants.

Michael Seidl: dazu holen. In erster Linie natürlich vielleicht am Anfang bei der Definitionsphase, der also quasi hilft, den Weg aufzuzeigen, wie der Projekt XY umgesetzt wird am besten nach Stand der heutigen Zeit und dann optional natürlich auch bei der Umsetzung helfen. Wer jetzt dann schreit mit Exzellen, ja die sind so teuer, blablabla. Wie teuer wird es denn, wenn dementsprechend Security Preaches oder was auch immer passiert? Vielleicht darf immer ein bisschen abwägen, aber man kann das ja dementsprechend auch machen, dass man sie in der Implementationsphase holt oder bei der Planungsphase so quasi gemeinsam den Plan macht, wie es denn am besten umgesetzt wird. Vielleicht auch gemeinsam dann umsetzen mit den internen Kollegen, das Know-how aufzubauen. ich finde trotzdem ... sollte man, wenn das Wissen nicht da ist, zumindest für eine gewisse Zeit oder für eine gewisse Phase dieses Projektes externe Ressourcen dazuholen, technische Schulden zu vermeiden. Vor allem die, die unbewusst gemacht werden. Weil die kann ich dann auch dementsprechend nicht mehr korrigieren oder sehr schwer wieder identifizieren und korrigieren. Und das geht ja. Also wenn ich bewusst irgendwelche technischen Schulden mache, weil es zeitlich nicht passt, dann habe ich das dokumentiert und kann das dementsprechend planen. Aber wenn ich unbewusst oder unwissentlich Themen einfach nicht umsetze und eben technische Schulden mache, dann wären die auch nicht behoben. Und da können wir einfach externe Ressourcen dementsprechend helfen. Oder meine Leute vor auf Schulungen schicken. Ja, das kostet alles Geld. Aber wenn man dementsprechend die Qualität hochhalten möchte und auch vielleicht Stand der Dinge haben möchte, vor allem, ja. ist das einfach so. Dann müssen die Leute geschult werden, es müssen Extenents dazugeholt werden, Rat gefragt werden, aber dass man zumindest einen Plan hat, wie denn irgendwelche Projekte ohne diese technischen Schulden umgesetzt werden können. Das war's für diese Woche. Wenn ihr Fragen habt, diese bitte wie immer entweder per Textnachricht oder Sprachnachricht, am einfachsten via LinkedIn mir zukommen lassen, dann wird

Michael Seidl: deine oder eure Frage demnächst im Podcast behandelt. Ansonsten wünsche ich euch eine schöne restliche Woche. Bis zum nächsten Mal. Bleibt produktiv und bye bye.