Architekturberatung im Software-Engineering
Evaluation von Systemstrukturen und Entwicklungsprozessen
Softwarequalität ist dynamisch und das Resultat aktiver Steuerung.
Gleichzeitig wächst die Komplexität technischer Systeme rasant und verlangt eine gezielte Steuerung
(controlled Self-Governance).
Um Qualität, Stabilität, Leistungsfähigkeit und Anpassungsfähigkeit systematisch zu erhöhen,
werden Steuerungsinstrumente und Methoden der Validierung und Verifikation speziell
für industrielle Systeme ständig weiterentwickelt.
Durch eine fehlende aktive Steuerung ergibt sich ein bekanntes Phänomen,
das sich brachenübergreifend mustertypisch beobachten lässt (siehe Abbildung 1).
Abbildung 1: Das Phänomen „Technische Schulden“ (Kruchten et al., 2019)
Die Gründe für das Phänomen „Technische Schulden im Software-Engineering“ sind umfassend beschrieben;
eine wesentlich Ursache ist die projektbezogene Finanzierung;
damit werden Anforderungen priorisiert, die einen direkten Geschäftswert (Projektnutzen) generieren.
Software-Qualitätsmetriken (wie Wartbarkeit > Modularisierung und Isolation) sind daher strakt unterrepräsentiert.
Formulierte Qualitätsziele und gemessene Metriken driften auseinander;
die entstehende Diskrepanz lässt sich auf Organisationsebene messen.
Quelle:
Kruchten et al. (2019),
Kruchten, Nord & Ozkaya (2012)
Das Muster:
Abhängig von der Organisation entstehen bereits nach einem Jahr aufgrund der Vernachlässigung qualitativer Anforderungen erhöhte Kosten in der Entwicklung.
Nach weiteren 6-24 Monaten, sinkt die Produktivität messbar, Fehlerkorrekturen nehmen zu, Entwicklungsgeschwindigkeit (Velocity) und Entwicklungskapazität mit direktem Geschäftswert nehmen ab.
Nach 3-5 Jahren, übersteigen Aufwände für Fehlerkorrekturen die Kosten der Entwicklung, die Externalisierungsquote steigt und trägt zur Beschleunigung der Architektur-Erosion bei;
die (fehlende) strategische Ausrichtung verstärkt das Phänomen und wirkt unmittelbar auf die Wettbewerbsfähigkeit.
In der Softwareentwicklung verbergen sich technische Schulden häufig hinter Fehlern, Störungen und Systemausfällen.
Wie lassen sich Fehlern, Störungen und Systemausfällen vermeiden?
Hier kann eine evolutionsstrategische Ausrichtung für fundierte Architektur- und Designentscheidungen
(Priorisierung, Berücksichtigung von Lösungsalternativen und Risiken) hilfreich sein, um auf operativer Ebene
Effektivitäts- und Effizienzpotenzialen zu aktivieren.
Eine evolutionsstrategische Ausrichtung kann durch kollaborative Architektur-Entscheidungen, Design- und Code-Reviews zur Identifikation, Definition und Priorisierung von Backlog Issues gefördert werden.
Notwendig sind jedoch verlässliche Anforderungen, analysiert und formuliert aus drei Perspektiven (1) Business Needs, (2) Requirements Specification und (3) System Specification.
Das Requirements Engineering (RE) ist nach wie vor ein zentraler Aspekt im Software-Engineering, jedoch auch eine zentrale Herausforderung.
“Successful software systems always evolve as the environment in which these systems operate changes and
stakeholder requirements change. Therefore managing change is a fundamental activity in RE.”
Quelle: Nuseibeh & Easterbrook (2000) „Requirements engineering: A roadmap“
Ein Grund hierfür ist, dass besonders industrielle Systemlandschaften schon länger nicht mehr als statische Konstrukte zu verstehen sind.
Bezogen auf Fehlern, Störungen und Systemausfällen zeigen die Praxis und wissenschaftliche Arbeiten aus der Resilience-Engineering-Community,
dass in offenen, sich ständig verändernden Cloud- und IoT-Infrastrukturen die Vermeidung sämtlicher Ausfälle unmöglich ist.
Damit verändert sich auch das Aufgabenspektrum im Software-Engineering. Der traditionelle Ansatz der Fehlervermeidung (Fault Avoidance/Tolerance)
wird durch dynamische Systemfähigkeiten (Systemic Resilience) erweitert.
Hinzukommt ein weiterer Effekt. Die KI‑gestützte Softwareentwicklung beschleunigt Softwareentwicklungsprozesse spürbar,
sodass in kurzer Zeit deutlich mehr Lösungen entstehen und konkrete Softwareentwicklungsartefakte die Realität bestimmen
(intendet architecture ≠ implemented architecture ⇒ drifted architecture). Bei schleichender
Software-Architekturerosion
kommt es jedoch ohne aktive und systematische Restrukturierung zu einer architektonischen Degeneration, wodurch die konzeptionelle Integrität verloren geht
(Lehman, M. M. (1980), Anthony et al. (2024)).
~ Für eine unabhängige Studie stehen wir gerne zur Verfügung