Worauf es bei moderner Software-Architektur ankommt - und worauf nicht (mehr)

Es liegt wahrscheinlich am Begriff der Software-"Architektur" selbst, dass man sie automatisch mit einer Gebäude-Architektur assoziiert oder zumindest mit der ebenfalls physisch beschreibbaren Client-Server-Architektur.

Auswirkungen der Architektur-Analogie auf die Auffassung von Software-Architektur

Einerseits ist eine solche handfeste Analogie von Vorteil, weist sie darauf hin, dass jede Software eine Struktur hat und haben muss, eine Art grob granularen Grundriss. In ihm wird die Beziehung ihrer einzelnen Elemente sowohl zueinander als auch in Bezug auf die zu lösende Aufgabe festgelegt. Diese Struktur ist es, die die Nützlichkeit der Softwarelösung in Bezug auf ihre spätere Anwendung und Problemlösung entscheidend beeinflusst.

Was nichts anderes heißt, als dass die richtige und passende Software-Architektur für den Erfolg einer Anwendungsentwicklung von zentraler Bedeutung ist.

Der Spagat moderner Software-Architektur zwischen Struktur und Flexibilität

Allerdings stellt dies die moderne Software-Architektur gewissermaßen vor eine paradoxe Aufgabe. Einerseits muss sie einen Rahmen abstecken und Anforderungen an die Entwickler definieren. Auf der anderen Seite muss sie dafür sorgen, dass diese Struktur nicht zum Flaschenhals für die fließende Arbeitsweise agiler Projektteams wird. Im Framework SCRUM spielt etwa der iterativ-inkrementelle Prozess für die erfolgreiche Anwendungsentwicklung in Time und in Budget eine zentrale Rolle.

Das bedeutet, moderne Architektur muss beides: Einerseits muss sie die Requirements definieren, andererseits aber so flexibel bleiben, dass sie immer wieder neu angepasst werden kann. Zum Beispiel bei neuen Informationen, die vorher nicht da waren oder bei sich ändernden Anforderungen seitens des Kunden. Trotz fester Vorgaben entsteht Software-Architektur heute schrittweise und rückgekoppelt im Verlauf des Entwicklungsprozesses. Stets mit dem Fokus auf die Leitfrage, wie offen für Veränderungen die Lösung ist und inwieweit die jeweiligen Einzelschritte der Anwendungsentwicklung dem definierten Ziel nützen - oder eben nicht.

Näheres erfahren

Qualitätsmerkmale moderner Softwarelösungen

Diese neue Auffassung von Software-Architektur führt zu einem Perspektivwechsel und damit zu neuen Ergebnissen. Ganz vornweg zu einem der wichtigsten Qualitätsmerkmale heutiger Softwarelösungen: Sie so flexibel zu gestalten, dass kleinere Änderungen möglich sind, ohne dass sofort große Änderungen in der Software-Architektur durchgeführt werden müssen.
Ein derartig flexibles, emergentes Software-Design und die im agilen Prozess entwickelte Software-Architektur führt auch dazu, dass weitere zentrale Qualitätsmerkmale moderner Softwarelösungen erfüllt werden. Definiert werden sie laut ISO 25010 vor allem durch den sogenannten Qualitätsbaum.

Der Qualitätsbaum und seine Früchte

Die Anforderungspunkte dieser Norm werden im Leitfaden "Software Product Quality Requirements and Evaluation (SQuaRE)" definiert. Werden diese Punkte bereits in der Anfangsphase der Software-Architektur berücksichtigt, verläuft die Softwareentwicklung weit effizienter und günstiger. Was jedem einleuchtet, der schon einmal erfahren musste, wie nachträgliche Anpassungen das Budget gesprengt haben. Das Ziel muss angesichts dessen sein, Anpassungen zu vermeiden, oder sie, da sich dies oft nicht vermeiden lässt, auf ein absolutes Minimum zu begrenzen.

Laut dem Qualitätsbaum-Schema sollte die moderne und verantwortungsbewusste Softwareentwicklung folgende acht Qualitätskriterien erfüllen:

  1. Functional Suitability (Funktionalität): Die Software soll funktional sein, d.h. vollständig hinsichtlich der Softwarefunktionen, dabei korrekt und angemessen, d.h. weder unter- noch überdimensioniert.
  2. Reliability (Zuverlässigkeit): Die Lösung soll verlässlich und ausgereift sein, eine geringe Fehlertoleranz aufweisen und wiederherstellbar sein.
  3. Performance Efficiency (Performance): Eine auf moderne Weise entwickelte Software-Architektur soll Ressourcen besonders effizient nutzen und Kapazitäten schonen.
  4. Usability (Benutzerfreundlichkeit): Die Software soll leicht erlernbar und auch selbst lernfähig sein, sie soll sich leicht bedienen lassen und zudem den Benutzer vor den Konsequenzen einer Fehlbedingung (Datenverlust, Systemabsturz etc.) hinreichend schützen. Wenn das UX auch noch ästhetisch aussieht, ist die Benutzbarkeit der Softwarelösung nahezu perfekt.
  5. Compatibility (Kompatibilität): Niemand ist eine Insel, daher sollte auch eine gute Anwendung über Schnittstellen verfügen und mit anderer Software zusammenarbeiten können.
  6. Maintability (Wartbarkeit): Erwartet wird heute ein modularer Aufbau, der die oben bereits erwähnte Flexibilität bei Wartung und notwendig gewordenen Modifikationen ermöglicht. Dazu tragen auch wiederverwendbare Komponenten, hinreichende Testoptionen und aussagekräftige Analyse-Funktionen bei.
  7. Portability (Übertragbarkeit): Eine Software soll leicht zu installieren sein und sich einfach an unterschiedliche Umgebungen anpassen können.
  8. Security (Sicherheit): Angesichts des Cloud-Computing, des exponentiellen Wachstums des Mobile Computing sowie der digitalen Ökosysteme sollten heutige Software-Architekturen bereits in einem Frühstadium die Cybersicherheit mitdenken. Dazu gehört unter anderem die Beachtung des Datenschutzes und der Integrität ebenso wie sichere Administration, Authentizität und Schutz der Benutzer-Accounts.

Messbarkeit von Qualität durch unterschiedliche Qualitätsszenarien

Eine der relevanten Aufgaben einer Software-Architektur besteht darin, dass die Anwendung den wichtigsten Qualitätsszenarien genügt. Indem diese mit einer bestimmten Metrik als Zielwert arbeiten, können sie aus drei Arten von Szenarien messen, wie sich ein System unter dem Einfluss eines bestimmten Ereignisses verhält. Bei den drei erwähnten Szenarien handelt es sich um Benutzungs-, Änderungs- und Ausfallsszenarien.

Auf das Wie kommt es an: Agiler Prozess als Voraussetzung moderner Software-Architektur

Um all diese Qualitätskriterien einzuhalten, die Qualitätsszenarien erfolgreich zu durchlaufen und die Früchte dieses Qualitätsbaums in Form einer exzellenten Anwendungsentwicklung ernten zu können, muss der Blick vom Was auf das Wie der Entwicklung gerichtet werden.

Damit rückt der Rahmen in den Fokus, in dem ein Software-Projekt entwickelt wird. Abgesehen von Kanban, gehört SCRUM heute zu den bevorzugten Agile Frameworks bei der Entwicklung einer Software-Architektur - wie im modernen, agilen Projektmanagement überhaupt.

Das SCRUM-Framework - Teaming als Kernanforderung

Eine der Kernanforderungen des SCRUM-Frameworks besteht darin, dass die Produktentwicklung im Team mit flachen oder nicht vorhandenen Hierarchien geschieht. Teamarbeit ist in der Softwareentwicklung nichts Neues. Doch indem agile Teams in Sprints sowie in den eng getakteten Daily SCRUMs arbeiten und sich so inkrementell und iterativ dem Entwicklungsziel nähern, müssen Entscheidungen bezüglich der Software-Architektur erst relativ spät getroffen werden. Das Team bekommt so noch während des Entwicklungsprozesses die Chance, rechtzeitig auf den Zufluss neuerer Informationen zu reagieren und die Software-Architektur entsprechend anzupassen. (Ganz anders also als in der klassischen, linear verlaufender Wasserfall-Methode, in der Fehler erst bei der Installation oder dem Roll-out entdeckt werden und dann unter hohem Aufwand und Ressourcenverbrauch behoben werden müssen.)

Der Software-Architekt als Rolle und damit Paradigma des Wandels

Innerhalb des agilen Teams herrschen zwar flache Hierarchien. Allerdings gibt es mit dem Product Owner, dem SCRUM Master und dem Software-Architekten drei Rollen, die als eine Art Primus inter Pares fungieren.

Schon die Bezeichnung des Software-Architekten als Rolle, zeigt, von welchem demokratischen Geist SCRUM getragen ist. In der klassischen Softwareentwicklung ist die Bezeichnung Software-Architekt eine Positionsbezeichnung und markiert einen Karriere-Schritt. Aufgrund des in der Regel höheren Abstraktionsniveaus, auf dem der Software-Architekt dort arbeitet, entsteht das Verständnis von Software-Architektur als ein Top-down-Prozess. Nicht umsonst hat sich Bill Gates als Microsoft-CEO noch im Jahr 2000 den Titel "Chief Software Architect" umgehängt. Dies hat die Verknüpfung dieser Funktionsbezeichnung endgültig mit einer Position innerhalb der Unternehmenshierarchie unterstrichen.

Da Software-Architekt in der agilen Softwareentwicklung kein Titel, sondern eine temporäre Rolle ist, kann sie prinzipiell jedes der Teammitglieder übernehmen. Vor allem liegt der Fokus weniger auf technischen Aspekten wie zum Beispiel der Programmierung, sondern immer mehr auf Kommunikation. Ein agiler Software-Architekt in einem SCRUM-Framework versteht sich im verstärkten Maße als Kommunikator und Moderator. Seine Aufgabe ist es, zwischen den Teammitgliedern, den in den Daily SCRUMs berichteten Fortschritten sowie Behinderungen und dem Product Owner zu vermitteln. Stets mit dem Blick auf das Ziel der Anwendungsentwicklung und somit auf den Kunden bzw. Auftraggeber.

DevOps - Voraussetzung von Agilität

Der Software-Architekt sorgt auch dafür, dass die Verzahnung der Bereiche Entwicklung und Umsetzung nahtlos erfolgt. Obwohl DevOps in der Softwareentwicklung kein besonders neuer Hut ist, stellt es heute immer noch die Voraussetzung für eine agile Anwendungsentwicklung dar. Es kommt dem Geist des SCRUM Frameworks auch dahin gehend sehr entgegen, als es sich wie dieses in Schleifen des Sprints und des Daily SCRUMs vollzieht und erst dann als abgeschlossen gelten kann, wenn die Entwicklungsziele erreicht sind.

DevSecOps - heute ein Muss

Indem heute zunehmend Cloud-Anwendungen gefragt sind und Anwendungen wie autonomes Fahren und IoT bzw. Industrial IoT immer wichtiger werden, rückt die Weiterentwicklung des DevOps-Ansatzes in Richtung von DevSecOps in den Fokus. Sicherheit ist dabei nicht etwas, was nach der abgeschlossenen Softwareentwicklung als Add-on draufgesattelt wird, vielmehr wird sie von Anfang an mitgedacht.

Scaled Agile Framework(R) (SAFe(R))

Agile Softwareentwicklung ist exzellent für die Anforderungen von Einzelteams angepasst. Allerdings erweist sie sich oft als zu 'eng' für breiter angelegte, oft unternehmensweite Projekte. Ganz besonders gilt dies für Unternehmen, die ihre gesamten Projekte und Prozesse agil transformieren wollen. Für diese Art von Anforderungen wurden skalierbare und vertrauenswürdige Ansätze wie das Scaled Agile Framework(R) (SAFe(R)) entwickelt.

Genauer: Da ein Umdenken in der Projektorganisation meist nicht auf einen Bereich begrenzt bleibt, sondern das ganze Unternehmen samt Unternehmenskultur umfasst, gewinnen skalierbare Ansätze innerhalb der modernen Software-Architektur und Anwendungsentwicklung zunehmend an Bedeutung.

SCRUM Teams as a Service

Oft verfügen Unternehmen nicht über ausreichende eigene Expertise in Sachen SCRUM und agile Softwareentwicklung. Auch ist der IT-Markt aktuell personell sehr ausgedünnt. Besonders für Unternehmen im Umbruch bieten sich daher externe SCRUM Teams as a Service an, die ihre Kunden auf die agile Schiene setzen und sie mit ihrer Erfahrung und ihrem Know-how begleiten und unterstützen.

Jetzt nichts mehr verpassen! Abonnieren.