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/architectural 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 branchenübergreifend mustertypisch beobachten lässt (siehe Abbildung 1).
Unkontrollierte Systemkomplexität und eine hohe Feature-Priorisierung führen zwangsläufig zu technischen Schulden und schleichender Architekturerosion.
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 wesentliche 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 stark 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.
(Bei diesen Daten handelt es sich um Beobachtungswerte aus spezifischen Fallstudien)
In der Softwareentwicklung verbergen sich technische Schulden häufig hinter Fehlern, Störungen und Systemausfällen.
Wie lassen sich Fehler, Störungen und Systemausfälle 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 Effizienzpotenziale 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.
Einhergehend mit relevanten Architektur-Artefakten wie Architecture Decision Records (ADRs), Quality Attribute Scenarios (QAS) und agile Acceptance Criterias
lassen sich Ansätze wie controlled Self-Governance/architectural governance effizient umsetzen.
Das Requirements Engineering ist nach wie vor ein zentraler Aspekt im Software-Engineering und auch eine zentrale Herausforderung.
Erfolgsversprechende Ansätze mit erheblichem Potenzial zur Steigerung von Effektivität und Effizienz sind
anforderungsgetriebene automatisierte Testverfahren, wie beispielsweise das REquirements-Driven Automated Software Testing (REDAST).
Diese Ansätze verbinden das Requirements Engineering mit qualitätssichernden Masßnahmen.
“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 für diese Herausforderungen ist, dass besonders industrielle Systemlandschaften schon länger nicht mehr als statische Konstrukte zu verstehen sind.
Bezogen auf Fehler, Störungen und Systemausfälle zeigen Praxis, wissenschaftliche Arbeiten sowie die Reliability- und Resilience-Engineering-Community,
dass in offenen, sich ständig verändernden 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.
Verstärkungseffekt durch KI-gestützte Entwicklung: Hinzu kommt ein weiterer Effekt.
Die KI‑gestützte Softwareentwicklung beschleunigt Softwareentwicklungsprozesse erheblich,
sodass in kurzer Zeit deutlich mehr Lösungen entstehen und konkrete Softwareentwicklungsartefakte die Realität bestimmen
(intended 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