"Technical Dept" und Cyber-Security

Only in German available.

Der Tweet von Michael Käser mit einer neuen Interpretation von “Tech Dept” hat mich zu diesem Blog-Beitrag inspiriert.

"Many engineers understand tech debt as 'old code' or 'outdated libraries', but in practice the biggest velocity killer for product engineering teams is when the "product model" starts to increasingly diverge from the "data model", and the UI has to bridge the gaps."

Aus Entwickler Sicht macht dies durchaus Sinn. Ein Ungleichgewicht zwischen Datenmodell, Produkt und GUI erschwert die Arbeit immer. Der Spagat zwischen Datenmodell und Benutzerinterface wird immer grösser und grösser. Wie sieht die Angelegenheit aus Cybersecurity-Sicht aus?

In White-Box-Reviews legen wir unseren Fokus unter anderem genau auf diese Stellen. Muss man als Entwickler Lücken füllen oder Brücken bauen, man muss vom Standard-Lösungsweg abweichen und den Spagat mit “kreativen Lösungen” hinkriegen.

Aber auch bei Black-Box-Reviews erkennen wir, dank unserer Erfahrung, Orte bei denen wir im Hintergrund solche “kreativen Lösungen” vermuten. Die Bedienung ist meist weniger intuitiv oder die API bietet Funktionalität, die nicht ins Gesamtbild passt.

Sobald Anpassungen an einem System historisch bedingt nicht einfach vorgenommen werden können, sollten diese Anforderungen zurückgestellt werden und das gesamte System angepasst/refactored werden. Dies benötigt leider oft mehr Zeit und ist somit teurer, man verhindert damit jedoch, dass dieser Spagat immer grösser wird.

Ein extremes Beispiel, welches wir schon öfters gesehen haben, ist wenn man die Entwicklung nicht bei null startet, sondern auf einem alten oder einem Beispiel-Projekt aufbaut. Eine Applikation die als Basis den "Zweck X" hat aber eigentlich "Zweck A" erfüllen soll, ist nie sicher. Der Grund dafür ist, dass sich der Entwickler nicht traut, den Basis Code zu ändern, da er nicht versteht, was es für einen Einfluss auf das Gesamtsystem hat. Und so wird immer alter Source-Code mitgeschleppt, welcher eigentlich nicht gebraucht wird aber doch vorhanden sein muss.

Was ändern?

Unser Empfehlung Produkt/Business-Model, GUI und Datenmodel stetig überarbeiten und and die aktuellen Anforderungen anpassen. Zudem auch den Mut beweisen, alte Zöpfe abzuschneiden und Datenfelder, welche nicht mehr verwendet werden zu löschen.

Die klassische Bedeutung von Tech Dept und deren Einfluss auf Cyber-Security wird in einem kommenden Blog behandelt.