Software-Architektur gestalten
Der Weg zu ausgewogenen Architekturentscheidungen
Wie treffen Sie Entscheidungen zur Software-Architektur?
- Wie wählen Sie die passende Technologie und Methodik aus?
- Wie kommen Fachlichkeit und Technik in der Architektur zusammen?
- Welche Dokumentation bringt langfristigen Nutzen?
Wanted: Wo ist der Architekt?
Unterschiedliche Blickwinkel:
„Jedes Team entscheidet eigenverantwortlich über seine Architektur.“
„Zentrale Architekturvorgaben sind zwingend erforderlich.“
Unsere Erfahrung:
Architekturkompetenz ist sowohl innerhalb der Projekte als auch unternehmensübergreifend notwendig
Software-Architektur im Projekt existiert nicht für sich allein, sondern ist eingebettet in den Unternehmenskontext. Daher unterstützt sie die strategischen Ziele und passt sich in die Enterprise Architektur und die allgemeine Bebauungsplanung ein. Gleichzeitig benötigen agile, selbstverantwortliche Teams alle Kompetenzen, um die Projektaufgabe effektiv zu bewältigen. Dazu gehört insbesondere Architekturkompetenz, die ihnen hilft die nicht-funktionalen Anforderungen (NFA) sowohl zu erkennen als auch zu erfüllen.
Tatsächlich sind eigenverantwortlich handelnde Teams sehr gut in der Lage, für eine verstandene Fachdomäne eine passende und effiziente Architektur zu erarbeiten. Hierbei gibt es jedoch diverse Stolpersteine, die zu beachten sind. Prinzipiell sollte aber großer Freiraum für eigenverantwortliche Architekturentscheidungen eingeräumt werden.
Allerdings ist es in den seltensten Fällen so, dass einzelne Teams völlig isoliert arbeiten können – im Gegenteil das Projektziel wird nur mit der Integration aller Teilergebnisse erreicht. Und hier kommen dann wieder die übergreifenden Architekturthemen ins Spiel, allen voran Schnittstellen, Datenmanagement, Authentisierung und Security. Daher ist in den meisten Projekten ebenfalls eine übergeordnete Architektursicht notwendig. Architekturleitplanken unterstützen die Standardisierung sowohl im Projekt als auch im Unternehmen. Auf diese Weise können die Mitarbeiter die eingesetzten Technologien beherrschen und das Unternehmen vermeidet einen „Technologiezoo“.
Die Herausforderung liegt darin einen an langfristigen Zielen ausgerichteten Architekturprozess zu leben, ohne Flexibilität und Dynamik in der agilen Entwicklung zu behindern. Dafür sind entsprechende Mechanismen und Plattformen z.B. Architekturgilde, Community of Practice zu etablieren.
How to survive: Stabilität oder Innovation?
Verschiedene Meinungen:
„Never change a running system.
Stabilität benötigt bewährte Methoden und Technologien.“
„Cutting Edge Technologien bringen Produktivität und Zukunftsfähigkeit.“
Unser Ansatz:
Gute Software-Architektur ist maßgeschneidert für das Problem und den Kontext.
Hier gilt es, die richtige Balance zu finden: die zu lösenden Anforderungen sollten die Technologie-Auswahl bestimmen und nicht umgekehrt. „Cutting edge“ kann im Einzelfall sinnvoll sein, wenn dadurch ein klarer Wettbewerbsvorteil oder die Erfüllung wichtiger Ziele erreicht werden kann. Für Stabilität und Nachhaltigkeit ist allerdings ein „State of the Art“ Ansatz empfehlenswert. Dazu gehört eine Software-Architektur mit Technologien, die sich in der Praxis bewährt haben, sowie Open Source Frameworks und deren Best Practices.
Is a fool with a tool still a fool?
Zwei Standpunkte:
„Tools bringen fertige Lösungsbausteine mit. Warum das Rad neu erfinden?“
„Die individuellen Besonderheiten des Projektes sind maßgeblich. Tools sind oft überdimensioniert und teuer.“
Unsere Meinung:
Tools sind vor allem dann hilfreich, wenn sie zum Projekt und zur Methode passen.
Ohne unterstützende Werkzeuge kommt man in einem modernen Softwareprojekt kaum mehr aus. Der Glaube, dass ein bestimmtes Tool den Erfolg eines Projektes garantieren kann, ist jedoch irreführend. Viele Studien belegen, dass vor allem das Anforderungsmanagement und die Form der Zusammenarbeit den Erfolg eines Projektes bestimmen. Daher sollten zunächst die Kernanforderungen und die Methodik erarbeitet werden. Dabei unterstützen Business Function Modeling und proaktives Anforderungsmanagement. Erst danach erfolgt die Auswahl der passenden Tools.
Auch die Lernkurve bei der Einarbeitung in neue Tools sollte nicht unterschätzt werden. Oft kommt es zu Widerständen, wenn Mitarbeiter ihre vertrauten Werkzeuge austauschen sollen. Hinzu kommt die Herausforderung der Integration neuer Tools in die vorhandene Infrastruktur und die Fragmentierung von Informationen:
- Architekturdiagramme in UML finden sich z.B. im Enterprise Architect,
- Schnittstellenbeschreibungen in Alphabet und
- Architekturentscheidungen im Confluence.
Daher gilt vor allem bei der Auswahl von Tools: weniger ist mehr. Große „mächtige“ Werkzeuge lösen scheinbar alle Probleme des Projekts. Aber schwergewichtige Tools bringen meist eine starre Methodik und ein eigenes Vokabular mit, was die Einarbeitungszeit vergrößert und häufig den für das Projekt wirklich sinnvollen Vorgehensweisen zuwiderläuft. Allerdings gilt auch: Ohne Tools geht es ebenfalls nicht – große Vorhaben erfordern entsprechende Werkzeuge.
Ein Beispiel: Will man einen Satelliten in die Erdumlaufbahn bringen, wird man mit Sicherheit ein (mächtiges!) Tool brauchen – wie eine Rakete. Im Vordergrund steht jedoch, die Mission zu planen und das Einsatzgebiet des Satelliten zu definieren – nur so wird er seinen Zweck erfüllen können. Welche konkrete Rakete zum Einsatz kommt, ist eine nachgelagerte Entscheidung – allerdings muss sie zur Mission passen, z.B. stark genug sein, um einen Satelliten in die geplante Umlaufbahn zu bringen.
Also: Zuerst die Ziele verstehen und die Methodik festlegen, danach die Tools. Tatsächlich eignen sich im ersten Schritt auch herkömmliche analoge Werkzeuge wie Papier oder Whiteboard und ein Stift. Auch für die Erstellung eines ersten High Level Daten- oder Objektmodells benötigt man nicht sofort ein Tool. arc42 oder auch iSAQB stellen hier bereits hilfreiche Templates zur Verfügung. Wird es umfangreicher und detaillierter, so unterstützen Business Function Modeling und Agiles Story Mapping. Erst wenn die Methodik gewählt wurde, sollte man dann ein dazu passendes, wenn möglich leichtgewichtiges Tool auswählen.
Wozu Dokumentation? Und wenn ja, wie viel?
Extreme Sichtweisen:
„Einzig der Source Code birgt die Wahrheit, der Rest veraltet ungelesen.“
„Dokumentationsvorgaben sind bis ins kleinste Detail auszuarbeiten.“
Die Wahrheit liegt dazwischen
Zukunftsfähigkeit bedeutet: Wer schreibt, der bleibt.
Dokumentation sollte nicht erstellt werden, um Prozessvorgaben zu erfüllen. Vielmehr dient sie dazu, das Überleben des Produkts und seiner Software-Architektur in der Zukunft zu sichern – es geht also um „Dokumentation mit Nährwert“. Daher ist die Leitfrage: Was ist notwendig und hilfreich, um zu verstehen, wie das System funktioniert? Kompakte und konzentrierte Texte unterstützen Lesbarkeit und Verständnis. Deshalb ist eine Reduktion auf das Wesentliche im Zusammenspiel mit gut lesbarem Code anzustreben.
Source Code alleine ist als Dokumentation nicht ausreichend, da sich so über grundlegende Architektur- und Design-Konzepte kein Überblick gewinnen lässt. Hierfür hat sich bewährt, die Architektur aus mehreren Perspektiven zu beschreiben. Man braucht das Rad nicht neu zu erfinden, vielmehr gibt es Best Practices, wie insbesondere das arc42-Template. Bekannte Kapitel und Begriffe helfen dem Leser, sich schnell zurecht zu finden. Darüber hinaus fungiert ein Template als Checkliste, damit kein relevanter Aspekt vergessen wird.
Neben der Bausteinsicht und den Architekturzielen sollten vor allem die Entscheidungen festgehalten werden, die zur Architektur geführt haben. Denn das Design der Anwendung ist eine Menge von Entwurfsentscheidungen. Insbesondere diese sind festzuhalten, weil sie grundlegend sind für die Frage, warum ein System genau so gebaut wurde, wie es ist.
Schließlich sind die Aktualität und Konsistenz der Dokumentation ein entscheidender Faktor. Wenn hier nicht permanent nachgehalten wird, veraltet sie und verliert so ihre Glaubwürdigkeit – man kann sich nicht mehr auf sie verlassen. Andersherum gedacht, ist eine adäquate Dokumentation ein Health-Check Kriterium, um die Überlebensfähigkeit eines Systems zu bewerten. Daher ist diese regelmäßig ein Prüfpunkt bei Audits.
Who is driving? Technologie oder Business?
Unterschiedliches Verständnis:
„Kompetenz in Infrastruktur und Technologie löst alle Architekturaufgaben.“
„Einzig Fachlichkeit und deren Details bestimmen die richtige Architektur.“
Die Synthese:
Architektur ist Management von Komplexität – fachlich wie technisch.
Ein System in Komponenten zu teilen, reduziert Komplexität und ist somit eine Kernaufgabe der Software-Architektur. Der „richtige Schnitt“ in möglichst lose gekoppelte Bausteine (z.B. Microservices) wird dabei durch die Fachlichkeit bestimmt. Hierzu dienen Methoden wie Business Function Modelling und Domain Driven Design. Die Technologie jedoch entscheidet über die Ausgestaltung der Komponenten und auch über deren nicht-funktionale Eigenschaften. Beide Seiten spielen also eine große und oft gegensätzliche Rolle und die Trade-offs müssen aktiv gemanagt werden
Für das Management der Komplexität und wenn möglich deren Reduktion müssen die relevanten Komplexitätstreiber bekannt sein. Beide Seiten – Fachlichkeit und Technik – tendieren dazu, unnötigerweise Komplexität in das System einzubringen. Die dabei relevanten fachlichen Anforderungen zu identifizieren, ist eine wichtige Aufgabe, die dem Architekten ein Mindestmaß auch an fachlichem Verständnis abverlangt. Ebenso haben die nicht-funktionalen Anforderungen (NFA) wie Stabilität, Änderbarkeit, Betreibbarkeit oder Performance einen großen Einfluss auf die Komplexität.
Bewährte Methoden helfen dem Architekten, Komplexität zu managen. Business Function Modeling strukturiert die Fachlichkeit und ermöglicht bewusste Entscheidungen zu Scope und Funktionalität. Zusätzlich kann eine erste Komponentenstruktur aus einer so erarbeiteten fachlichen Landkarte abgeleitet werden. Domain Driven Design etabliert eine durchgängige Sprache auf allen Ebenen der Architektur und der Implementierung. Architekturziele wie Entkopplung, Kohäsion und Einfachheit helfen, zum richtigen Komponentenschnitt zu kommen. Alle Architekturentscheidungen müssen in ihrem jeweiligen zeitlichen und organisatorischen Kontext verstanden und dokumentiert werden, damit sie auch später noch nachvollziehbar sind. Zusammenfassen lässt sich dies am besten mit einem Zitat von Albert Einstein: Man muss die Dinge so einfach wie möglich machen. Aber nicht einfacher.
