Vorgehensmuster für Softwarearchitektur Flashcards
Szenarien:
Problemstellung: Wie drückt man Qualitätsanforderungen aus, um (1) Architekturarbeit sinnvoll zuleiten und (2) Stakeholder gerecht zu kommunizieren?
Qualitätsszenarien (oder kurz „Szenarien“) sind konkrete Aussagen darüber, wie sich das System bei gewöhnlicher Benutzung oder in Ausnahmefällen verhalten soll. Dabei steht nicht Funktionalität, sondern Qualität im Fokus: Wie oft, wie schnell, wie schön oder wie gut abgesichert muss bestimmte Funktionalität verfügbar sein? Qualitätsmerkmale wie Zuverlässigkeit, Effizienz oder Sicherheit werden also beispielhaft genauer beschrieben
Szenarien: Warum?
- Szenarien bilden eine hervorragende Grundlage zur Bearbeitung von Architekturentscheidungen. Durch die konkrete Formulierung lassen sich die architekturrelevanten Aspekte eines Qualitätsmerkmals besser verstehen und gezielt bearbeiten
- Szenarien machen die Vorstellungen zu Qualitätsaspekten des Systems transparent. So findet ein Abgleich zwischen Kunden, Benutzern, Entwicklern, Betrieb und anderen Stakeholdern statt, der sonst erst viel später möglich ist
- Szenarien bilden die Basis, um Softwarearchitekturen sinnvoll bewerten zu können. In einem iterativen Prozess führt Architekturbewertung zu besseren Entscheidungen mit breiterer Akzeptanz.
- Szenarien unterstützen dabei, Kompromisse zu kommunizieren und aufzulösen. Beschreibt man die Auswirkungen von Architekturentscheidungen mit Szenarien, werden sie für fachliche Ansprechpartner greifbar. So sind sinnvolle Abwägungen möglich, wo vorher nur „Rauschen durch technische Aussagen“ war
- Szenarien können relativ einfach in Akzeptanztestests verarbeitet werden (und sind ein wichtiger Schritt bei der Übersetzung zentraler Qualitätsanforderungen in automatisierte Tests.
Szenarien: Wie formulieren
Gute Szenarien sind für fachliche Stakeholder verständlich und für Umsetzer richtungsgebend
Szenarien kurz halten.
Als Daumenregel für die Länge eines Szenarios gelten ein bis drei Sätze. Lange Szenarien deuten darauf hin, dass Qualitätsaspekte vermischt sind
Szenarien aktiv formulieren.
Vermeiden Sie Wörter wie „sollte“, „müsste“ und „könnte“, indem Sie mit dem Szenario den Zustand nach Systemfertigstellung beschreiben. Durch die aktive Formulierung werdenSie konkreter und die übrigen Teile des Szenarios sind leichter zu formulieren.
Szenarien fachlich relevant halten. Driften Sie nicht zu stark in Richtung technischer Formulierung ab. Auslöser und Antwortmüssen von Stakeholdern auf Kundenseite verstanden werden. Anderenfalls verlieren Szenarien ihren Kommunikationszweck und Sie werden tendenziell zu viele Szenarien finden, um sie noch sinnvoll handhaben zu können
Szenarioarten und abgedeckte Qualitäten
Nicht nur in Anforderungs ¬Workshops, sondern auch während der Architekturarbeit und be¬sonders in der Umsetzung werden Fragen und Probleme offensichtlich, die qualitative Aspekte betreffen.
Szenarien: Qulaitätsbaum
Um erhobene Szenarien abzulegen, bietet sich ein Qualitätsbauman. Er ordnet Qualitäts¬szenarien dem jeweils bestimmenden Qualitätsmerkmal zu.
In iterativen Vorhaben stellt der Qualitätsbaum eine Art Speicher für qualitative Anforderungen dar, aus dem sich Backlogsund Kanban¬ Spalten bedienen können
Szenarien: Zusammenfassung
Szenarien bilden die Grundlage für iterative Arbeit an der Architektur. Sie werden ininitialen Anforderungs¬ Workshops bei Anforderungspflege ¬Workshops oder durch Erkenntnisse in der Umsetzung gefunden.
Verarbeitet werden Szenarien, z.B. als Architekturarbeit im Backlog oder Architekturarbeit auf Kanban. Szenarienkategorisieren hilft bei der Übersetzung in diese Konzepte. Durch die Sichtbarkeit, die Szenarien der qualitativen Anforderungsseite geben, ist es einfacher, Architekturarbeit vom Rest zu trennen und gemeinsam zu entscheiden wird einfacher. Wiederkehrende Reflexion ist meist szenariogetrieben und erhöht den Kommunikationsfaktor im Team weiter.
Aber selbstüber die Grenzen der Umsetzungsteams hinweg sind Szenarien wichtige Kommunikationstrei-ber. Sie sind Teil der Architekturwand eines Informativen Arbeitsplatzes und spielen auch ein Rolle, wenn Sie Stakeholder involvieren. Qualitätsszenarien sind konkrete Beispiele für qualitative Anforderungen und damit eine gute Basis, um qualitative Eigenschaften zu testen oder Qualitätsindikatoren zu nutzen.
Architekturarbeit auf Kanban
Problemstellung:
Wie kann die Architekturarbeit von der Idee bis zur Auslieferung optimiert werden, so dass ein mit Umsetzungsaufgaben verwobener, stetiger und sichtbarer Fluss von Aufgaben entsteht?
Sie setzt zentrale Ideen von Lean um.
Auf Softwareentwicklung übertragen, ermöglicht Kanban die Visualisierung des Entwicklungsprozesses und von eventuellen Engpässen (z.B. im Systemtest). Entscheidend ist der sogenannte „Pull“-Ansatz : Aufgaben werden nicht verteilt oder weitergeschoben, sobald sie
fertig sind, sondern von nachfolgenden Schritten gezogen, sobald sie bereit sind. Bevor dieser „Pull“ erfolgt, liegt die Aufgabe noch beim vorherigen Arbeitsschritt. Limitiert man nun die maximale Anzahl an Aufgaben, die ein Arbeitsschritt gleichzeitig „bearbeiten“ darf, gibt es
einen interessanten Effekt: Stockt die Verarbeitung in einem Arbeitsschritt weiter hinten, wird über kurz oder lang jeder Schritt davor voll laufen und ebenfalls stocken Die Lean Praktik des „Stop and Fix“ (halte an und repariere) wird so effektiv umsetzbar.
Littles Law
Dieses Gesetz von John D.C. Little[Lit61] beschreibt einen Sachverhalt der Warteschlangentheorie, wonach die durchschnittliche Menge an Elementen in einem Warteschlangensystem (L) gleich der durchschnittlichen Verweildauer im System (W) mal der durchschnittlichen Ankunftsrate () ist
L = (epislon) W
Das klingt erst mal logisch. Wenn Sie jeden Monat mit einer neuen Fernsehserie (oder einer Folgestaffel einer bekannten Serie) starten und durchschnittlich drei Monate benötigen, um eine Staffel abzuschließen, haben Sie zu jeder Zeit drei aktuelle Fernsehserien, die Sie aktivschauen. Das gilt unabhängig von der Art und Weise, wie Sie Serien schauen oder in welcher Reihenfolge Sie sich durch die Serien „arbeiten“. Spannend wird es nun, wenn man an den Parametern dreht. Steigt beispielsweise die Anzahl an Serien, die Sie jeden Monat starten(weil Ihre neue Freundin einen Netflix¬ Account mitbringt und nun mehr Angebot vorhanden ist – bzw. eine Meinung mehr vorhanden ist, was Sie sich anschauen müssen, haben Sie mehrgleichzeitig aktive Serien zu meistern. Bei zwei gestarteten Serien pro Monat wären es zum Beispiel sechs gleichzeitig geschaute Serien. Um dieser Last gerecht zu werden, müssten Sie die doppelte Zeit mit dem Serienkonsum verbringen. Wollen Sie das nicht, müssten Staffeln mit weniger Folgen her
Auf die Softwareentwicklung übertragen, ergeben sich daraus wichtige Erkenntnisse:
Teilen Sie Aufgaben in kleinere Häppchen (oben wären es Staffeln mit weniger Folgen),sinkt die Bearbeitungszeit und damit die Verweildauer (W). Als Folge können Sie in dergleichen Zeit, mit den gleichen Kapazitäten mehr dieser Häppchen umsetzen (höhere Ankunftsrate). Es entsteht ein schnellerer Fluss von umgesetzten Anforderungen mit häufigerer Rückmeldung aus der Entwicklung. Definieren Sie folglich kleine Aufgabenpakete
Beschränken Sie die Arbeit, die gleichzeitig in Bearbeitung sein darf (L– in obigem Beispiel würden Sie sich Netflix verweigern und bei drei gleichzeitig geschauten Amazon Prime Serien Staffeln bleiben), können Sie auf Basis Ihrer durchschnittlichen Bearbeitungszeit (W– oben waren es drei Monate) genau bestimmen, wie viele Anforderungen Sie durchschnittlich annehmen können (– eine Staffel pro Monat). Das gibt Planungssicherheit und macht verbindliche Aussagen zu Umsetzungszeitpunkten einfacher. Limitieren und planen Sie folglich die gleichzeitig in Bearbeitung befindliche Arbeit (engl. work in progress– WIP). Kanban beinhaltet mit Pull Prinzip, Stop&Fix, WIP Limits und kleinteiligen kanban all diese Aspekte und ist auf jeden Fall einen Blick wert, wenn Sie stetige Arbeit an einem Produkt odereiner Plattform leisten.
Kanban Board
Die Kanban ¬Tafel beinhaltet keine Architekturspalte. Stattdessen wird Architekturarbeit über entsprechende Kanban abgebildet.
Wenn Sie Ideen analysieren, können Sie über die Kartenfarbe oder form kenntlich machen, um welche Art von Anforderung es sich handelt. So lassen sich auch die Szenariokategorien abbilden.
Kanban hat keinen fixen Takt wie ein iteratives Vorgehen. Stattdessen werden stetig kanban abgearbeitet. Sie bilden auch die Granularität für Feedback. Wird eine Karte von der Spalte Akzeptanztest gezogen, werden entsprechende (nicht funktionale) Tests und Metriken aufgesetzt, ausgeführt und idealerweise in den Build integriert. Feedback ist verfügbar, sobald die Karte über die Tafel gewandert ist und nicht erst, wenn eine Iteration zu Ende ist. Die vorgestellte integrierte Architekturarbeit ohne separate Architekturspalte hat meiner Meinung nach einige Vorteile.
Flexibilität: Nicht jede Anforderung braucht Architekturarbeit und Limits auf Architekturarbeit behindern in der Praxis öfter, als sie helfen. Trotz der fehlenden Spalte ist Architekturarbeit über die Kartenfarbe oder form sichtbar
Lebenszyklus: Architekturarbeit ist nicht an einer Stelle und in einer Spalte zu erledigen, sondern beinhaltet ähnliche Aspekte wie andere Entwicklungstätigkeiten. Architektur¬ Kanban sollten nicht nur bearbeitet, sondern deren Lösung auch analysiert, kommuniziert und verifiziert(getestet) werden. All diese Tätigkeiten in einer Spalte abzubilden, ist wenig transparent
Kleinteiligkeit: Kanban beschreibt den dynamischen Fluss von kleinteiligen Aufgaben mit schneller Rückmeldung. Eine eigene Architekturspalte würde diesen Fluss behindern (siehe voriger Punkt zu Lebenszyklus) und suggeriert leider zu oft klassische Verhältnisse. Teams und Projekte, die noch nicht vollkommen an dynamische und agile Arbeit gewöhnt sind, bekommen mit der Architekturspalte
einen „Ankerpunkt“ für wasserfallähnliche Konzeptphasen. Kanban ¬Tafeln werden statischer und einzelne Kanban verweilen lange in der Spalte, bevor sie weitergeschoben werden. Durch das Entfallen der Spalte setzt man meiner Erfahrung nach ein deutlicheres Zeichen und fördert Umdenken hin zu einer integrierten Architekturdisziplin
Zusammenfassung: Kanban mit Architekturarbeit
Kanban verarbeitet Szenarien als Architekturanforderungen, die über Szenarien kategorisieren vorbereitet wurden. Die Ideen¬ Spalte kann über initiale Anforderungsworkshops befüllt werden. Ideen wandern von neu nach analysiert, wenn Anforderungspflege¬ Workshops stattfinden. Die wichtigsten Anforderungen werden dann Stück für Stück als Features übernommen. Dabei sollte der letzte vernünftige Moment beachtet werden. In der Spalte Architekturkommunikation kommt wiederkehrende Reflexion zum Einsatz, um Entscheidungen zu bewerten und gemeinsam zu treffen. In der Spalte Akzeptanztests sollten Siequalitative Eigenschaften testen Qualitätsindikatoren nutzen und Code mit Architektur verbinden. Die Verwebung von qualitativen und funktionalen Anforderungen auf der Kanban ¬Tafel macht Architekturentscheidungen treffen ( und gemeinsam entscheiden besser umsetzbar, als das mit einer eigenen Architekturspalte möglich wäre
Der letzte vernünftige Moment
Wann sollte eine architekturelle Fragestellung idealerweise entschieden werden, um (1) unter größtmöglicher Sicherheit zu entscheiden und (2) das Risiko einer Fehlentscheidung zu minimieren?
Entscheidungen werden dabei möglichst spät getroffen, auch wenn das Problem selbst schon früher bekannt ist. Hören Sie dieses Konzept zum ersten Mal, klingt es vielleicht eigenartig oder gewöhnungsbedürftig. Die zugrunde liegende Real¬ Options¬ Theorie hat aber überzeugende Argumente.
Wann wissen Sie das meiste über das zu entwickelnde Produkt oder System? Wahrscheinlich wenn es ausgeliefert und in Benutzung ist. Mit diesem Wissen könnten Sie das gleiche Problemwohl in der Hälfte der Zeit lösen. Sie würden weniger Mitentwickler benötigen und manche Entscheidungen anders treffen. „Hinterher ist man immer klüger“, hört man Leute sagen. Die Klugheit kommt allerdings nicht auf einen Schlag ganz am Ende der Entwicklungstätigkeit. Sie wächst über den gesamten Zeitraum der Softwareerstellung.
Im letzten Muster haben wir architekturrelevante Fragestellungen als die weittragendsten und risikoreichsten technischen Fragestellungen des Vorhabens definiert.
Wasserfallvorgehen durch iterative Ansätze abgelöst wurden. Es steckt Wert darin, zu warten wenn Entscheidungen Unsicherheit beinhalten. Diese zeitliche Verzögerung dient dem Erkenntnisgewinn und ermöglicht bessere Entscheidungen. Die meisten Entscheidungen lassen sich nicht beliebig weit nach hinten schieben. Irgendwann gibt es einen Punkt, an dem eine Entscheidung spätestens getroffen werden muss, um negative Effekte zu vermeiden. Diesen virtuellen Moment nennen wir den „letzten vernünftigen Moment“. Illustriert, wie Fragestellungen mit der Zeit zu ihrem individuellen wandern
Wie finden Sie den LRM?
Der letzte vernünftige Moment ist nicht einfach zu finden und nicht im Voraus mit Datumfestlegbar. In der Praxis brauchen Sie Indikatoren, die Ihnen anzeigen, dass eine baldige Entscheidung notwendig wird
- Optionen haben Wert.
- Optionen haben ein Ablaufdatum.
Die erste Aussage zeigt noch einmal auf, dass es wertvoll ist, Optionen zu haben – sich also nicht früh festzulegen. Die zweite Aussage ist für die LRM ¬Findung die interessantere. Architekturentscheidungen sollten spätestens zu jenem Zeitpunkt getroffen werden, an dem mindestens eine wichtige Entscheidungsalternative wegbricht bzw. eine Option „abläuft“.
Will man z.B. mit mehreren Teams in die Implementierung starten, ist die Plattformentschei¬dung nahe am letzten vernünftigen Moment. Das Optionsfenster für jede andere Plattformschließt sich. Mögliche Indikatoren für eine bald nötige Entscheidung wären:
- Wird jetzt nicht entschieden, entsteht eine De¬facto ¬Entscheidung, die schwer zurückzu¬rollen ist (wie eben im Plattformbeispiel).
- Wird jetzt nicht entschieden, ist die Umsetzung einer Alternative bis zu einem festen Termin nicht mehr möglich.
- Die Unsicherheit belastet bei anderen Entscheidungen (potenziell in anderen Teams).
- Es gibt Abhängigkeiten zu Hardware, Lizenzierung, rechtlichen Bestimmungen oder an¬deren Rahmenbedingungen, die eine Entscheidung nötig machen.
- Die Unsicherheiten bei den noch vorhandenen Optionen sind vernachlässigbar, die Optionenhaben also keinen Wert mehr
Lernräume schaffen
Zwischen dem Erkennen der Fragestellung und dem letzten vernünftigen Moment öffnet sich ein Lernfenster
In diesem Fenster steigt das Wissen über das Problem und wichtige Rahmenbedingungenstetig. Sie sollten versuchen, diesen Lernzeitraum so groß wie möglich zu machen und aktiv zu nutzen. Der letzte vernünftige Moment für eine Entscheidung lässt sich beeinflussen. Sie könnenIhr Lernfenster etwa mit folgenden Maßnahmen vergrößern:
fachliche Umpriorisierung,
Abstraktion,
parallele Umsetzung mehrerer Alternativen (Set¬Based Design),
flexible Austauschformate,
Einsatz von Standards (oder nichtinvasiven Technologien),
Splitten von Entscheidungen (in dringliche und andere Aspekt
Die fachliche Umpriorisierung ist die technisch einfachste Variante: Sie machen eine archi¬tektonische Fragestellung weniger dringend, indem Sie darauf aufbauende Anforderungen weiter nach hinten schieben.
Als Beispiel zur Abstraktion können wir die Datenbankentscheidung aus dem Projektbeispielbetrachten: Durch die Kapselung der Datenbanktechnologie hinter einer DAO¬ Schicht ist die eigentliche Technologieentscheidung weniger dringend. Die fachliche Implementierung ist von den Datenbankzugriffen entkoppelt und muss bei der Datenbankentscheidung nichtangepasst werden. Die Optionen bleiben so länger greifbar.
Set Based Design 1
Set Based Deisgn 2
Gerade genug Architektur vorweg
• Aufwendigere Planung zu Beginn ist keine Garantie für geringe Umbauaufwände im Nachhinein – die Darstellung vereinfacht hier ein wenig. Tatsächlich können eine ausgedehnte Analysephase zu Beginn und eine dadurch verzögerte Implementierung von ersten Lösungs-teilen zu verzögertem Erkenntnisgewinn und langsamem Lernen führen. Falsche Annahmen oder sich ändernde Anforderungen sind nie auszuschließen und erst in der Konkretheit von Programmcode und Tests lernen Sie, was wirklich funktioniert und was nicht. Scott Ambler macht den Punkt deutlich, indem er die Nutzenkurve für die Vorabmodellierung ab einem gewissen Aufwand in negative Bereiche laufen lässt. Die tatsächlichen Aufwände für spätere Umbauten sind technologie- und vorgehensabhängig. Änderungen an .NET ¬oder Java -Applikationen oder der Ersatz von nicht invasiven Standard ¬Frameworks auf diesen Plattformen sind weniger problematisch als ähnliche Änderungen an ABAP ¬oder gar Cobol-Programmen. Auch die Toolunterstützung und Entwicklungsumgebungen sind dabei ausschlaggebend – Eclipse unterstützt etwa Umstrukturierungen, Extraktionen und Umbenennungen sehr gut, SAP Editoren haben hier weniger zu bieten.
Zusätzlich machen Entwicklungspraktiken wie testgetriebene Entwicklung (TDD) oder Praktiken aus Software Craftsmenship spätere Anpassungen weniger schmerzvoll – damit wird vorab geleistete Architekturarbeit auf einigen Ebenen weniger wertvoll.
Was mindestens? Gerade genug Architektur vorweg
Unabhängig von der Komplexität des Vorhabens sollten Sie (1) die fachliche Zielsetzung und zentrale Rahmenbedingungen architekturell aufbereiten und (2) die Voraussetzungenfür eine gemeinsame Entwicklungsarbeit schaffen. Der erste Teil (Ziele und Rahmen) ist stark von der Produktvision und den Ergebnissen aus initialen Anforderungs¬Workshops(→Abschnitt3.1) getrieben, motiviert das Warum des Vorhabens und schafft die Vorausset¬zung für Architekturarbeit. Der zweite Teil (Entwicklungsvoraussetzungen) baut auf dieses Verständnis auf und beinhaltet grundlegende Architekturentscheidungen, ohne die ein Start in die Realisierung nicht effektiv möglich ist. Beides wird mit dem Begriff Architekturvisionin Verbindung gebracht
Halten Sie die Architekturvision immer kurz (wenige Seiten oder Flipcharts) und achten Sie auf Klarheit und Verständlichkeit.
Systemkontext: Der Systemkontext dient der Abgrenzung des Systems. Er zeigt das eigene System als Blackbox, umgeben von Benutzern und Fremdsystemen, mit denen direkt kom-muniziert wird. Aus dieser einfachen Darstellung lassen sich viele Qualitätsmerkmale, Rahmenbedingungen und Risiken ableiten
Rahmenbedingungen: Rahmenbedingungen beinhalten technische oder organisatorische Einschränkungen sowie einzuhaltende Konventionen. Es ist wichtig, diese Einschränkun¬gen zu kennen, um sinnvolle Entscheidungen zu treffen und gangbare Wege nicht zu früh auszuschließen
Qualitätsmerkmale: bestimmende qualitative Aspekte des Systems (auch als „nichtfunk¬tional“ bezeichnet, Überblick inBild3.2), priorisiert und in eindeutiger Reihenfolge. Unab¬hängig von konkret bearbeiteten Szenarien(→Abschnitt3.3), gibt eine Liste der Top 3 bis 5Qualitätsmerkmale allgemeine Orientierung in Entwurfsfragen. Sie können allerdings auch schon einige sehr wichtige Szenarien beschreiben, um die Qualitätsziele zu illustrieren.
Fachliche Risiken: Große fachliche Unsicherheiten oder zentrale, noch zu klärende Punktewerden inAbschnitt4.6als Variabilitätsrisiken bezeichnet. Sie sind oft für die Schätzbarkeit eines Systems interessant und sollten früh bearbeitet werden. Die Erstellung des Systemkon-texts und Abstimmung der qualitativen Ziele machen diese Risiken oft sichtbar
Technologien: Der technologische Stack der Anwendung muss und sollte in der Vision nichtvollständig und abschließend festgelegt werden. Einzelne Entscheidungen sind jedoch frühnötig, um mit der Entwicklung starten zu können. Dazu zählen üblicherweise die Plattform, die Programmiersprache(n) oder auch verwendete Komponentenframeworks.
Architekturstil: Der Architekturstil bezeichnet, im engeren Sinn, das eine bestimmendeArchitekturmuster der Anwendung. Kandidaten wären etwa Schichtenarchitektur, Micro¬services, Pipes and Filter oder hexagonale Architektur.
Architekturprinzipien: Architekturprinzipien beschreibe ich inAbschnitt4.7genauer.In der Architekturvision sollten nur einige wenige, grundlegende Prinzipiendefiniertwerden. Kandidaten betreffen den Arbeitsstil (siehe Designpraktiken inAbschnitt2.1.6), Präferenzen bei der Technologieauswahl oder leitende Prinzipien aus der höher liegenden Unternehmensarchitektur.
Grobe Gliederung und Domänenmodell: Je nach Architekturstil kann es sehr interessant sein, früh mit der fachlichen Gliederung des Systems zu starten. In Microservices¬ Vorhaben ist die Domänenanalyse und Aufspaltung des Systems in fachliche Blöcke oder Services sehr zentral. In Schichtenarchitekturen kann das Komponentendesign auch später erfolgen, allerdings ist eine frühe Hypothese als Arbeitsmodell fast immer ratsam.
Architekturentscheidungen treffen
Welche Tätigkeiten sind nötig, um Architekturentscheidungen effektiv zu treffen, und wie werden sie zeitlich eingeordnet und wahrgenommen
Architekturentscheidungenbetreffen weite Systemteile und viele Entwickler. Vom Erkennender Fragestellung bis zur umgesetzten und eingehaltenen Architekturentscheidung brauchtes folglich Zeit. Im Sinne desletzten vernünftigen Moments möchten Sie diese Zeitspanne möglichst groß halten und aktiv nutzen. Sie lernen, Zusammenhänge zu verstehen, suchen und bewerten Lösungsoptionen, bauen eventuell nötiges Wissen auf, treffen eine (vorläufige) Entscheidung, kommunizieren sie, setzen um und reagieren auf die Erkenntnisse aus der Umsetzung. Wie sehen, ist der eigentliche Entscheidungszeitpunkt nur ein kleiner Teil des Entscheidungsprozesses bei Architekturfragen. Zu diesem Zeitpunkt sind nicht alle Unsicherheiten ausgeräumt, die teilweise Umsetzung im Lernraum (davor) und auch die Implementierung in der Breite (danach) sind wichtig, um Entscheidungen zu festigen.
Ausgangspunkt für Architekturentscheidungen sind Fragestellungen, wie grob formulierte Probleme oder Potenziale, eventuell konkretisiert mit Szenarien oder technischen Schulden.
Gerade bei größeren, risikoreichen Entscheidun¬gen sollten Sie diese Tätigkeiten planen, um sie aufeinander abgestimmt und rechtzeitig auszuführen. Grundvoraussetzung dafür ist ein gutes Verständnis, welche Aktivitäten bei Architekturentscheidungen nötig sind und wie sie ablaufen – das ist Thema dieses Musters. Darauf aufbauend kann die Planung von Architekturentscheidungen auch in die Release¬ Planung integriert werden.
Aktivitäten bei Architekturentscheidungen: Architekturentscheidungen treffen
Wie jeder kreative Prozess, lässt sich auch die Entscheidungsfindung bei Architekturfragen nicht einfach sequentiell beschreiben. Dafür sind die Fragestellungen, die Sie im Rahmen der Architekturarbeit bearbeiten, zu unterschiedlich und Ihr Kontext (Unternehmen, Systemlandschaft, Projekt etc.) zu einzigartig13. Als grobe Richtlinie können Sie den Entscheidungsprozess in zwei Phasen unterteilen: vor der Festlegung und nach der Festlegung. Der Zeitraum vor wichtigen Festlegungen sollte, im Sinne des letzten vernünftigen Moments, möglichst lang sein, um die bestmögliche Problemkenntnis zu besitzen. In diesem Lernraum können bereits Anforderungen in der echten Umgebung umgesetzt werden. Die beste Erkenntniskommt fast immer aus der Realität. Nach der (vorläufigen) Festlegung sollte die Zeit, bis belastbares Feedback aus der Breite verfügbar ist, möglichst kurz sein, um den Schaden einer Fehlentscheidung zu minimieren. Selbst diese einfache Zweiteilung muss jedoch nicht immer gelten, wie die Praktik des Set Based Design zeigt
Release-Planung mit Architekturfragen
Wie werden Abhängigkeiten, Risiken und die Dringlichkeit von architekturellen Fragestellungen geplant berücksichtigt, ohne den Prozess der „normalen“ Umsetzung von Funktionalität unnötig aufzublähen?
Architekturentscheidungen treffen beschreibt die Anatomie einer Architekturentscheidung, ohne ein bestimmtes Vorgehen vorauszusetzen.
Releases bieten eine für den Kunden wertvolle Erweiterung des Systems und werden meist über mehrere Iterationen hinweg entwickelt.
Aus Architektursicht ist die Release Planung spannend, weil sie beim Gruppieren von Anforderungen (Stories) und Zuordnen von Features zu Releases Abhängigkeiten betrachtet: Welche Anforderungen gehören zusammen? Welche müssen früher umgesetzt werden, weil andere Anforderungen darauf aufbauen?
Das passt gut zu Architekturarbeit, wo der Zeitpunkt der Bearbeitung, Entscheidung und Umsetzung sehr wichtig ist. Außerdem betrachtet die Release Planung mehr als eine einzelne Iteration und kann damit die Aktivitäten größerer Architekturentscheidungen gut sortieren?
Release-Planung mit Architekturfragen
Als Grundlage für Architekturarbeit habe ich Qualitätsanforderungen (Szenarien)und technische Schulden identifiziert.
• Qualitätsanforderungen
Sind sehr ähnlich zu funktionalen Anforderungen – ihre Umsetzung oder Einhaltung verursacht Kosten (die typischerweise mit der Zeit stark steigen), der Wert ist von Stakeholdern bestimmbar und kann bei späterer Umsetzung abnehmen oder zunehmen (z.B. Skalierbarkeit).
• Technische Schulden:
Die Beseitigung der Schuld verursacht Kosten (die typischerweise mit der Zeit steigen), der Wertergibt sich aus der Ersparnis bei künftigen Feature ¬Umsetzungen oder aus dem Qualitätsgewinn, wenn die Schuld beseitigt ist
Der Release ¬Plan steht zwischen der Anforderungsliste und einzelnen Iterationen. In Ite¬rationen arbeiten Sie Aufgaben ab, die den Features und Architekturgruppen des Release entnommen sind. Architekturaufgaben können Sie sich mit Hilfe der im letzten Abschnittbeschriebenen Aktivitäten überlegen – Fragestellung und Kontext sind schon teilweise in der Release¬ Planung betrachtet worden, den Rest können Sie in die Iterationen schieben und gemeinsam bearbeiten. Bei größeren Fragestellungen können Sie die Aufgaben auch übermehrere Iterationen verteilen: In der ersten Iteration suchen Sie Optionen und erstellenvielleicht einen Prototypen, danach setzen Sie um, in der dritten Iteration stabilisieren und verfeinern Sie die Lösung.
Mit dem Zwischenschritt der Release¬ Planung lassen sich Abhängigkeiten gut bewältigen, technische Schulden planen und in Grenzen halten, sinnvolle Auslieferungen erreichen und der letzte vernünftige Moment wird leichter eingehalten. Ob Sie Releases planen oder sich direkt aus der Anforderungsliste bedienen, ist eine Frage der Aufgabe. In der Web¬entwicklung mit praktisch fixem technologischen Unterbau sind Releases eher dynamisch, kleinteilig und ungeplant. Im Umfeld von Gerätebau oder in großen Systemlandschaften ist Release ¬Planung sicher sinnvoller.
