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 Verifikation und Validierung 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.
Eine evolutionsstrategische Ausrichtung ist für fundierte Architektur- und Designentscheidungen
(Priorisierung, Berücksichtigung von Lösungsalternativen und Risiken) hilfreich, um auf operativer Ebene
Effektivitäts- und Effizienzpotenzialen zu aktivieren.
Beispielsweise durch kollaborative Architektur-Entscheidungen, Design- und Code-Reviews zur Identifikation, Definition und Priorisierung von Backlog Issues.
Notwendig sind jedoch verlässlich formulierte Anforderungen.
Daher ist nach wie vor das Requirements Engineering (RE) ein zentraler Aspekt, 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“
In der Softwareentwicklung verbergen sich technische Schulden häufig hinter Fehlern, Störungen und Systemausfällen.
KI‑gestützte Softwareentwicklung beschleunigt den Entwicklungsprozess 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 ohne aktive und systematische Restrukturierung zu einer architektonischen Degeneration, die konzeptuelle Integrität geht verloren
(Lehman, M. M. (1980), Anthony et al. (2024)).
~ Für eine unabhängige Studie stehen wir gerne zur Verfügung