Unternehmen müssen sich um ihre technischen Schulden kümmern – sonst können sie sich zu einem schwerwiegenden Problem entwickeln
in Low-Code Development, 7 Min. Lesezeit
Die Wahl der schnellsten Lösung für ein Problem, um dadurch kurzfristige Gewinne zu erzielen, ist häufig die falsche Strategie. Sie missachtet die langfristigen Auswirkungen auf ein Unternehmen. Damit begeben sie sich quasi freiwillig in den Teufelskreis der „technischen Verschuldung“ (Technical Debt). Für IT-Teams und Programmierer ist dies zu einem ebenso schwerwiegenden Problem wie für Chief Technology Officer (CTO) und andere Führungskräfte geworden. Die Team-Mitglieder, die die meiste Zeit mit Coden verbringen, befassen sich direkt mit der technischen Verschuldung. Wird diese früh genug erkannt, sind Programmierer in der Lage, ihr relativ schnell beizukommen und die Herausforderung zu lösen. Wachsen die technischen Schulden ungehindert weiter, kann dies den Betriebsablauf negativ beeinflussen. Darunter leiden wiederum die Produktivität der Mitarbeiter sowie der Umsatz – und gegebenenfalls sogar der Ruf des Unternehmens.
Einige Organisationen antizipieren diese potenziellen künftigen Probleme bereits und arbeiten an Lösungen – denn sie haben das Thema „technische Schulden“ auf ihrem Radar. Technische Schulden entwickeln sich zunächst im Datenkern eines Unternehmens und kaskadieren sich dann. Eine Anwendung, die die Geschäftsprozesse managt, kann ein Teil der Gegenmaßnahmen sein. Unternehmen funktionieren durch den Einsatz solcher Applikationen reibungsloser als zuvor.
Technische Schulden für Anfänger
Das Problem der technischen Verschuldung wurde vom Programmierer und Berater Ward Cunningham, dem Entwickler des WikiWikiWeb, entdeckt. Er prägte den Begriff, als er ihn 1992 auf der diesjährigen Konferenz OOPSLA (Object-Oriented Programming, Systems, Languages and Applications) offiziell erklärte: „Mit der Auslieferung der ersten Code-Zeilen beginnt die Verschuldung“, so Cunningham. „Geringe Schulden treiben die Entwicklung voran. Jedenfalls so lange, wie sie zurückgezahlt werden. Die Gefahr besteht, wenn die die Schulden nicht beglichen werden. Jede Minute, die in einen Code investiert wird, der nicht hundertprozentig passt, sind Zinsen dieser Verschuldung. Unternehmen können unter der Last einer nicht konsolidierten Implementierung zusammenbrechen.“ Die technische Verschuldung ist damit ein Beispiel dafür, wie fahrlässig eine Vorgehensweise sein kann, bei der auf schnelle Ergebnisse gedrängt und künftige Konsequenzen vergessen werden.
In der Realität kostet jede Anwendung, jedes Netzwerk oder jede Plattform, die schnell, einfach und kostengünstig zu installieren ist, durch spätere Korrekturen viel mehr als geplant. In kürzester Zeit würden die Ressourcen der IT-Teams dadurch gebunden, die entsprechenden Anwendungen mit zusätzlichen Funktionen auszustatten, damit sie weiterhin einsetzbar bleiben. Im Gegensatz dazu bieten Systeme, die zwar in ihrer Implementierung aufwändig sind und Zeit in Anspruch nehmen, in absehbarer Zukunft deutliche Vorteile: Sie müssen nicht nachgerüstet werden, sind in der Handhabung robust und lassen sich skalieren – die Vorab-Investitionen sind damit im Laufe der Zeit mehr als ausgeglichen.
Gemeinsame Ursachen identifizieren
Cunningham unterstreicht in seiner Erklärung zu technischen Schulden, dass dieses Phänomen nicht unbedingt negativ sein muss. Es kann durchaus wertneutral und eine Folge eines über Jahre andauernden Entwicklungsprozesses sein. Aber natürlich kann es ebenso negative Auswirkungen auf Unternehmen haben, so Dag Liodden, Mitbegründer und CTO des Werbetechnikanbieters Tapad. In einem Interview mit dem Hacker Noon-Blog der Technologie-Venture-Capital-Firma FirstMark tritt eine unvermeidliche oder – in Lioddens Worten „absichtliche“ technische Verschuldung auf, wenn ein Produkt schnell auf den Markt gebracht werden muss. Sei es, dass dies auf Veranlassung der Geschäftsleitung oder als Reaktion auf die unerwartet frühe Einführung eines Wettbewerbersystems geschieht. Obwohl diese Vorgehensweise nicht ideal ist, basiert sie auf strategischen oder taktischen Gründen. Diese Art technischer Verschuldung wird daher wahrscheinlich keinen dauerhaften Schaden anrichten.
Die Probleme beginnen, wenn Technical Debt als Ergebnis von Qualitätsminderungen entsteht – egal, ob dies zufällig oder organisch entsteht, zum Beispiel durch das Fehlen bewährter Methoden. Die Agile Alliance betont, dass falsch geschriebener Code, Bugs, Fehler in der Plattform-Architektur, beim Testing und Duplizierung nur einige der Praktiken sind, die technische Schulden verursachen kann. Jede einzelne (oder eine Kombination von mehreren) kann verheerende Folgen für die Produktivität und die Profitabilität von Unternehmen haben.
Von FirstMark als „Bit Rot Tech Debt“ bezeichnet, ist dies die schleichende Entropie der Leistung eine Plattform aufgrund von Verschleiß. Der Grund dafür ist eine Vielzahl kleiner Änderungen am System. Jede Veränderung allein ist wahrscheinlich nicht problematisch – einige sind sogar notwendig. Werden sie jedoch von verschiedenen Programmierern oder IT-Mitarbeitern durchgeführt, die nicht alle auf Basis der gleichen Prinzipien oder Plänen arbeiten oder die das ursprüngliche Design nicht vollständig verstehen, entsteht die technische Verschuldung. Diese Art der technischen Verschuldung ist die schädlichste von allen.
Gegen technische Schulden ankämpfen – und gewinnen
Unabhängig von der genauen Ursache dieses speziellen Mangels lassen sich die möglichen negativen Folgen nicht unterschätzen: Die für die Studie befragten 500 Führungskräfte gaben an, dass 40 Prozent der IT-Entwicklungszeit in diesen Unternehmen auf die Lösung von Problemen aufgrund von technischen Schulden aufgewendet werden. Es braucht keinen Tech-Experten, um zu verstehen, wie hoch der Produktivitätsverlust in diesen Organisationen ist.
Wie lässt sich dieser Kampf gegen die technische Verschuldung führen und Gewinne erzielen? Die Antworten der IT-Verantwortlichen hinsichtlich der Ursachen weisen häufig bereits den Weg zu möglichen Lösungen:
Die Trennung von IT und dem Rest der Organisation ist oftmals die größte Herausforderung. Daher sollten die IT-Teams und alle anderen Abteilungen kontinuierlich kommunizieren. Nur so lassen sich Silos vermeiden.
Die Befragten aus Unternehmen in Europa und dem Nahen Osten gaben darüber hinaus an, dass verbesserungswürdige Anforderungen an Dokumentationen und Projektbeschreibungen der Grund für wachsende technische Schulden wären.
Detaillierte Briefings und Anforderungskataloge hingegen verhindern, dass Programmierer und andere Mitglieder des IT-Teams Applikationen entwickeln, die nicht den Bedürfnissen der Anwender entsprechen.
Vereinfachte Prozesse sind auch für den Entwicklungsprozess hilfreich – und wirken der technischen Verschuldung entgegen. Mit dem Einsatz von Low-Code können Unternehmen kundenorientierte und interne Anwendungen schneller und deutlich effizienter erstellen, ohne hohe technische Schulden anzuhäufen.
Der Low-Code-Leitfaden
Fakten und Wissenswertes zum Thema Low-Code – Antworten auf die Fragen:
Was sind die Vorteile?
Wann sollte man Low-Code verwenden?
Wie meistern andere die Transformation durch Low-Code?
Schnell und agil zur digitalen Transformation
Diese Umfrage zur digitalen Transformation 2018 widmet sich den Problemen bei der Digitalisierung. Zudem wird aufgezeigt, wie Low-Code Development einen möglichen Lösungsweg darstellt.
Management Summary: Process Manager
Sie möchten sich in aller Ruhe mit den Themen Business Process Management, Low-Code Development und RPA befassen oder diese im Kollegenkreis weiterempfehlen?
Hier erhalten Sie die Inhalte dieser Website als Management Summary im PDF-Download. Wir wünschen eine inspirierende Lektüre – auf dem Screen Ihrer Wahl oder gedruckt.
