Die 5 Merkmale zeitgemäßer Software-Architektur

Entwicklung, Beschaffung und Anpassung von Softwarelösungen setzt laufende konzeptionelle Arbeit voraus. Dabei sind die Maßstäbe von der kleinsten Hilfsanwendung bis zum umfassenden Shop- oder ERP-System ähnlich. Welche Merkmale machen eine Software-Architektur zeitgemäß?

„Zeitgemäß“ nennt Stefan Toth, geschäftsführender Gesellschafter der Softwareberatung Embarc, Implementationen, die konkrete Bedürfnisse der Anwender funktional ausreichend, in deren betriebliche Abläufe eingepasst und gleichzeitig ressourcenschonend erfüllen. Auf der Basis dieser Prämisse schlägt er in seinem Buch Vorgehensmuster für Software-Architektur die nötigen Verfahrensmodelle vor und leitet zu deren Anwendung an. Im IT-Channel von buchreport.de erklärt er die fundamentalen Prinzipien, an denen sich Entwicklungsteams orientieren sollten.

Durch Anforderungen getrieben

Wenn Sie eine fachliche Methode ausimplementieren oder ein neues Feld im User Interface vorsehen, orientieren Sie sich an Wünschen und Anforderungen des Kunden. Dasselbe sollten Sie tun, wenn Sie Technologien auswählen oder Fremdsysteme anbinden. Was auch immer die grundlegenden Fragestellungen in Ihrem Fall sind: Lassen Sie sich von Anforderungen leiten.

Qualitätsanforderungen kommt dabei eine besondere Bedeutung zu. Sie beschreiben die nichtfunktionalen Aspekte der zu erstellenden Lösung, also wie eine Funktionalität bereit­gestellt werden soll. Soll die Funktionalität ohne Unterbrechung zur Verfügung stehen, sind Zuverlässigkeit und Verfügbarkeit wichtig. Wollen wir in Zukunft mehr Benutzer mit unserer Funktionalität beglücken, ist Skalierbarkeit spannend. Wollen wir verhindern, dass Unbefugte heikle Funktionalitäten nutzen, ist Sicherheit ein Thema. Diese Qualitätsmerkmale beziehen sich oft auf weite Systemteile oder sogar das Gesamtsystem. Zuverlässigkeit lässt sich nicht durch eine neue Klasse oder Komponente sicherstellen, die gesamte Anwendung und deren Basis müssen entsprechenden Prinzipien gehorchen.

Qualität ist somit meist querschnittlich und betrifft viele bis alle Entwickler. Wir erreichen Qualitätsmerkmale durch den Einsatz der richtigen Technologien, Plattformen, Frameworks und Muster oder die breite Adaptierung von Arbeitsweisen. Das ist grundlegende Arbeit am Fundament. Entsprechende Entscheidungen sind weitreichend und oft aufwendig in der Umsetzung. Wir sind damit mitten in der Architekturdomäne und es ist wenig überraschend, dass Qualitätsanforderungen als die Architekturanforderungen gesehen werden.

Vom Aufwand her dem Problem angemessen

Stellen Sie sich ein neu zu entwickelndes Produkt vor, das auf einem bekannten Technologie­stack aufsetzt. Es gibt ein passendes, unternehmensspezifisches Applikationsframework, das einzige Umsetzungsteam hat bereits ähnliche Produkte gebaut und kennt die Domäne. Die zeitliche Planung ist realistisch und der Aufwand ist überschaubar. Dieses Vorhaben kommt wohl mit weniger Architekturaufwänden aus als ein Großprojekt, das sich um die Umsetzung einer neuartigen Flugsicherungssoftware kümmern soll. Im ersten Kontext ergeben sich wahrscheinlich weniger risikoreiche Fragestellungen. Das Umfeld ist weniger komplex, das zu lösende Problem und der Lösungsweg sind recht gut verstanden.

Im Großprojekt hingegen sind einige Komplexitätstreiber zu finden – Architekturarbeit wird spannender. Abbildung 1 zeigt, wie sich Architekturaufwände und Komplexitätstreiber die Waage halten sollten.

Abb.1: Das richtige Maß für Softwarearchitekturarbeit

Arbeit an der Softwarearchitektur hat das Ziel, gute Entscheidungen zum richtigen Zeitpunkt zu treffen und das Risiko teurer Irrwege zu minimieren. Zu hohe Aufwände für Architektur­arbeit machen die Entwicklung schwerfällig, langsam und aufwendiger als nötig. Erstellen Sie etwa einen Prototypen für eine einfach umzusetzende Anforderung, verzögern Sie die Umsetzung und die damit verbundene Rückmeldung. Ihr Aufwand hat zudem wenig bis keinen Nutzen. Eine solche „Verschwendung“ behindert vor allem in weniger komplexen, dynamischen Projekten und macht Sie starrer als nötig.

Auf der anderen Seite führt zu wenig Arbeit an der Softwarearchitektur zu zufälliger Architek­tur und potenziell zur Verfehlung wichtiger Ziele. In architektonisch risikoreichen Umfeldern muss folglich ausreichend fundierte Architekturarbeit geleistet werden. Wichtig ist die richtige Balance, die sich für jedes Vorhaben anders gestaltet.

Von aktuellen Erkenntnissen zu Zusammenarbeit und Vorgehen beeinflusst

Auch wenn die Wurzeln der Disziplin noch weiter zurückreichen – Softwarearchitektur ist ein Kind der 1990er ­Jahre. Im universitären Umfeld und mit großer finanzieller Unterstützung des amerikanischen Verteidigungsministeriums wurden Muster, Sprachen und Methoden erarbeitet.

Die Softwareentwicklung hat seit den 1990er ­Jahren viel gelernt. Agile Softwareentwicklung, Lean Development oder auch die Organisationstheorie beinhalten viele Erkenntnisse zu Zusammenarbeit, Komplexität und Dynamik. Auch Softwarearchitektur kann als Disziplin von diesen Erkenntnissen profitieren.

Wie wäre es mit Praktiken, die es ermöglichen, Architekturaufgaben effektiv auf mehrere Schultern zu verteilen? Praktiken, die dynamisches Vorgehen nicht bremsen? Was halten Sie von zeitgemäßen Methoden zur Minimierung von Unsicherheiten und Risiken? Und was wäre, wenn Softwarearchitektur so transparent wird, dass Sie stetig und gewinnbringend mit großen Entwicklungsgruppen oder Stakeholdern zusammenarbeiten können?

Gut mit der Implementierung verzahnt

Abbildung 2 zeigt ein vereinfachtes Bild des generischen Entwicklungsprozesses, den ich in Ab­schnitt 7.2 genauer beschreiben werde. Er zeigt, wie Anforderungen die iterative Entwicklung speisen (Mitte) und der Umsetzungszyklus auslieferbare Software erstellt (rechts). Funda­mentale Fragestellungen wandern vor der Implementierung durch den Architekturzyklus (links) bzw. es liefern Erkenntnisse und Probleme aus der Umsetzung (rechts) die Grundlage für gezieltere architektonische Betrachtungen (links). Ich durchwandere das Bild mit Hilfe eines vereinfachten Beispiels, um die Verzahnung von Architektur und Implementierung zu illustrieren.

Abb.2: Iterative Architekturarbeit mit Umsetzung verzahnt

Sie haben immer wieder wichtige Entscheidungen in der Entwicklung zu treffen. Nehmen wir zum Beispiel an, ein Teil Ihrer Applikation nimmt komplizierte Berechnungen vor. Sie haben den Applikationsteil bereits in Bausteine zerlegt und sehen sich nun mit Anforderun­gen konfrontiert, die hohe Flexibilität im Berechnungsablauf fordern. Da die Fragestellung nicht isoliert betrachtet werden kann und viele Bausteine betrifft, wandern Sie in den Ar­chitekturzyklus aus Abbildung 2.

Um möglichst lose Kopplung zu erreichen, entwerfen Sie einen einfachen Eventmechanis­mus. Sie sehen vor, dass Komponenten einen eigenen Berechnungszustand halten und bei Änderungen an diesem Zustand entsprechende Events feuern. Andere Bausteine können auf diese Events reagieren. Sie erstellen eine kleine Implementierung, die die Möglichkeiten Ihrer Plattform nutzt, um diese Idee umzusetzen. Es funktioniert.

An dieser Stelle definieren Sie die Idee als brauchbare Möglichkeit und entscheiden sich für eine breitere Umsetzung. Sie schaffen damit die Grundlage für Implementierungstätigkeiten, Sie stellen eine kommunizierbare Hypothese auf (siehe Abb.2, oben links). Es handelt sich um den ersten wichtigen Berührungspunkt zwischen Architektur­ und Umsetzungsarbeit.

In der Umsetzung wenden Sie das Konzept auf Ihre Bausteine an (vielleicht nicht sofort auf alle). Sie versuchen, Zustandsübergänge zu definieren, eine produktivtaugliche Implementie­rung für den Zustand selbst zu kreieren und entwerfen fachliche Events. Erst hier haben Sie das Problem annähernd vollständig vor Augen: Sie erkennen, wie kompliziert sich Zustände teilweise zusammensetzen, welche Daten mit den Events übertragen werden müssen und wie diese Lösung mit anderen Konzepten Ihrer Bausteine zusammenwirkt. Haben Sie wichtige Teile umgesetzt, können Sie mit Tests eine Idee vom Laufzeitverhalten bekommen.

Hier ist der zweite wichtige Berührungspunkt zwischen Architektur und Implementierung: die Rückmeldung aus der Implementierung, samt den Erkenntnissen aus Integration und Test (siehe Abb.2, oben rechts). Sie sollten diese Rückmeldung häufig und zeitnah suchen. So prüfen Sie architektonische Hypothesen und minimieren den Raum für Annahmen und Spekulationen. Technische oder konzeptionelle Probleme, die auf Implementierungsebene auftreten, stellen einen sekundären Architekturtreiber dar (neben den weiter oben bespro­chenen Anforderungen). Insgesamt entsteht eine gelebte Softwarearchitektur, die durch die Implementierung nicht verwässert, sondern bereichert wird. Hypothesen erhärten sich über das Feedback aus der Umsetzung und werden nach und nach zu breit akzeptierten Entscheidungen.

Zeitgemäße Softwarearchitektur zeichnet sich durch häufige und schlanke Durchläufe des Architekturzyklus aus. Die Übergänge an beiden Berührungspunkten zur Umsetzung sind gut verstanden und mit geringen Aufwänden verbunden.

Einfach in aktuelle Vorgehensmodelle integrierbar

Immer mehr Projekte adoptieren ein Vorgehen, das mit so wenig Verzögerung wie möglich Richtung Auslieferung von Software drängt. Das Stichwort „agil“ ist so omnipräsent, dass sich viele bereits genervt abwenden, wenn das Thema zur Sprache kommt. Ich verweigere mich jedem religiösen Fanatismus an dieser Stelle und möchte hier auch nicht dogmatisch werden.

Nüchtern betrachtet setzen immer mehr Unternehmen auf agile Praktiken – und es funktioniert. Viele Studien und Umfragen zeigen Erfolge von agilen Projekten. Eine jährlich durchgeführte Umfrage von VersionOne befragte über 5.000 IT­-Mitarbeiter aus Europa und den USA zum „State of Agile Development“. 97 % der Organisationen setzen demnach agile Methoden ein, nur 4% der Unternehmen geben an, keine agilen Initiativen durchzuführen oder zu planen. Scrum ist, wenig überraschend, am weitesten verbreitet und kommt auf 72% Marktanteil unter den agilen Methoden (Varianten mit eingerechnet).

Was bedeutet das für die Disziplin der Softwarearchitektur? Zeitgemäße Softwarearchitektur muss auch in agile Entwicklungsvorhaben passen und sollte die Konzepte, Praktiken und Rollen dieser Ansätze nutzen und annehmen. Sie muss zumindest iterativ leistbar sein und sollte eher erklären, wie Architekturpraktiken in moderne Vorgehensmodelle passen, als diese Vorgehensmodelle mit behindernden oder umständlichen Ergänzungen zu versehen. Wenn 80 % der Projekte Iterationsplanungstreffen abhalten, 53% kontinuierlich integrieren und 61 % Kanban nutzen, sollte Softwarearchitektur zumindest ihren Platz in diesen Praktiken kennen.

Warum Design alleine nicht hilft

Es gibt wichtige Fähigkeiten, die ein guter Entwickler haben sollte. Dazu zählen zweifellos Praktiken und Prinzipien rund um den Entwurf und das Design von Software. Bild 2.3 gibt einen Überblick zu einem Teil der entsprechenden Fähigkeiten und Denkweisen. Sie gehen über das stumpfe „Runterprogrammieren“ von Anforderungen hinaus.

Abb.3: Praktiken, Prinzipien und Haltung für das Design von Software

Es ist durchaus sinnvoll, die Ideen aus Abbildung 3 als eigene Disziplin zu betrachten und entsprechendes Wissen breit zu streuen. Ich nenne diese Disziplin wenig überraschend „Design“. Auch wenn es Überschneidungen mit Softwarearchitektur gibt, sind Design und Architektur nicht deckungsgleich. Betrachten wir die enthaltenen Praktiken und Prinzipien genauer, sind zwei Dinge spannend:

• Mit dem Fokus auf einfache, bewegliche, gut verständliche Lösungen unterstützt Design vor allem ein Qualitätsmerkmal: Wartbarkeit. Architektur hat einen breiteren Fokus auf alle Qualitätsmerkmale und gleichzeitig das Ziel, eventuelle Kompromisse aufzulösen. Der Einsatz von Designpraktiken ist damit selbst eine Architekturentscheidung. Architektur bildet den Rahmen für die Designdisziplin.
• Der Einsatz von Designpraktiken beeinflusst die Struktur der Softwarelösung und hält sie flexibel. Entscheidungen rund um die Funktionalität, die Klassenstruktur und den Interfaceschnitt werden leichter änderbar – und damit weniger architekturrelevant. Gutes Design reduziert die nötige Architekturarbeit. Die Struktur kann potenziell durch Imple­mentierungs-­ und Refactoring­-Zyklen entstehen und wächst über die Zeit, statt zu Beginn vollständig geplant zu werden (modisches Stichwort: „emergentes Design“).

Ich werde den Blick in weiterer Folge auf Architektur fokussieren. Nicht weil Design, wie ich es in diesem Abschnitt abgegrenzt habe, nicht wichtig ist! Design ist essenziell und macht Architekturarbeit sicher einfacher. Gleichzeitig ist die Designdisziplin aber gut verstanden und aktuell viel besprochen. Die Verzahnung mit der Implementierung ist relativ geradlinig und in aktuellen Bewegungen wie „Software Craftsmenship“ ausreichend behandelt.

Warum agiles Vorgehen alleine nicht hilft

Agiler Fokus auf Design

In der agilen Diskussion um Softwarearchitektur nehmen Designpraktiken einen hohen Stellenwert ein. Testgetriebene Entwicklung, Clean Code, Refactoring, Pair Programming oder die Befolgung von Designprinzipien werden breit gepredigt und gelebt. Wie oben besprochen, kann die Struktur von Software damit flexibler gehalten werden, Architekturarbeit wird aber nur teilweise ersetzt. Qualitätsanforderungen wie Sicherheit oder Zuverlässigkeit werden durch Designarbeit nicht adressiert und Entscheidungen zu Platt­formen, Frameworks, Programmierstilen oder Protokollen sind meist grundlegender Natur. Lösungen zu diesen Themen wachsen nicht aus gutem Design, sondern aus Architekturarbeit.

Fehlende Qualitätsanforderungen

Wartbarkeit und Erweiterbarkeit sind häufig die prominentesten Qualitätsmerkmale in agilen Entwicklungsmannschaften. Selbst diese Qualitätsmerkmale werden aber meist nicht in Anforderungen gegossen. Backlogs von Scrum­-Teams sind oft nur mit funktionalen Stories gefüllt – mit Qualitätsanforderungen fehlt die wichtigste Grundlage für Architekturarbeit. Das hat mehrere Konsequenzen:

• Kompromisse zwischen konkurrierenden Qualitäten werden erst spät erkannt und müssen mühevoll aufgelöst werden, wenn bereits viel Programmcode entwickelt wurde. Entsprechende Anpassungen können projektgefährdend sein.
• Architekturanforderungen sind nicht sichtbar. Entwickler können folglich schwerer einschätzen, hinter welchen Backlog­-Einträgen sich Architekturaufgaben verbergen. Die Aufwandsschätzung wird schwieriger und es ist manchmal nur zu raten, ob man das nötige Know­-how hat, um sich bestimmte Aufgaben zu nehmen und zu bearbeiten.
• Die Kommunikation ist unfokussierter. Qualitätsanforderungen sind querschnittlich, Architekturentscheidungen betreffen viele Projektmitglieder. Sie müssen getroffene Entscheidungen breit kommunizieren und Feedback am Weg zur Entscheidung wäre nicht verkehrt. Wenn Sie diese Fragestellungen nicht erkennen, können Sie nicht gezielt zusammenarbeiten, die Kommunikation enthält viel Rauschen. Größere Projekte oder Produktentwicklungen zerbrechen dann unter zu hohem Kommunikationsdruck oder treffen verteilte, integritätsbedrohende Entscheidungen, die schwer zurückzunehmen sind.

Die Reaktion auf diese Phänomene ist häufig alles andere als agil. Ich habe gesehen, wie „agile“ Projekte Architektur großspurig wiedereinführen, eigene Architekturabteilungen wiederbeleben und dazu übergehen, wieder früh zu planen bzw. harte Governance auf Ar­chitekturvorgaben zu setzen. Die Muster in diesem Buch zeigen, wie es anders geht.

Mit freundlicher Genehmigung des Carl Hanser Verlags.

Stefan Toth: Vorgehensmuster für Softwarearchitektur. Kombinierbare Praktiken in Zeiten von Agile und Lean.

Aktualisierte und erweiterte Auflage 2019.

308 Seiten. Flexibler Einband. E-Book (PDF) inside. EUR 34,90

E-Book (PDF) EUR 27,99