Technische Schulden in kommerziellen Anwendungssystemen
Exposé
meine Diplomarbeit mit dem Titel "Technische Schulden in kommerziellen Anwendungssystemen" beruht auf meinen 17 Jahren als IT-Berater und Trainer.
In dieser Zeit habe ich mehrere Dutzend IT-Projekte gesehen. Ich konnte in dieser Zeit immer wieder feststellen, dass es bei der Entwicklung von IT-Systemen, die in täglicher Nutzung sind, immer wieder zu Situationen kommt, in der eine kurzfristige Lösung realisiert wird, ohne das Problem grundsätzlich anzugehen. So entsteht dabei ein immer größerer Zeitbedarf, um die Anforderungen der Software zu erfüllen.Dies wird als technische Schulden bezeichnet.
Die Fragen in meiner Arbeit sind: Wie entstehen diese Schulden? Warum werden sie in Kauf genommen? Welche Situationen im Entwicklungsprozess begünstigen die Entstehung der technischen Schulden?
Ein weiteres Zeil der Arbeit wird die Ausarbeitung von Strategien sein, die technischen Schulden entgegenwirken.
Als Forschungsmittel werde ich GTM (Grounded Theory Methodologie) nutzen, sowie meine Kontakte in die Wirtschaft.
Die Grundlage der Arbeit bildet eine Reihe von Interviews mit Entwicklern aus realen Projekten.
Aufgrund der Nutzung von GTM möchte ich die Arbeit nicht durch eigene Erwartungen verfälschen. Die Antworten auf die gestellten Fragen sollen sich erst aus der Arbeit mit den Interviewpartnern ergeben, genau wie eine Schärfung der Fragestellung.
Bei der Nutzung meiner Wirtschaftskontakte ist es mein Ziel, Firmen zu finden, die Projekte mit sehr langer Laufzeit verfolgen, wodurch die Wahrscheinlichkeit von technischen Schulden erhöht ist.
Zum Finden von Interviewpartnern werde ich zum einen meine Kundenkontakte im IBM Power bzw. AS400 Community nutzen sowie Kunden, die ich durch meine Tätigkeit als IT-Trainer gewonnen habe.
Das Interview wird als Art Pro Bono Beratung beim Kunden angetragen.
Comments
Diplomarbeit
Thema: Technische Schulden
Ziel der Arbeit ist es, eine klare Definition des Begriffes Technische Schulden zu liefern. Weiterhin soll untersucht werden, wie diese entstehen. Dieser Punkt ist in meinen Augen besonders wichtig, da dies der erste Schritt dahin ist, ebensolche zu vermeiden.
Welche Mittel sollen benutzt werden?
Der wesentlichste Punkt hierbei ist eine Studie über das reale Erscheinen der Thematik. Die Aufgabe besteht also darin, reale langlaufende Projekte zu untersuchen und herauszufinden, wie auf das Thema „technische Schulden“ reagiert wird.
Für diese Aufgabe werde ich mich einer Technik aus der Soziologie bedienen, der „Grounded Theory Method“. Hierbei handelt es sich um eine qualitative Befragung einzelner Personen, also Entwicklern.
Im ersten Schritt werde ich das Umfeld in 4 Kriterien einordnen.
1) Laufzeit des Projektes Hierbei interessieren mich besonders langlaufende Projekte. Projekte die über viele Jahre laufen, erschaffen gerne einen Mikrokosmos, in dem eigene Regeln gelten. Über die Laufzeit des Projektes verändern sich die Entwicklungsmodelle: V-Model zu agiler Entwicklung, Wasserfall-Modell zu V-Modell usw. Wie gehen die Projekte mit wiederholten Veränderungen einzelner Module um? Beispiele: ERP-Programme, die gesetzliche Richtlinien abbilden müssen, IQTIG- Institut für Qualitätssicherung und Transparenz im Gesundheitswesen
2) Ausbildung der Entwickler Hier ist es interessant zu sehen, welche Probleme durch mangelndes Verständnis entstehen können. Hierfür können bereits zwei Erfahrungsberichte genannt werden: Firma Overbeck, Weltmarktführer in ihrem Bereich, steuert seine Schleifmaschinen über ein XML File. Für jede Position wird ein neuer XML Tag benutzt, also3) Welche Techniken, Programmiersprachen, Datenbanken, API’s werden benutzt? Hier ist besonders die Frage interessant, welche technischen Schulden durch die benutzten Technologien erzeugt werden. Hierbei ist es sowohl denkbar, dass eine Änderung der Basistechnik zu großem Aufwand führt, zum anderen, dass mangelnde Kenntnisse der Technik hinter der API zu sich wiederholenden Problemen führt. Hierfür sind JPA Frameworks ein häufiger Grund. Gerade die Modellbildung für die Abfrage kann dabei zu Problemen führen.
4) Soziale Probleme Beispiele: Der Quellcode vom Chef wird nicht angefasst. „Das wurde teuer eingekauft, das muss gehen.” (Beides habe ich vor Kurzem bei „ORBIS Software GmbH“ gesehen.)Probleme bei der derzeitigen Umsetzung der Befragung:
Problem Corona: Vororttermine sind gerade so gut wie unmöglich. Gerade auch Reisen zu möglichen Gesprächspartnern sind fast unmöglich. Ich hoffe das die Terminierung im Juni möglich ist. Ich brauche eine schriftliche Aussage der Freien Universität, dass die Befragung im wissenschaftlichen Rahmen stattfindet. Bei den genannten Kunden bin ich als Berater oder IT-Trainer bekannt. Deswegen sollte ich hier sicherstellen, das der Kunde keine Konkurrenzsituation befürchtet.
-- Main.ldkohl - 23 May 2020
Selbstbefragung
In Ermangelung von Interviewpartnern habe ich mich hingesetzt und mal überlegt welche Fälle von technischen Schulden mir in meiner Tätigkeit als Berater und IT Trainer untergekommen sind.
Diese Betrachtung soll auch helfen, nicht in die Falle zu tappen, Normative Fallacy zu treffen. Die Bestimmung der „Vorurteile“ wurde auch bei Jörg Strübing „Grounded Theory“ als Vorbereitung genannt.
Gründe, die dazu führen, dass der Entwickler ein Code-Stück nicht mehr ändert, können sein:
Der Quellcode wurde aus einem Beispiel (Stackoverflow, Foren, Büchern) übernommen, ohne dieses näher zu überprüfen. Häufig steht das in Verbindung mit der Nutzung von APIs. Konkret kann ich hier die Nutzung von Datenbanktreibern nennen. Hierbei werden die Beispiele in vielen Anwendungen eins zu eins übernommen, ohne die Parameter zu prüfen oder die Funktion zu hinterfragen.
Was kann daraus resultieren? Die Möglichkeiten der Datenbank werden nicht vollständig genutzt. Die Transaktionssteuerung wird nicht aktiviert: „autocommit on“. Das kann dann zu Performanceproblemen oder auch Anwendungsfehlern führen. Sollte hier nicht an den Ursachen gearbeitet werden, führt das zu dem massiven Mehraufwand, dass die einzelnen Fehler erkannt und separat behoben werden müssen.
Gerade im Bereich der klassischen Relationale-Datenbank kann man eine Vielzahl von technischen Schulden finden. Dies beginnt meist mit einer unvollständigen Modellbildung, welche dazu führt, dass diese im laufenden Betrieb zu Änderungen im laufenden System führt. Wenn die Architektur der Software nicht optimal ist, also Queries zentral zusammen gefasst sind, kommt es dazu, dass man beliebig viele Teile der Anwendung anpassen muss. Dasselbe gibt es für die Modellbildung in der Software, wobei hinter jeder Abfrage eine Klasse steht, die die Ergebnisse in der Anwendung in einen OOP-Kontext bringt.
Hier sehe ich oft, dass sich diese Klassen über die ganze Anwendung verteilen, sodass diese nicht wartbar sind. Auch JPAs wie Hibernate helfen hier nur bedingt.
Hier sind wir bei dem nächsten Problem. Es gibt heute, glaube ich, keinen Entwickler mehr, der nicht schon mal mit OOP konfrontiert wurde. Leider wird OOP immer noch als Problem und nicht als Lösung wahrgenommen. Viele Techniken der OOP sind meiner Erfahrung nach nicht wirklich bekannt. Ideen wie Vererbung sind ebenfalls meistens unbekannt. Gerade in meiner Tätigkeit als IT-Trainer, bin ich immer wieder in der Situation, dass ich in JAVA-, Python-, Ruby- usw. Kursen Leute vor mir habe, die seit vielen Jahren programmieren, die Anwendungen geschrieben haben wie Bilderkennungssoftware (Ralf Balzer - Osram), die jedoch von dem Vorgang „Quadrat extends Rechteck“ überfordert sind. Dies soll zeigen, dass es jede Menge Entwickler gibt, die sehr gute Ergebnisse erzielen, aber für die die Vorgänge der Software-Architektur komplett neu sind. Ja, es macht Spaß, dann Sachen wie „Singleton“ oder „Factory“ zu demonstrieren. Das führt dann aber dazu, dass die Entwickler mit der häufigen Anpassung oder eskalierenden Codemenge leben, da sie davon ausgehen, dass diese nicht zu vermeiden ist.
Schön ist auch die Definition, die viele Leute für die Stelle Software-Architekt benutzen. „Das ist jemand der viele Jahre programmiert.“ Das zeigt auch hier, dass viele Menschen in der IT nicht mit den Werkzeugen der Software-Architektur umgehen können. Den die Nutzung von Entwurfsmustern wird von vielen als unnötiger Aufwand gesehen. Oder Entwurfsmuster werden ohne sin und verstand eingesetzt. Aus meiner Erfahrung lässt sich dies nicht auf einen Bildungsstand oder Erfahrungsbereich einschränken.
Hier kenne ich auch die Aussage von Diplominformatikern, dass Datenbankschemas und -normalisierung nur etwas für die Uni ist.
Entwurfsmuster scheinen an vielen Universitäten nicht als Pflichtfach unterrichtet zu werden.
Ein weiteres Problem ist in meinen Augen auch immer die Nutzung von APIs, ohne diese zu hinterfragen. Gerade High Level APIs im Webbereich wie Vaadin und Wicket, führen gern zu versteckten Fehlern. Die Probleme erscheinen erst ab einer bestimmten Datenmenge oder Zugriffshäufigkeit. Das ursprüngliche Problem wird dabei komplett von der API verdeckt. Hier ist die Frage, ob und in wieweit man von technischen Schulden sprechen kann.
Wenn ja, tritt genau dieses Problem immer wieder auch bei langlebigen Anwendungen auf. So ist es zum Beispiel im Logistikbereich und Bankenbereich üblich, sich auf ältere Softwarekomponenten zu stützen.
Gerade bei Systemen wie IBM i (AS/400) und IBM z (s390) ermöglicht das Betriebssystem den lückenlosen Zugriff auf alte Softwarekomponenten. Diese können dann zum Beispiel in Cobol oder RPG geschrieben sein und sind damit meist auch nicht multi-threadfähig. Das kann dann an vielen Stellen zu einem Mehraufwand führen.
Vielleicht ist das auch ein gutes Thema für das Seminar.
-- Main.ldkohl - 08 Jun 2020