Be Wise Apps
Read in English · Leer en español · Lire en français
Abschnitt 2.8 von 2.8 · Mittelstufe · 22 Min. Lesezeit
Qualitätsmerkmale erheben, priorisieren und abwägen
Videolektion
5 Min. · auf Englisch gesprochen, mit UntertitelnNur anhören (Audio)
Transkript lesen
In dieser letzten Lektion des Kapitels lernen Sie, wie Sie die wichtigen Qualitäten finden, sie gewichten und entscheiden, worauf Sie verzichten.
Bei der Planung eines Familienurlaubs will jeder etwas anderes. Einer will es günstig, eine andere will einen Pool, ein Dritter kurze Reisezeiten. Man kann nicht alles haben. Also setzen Sie sich zusammen, notieren, was jede Person wirklich braucht, stimmen ab, was am wichtigsten ist, und einigen sich, worauf Sie verzichten. Architekten machen dasselbe mit den Qualitäten eines Systems.
Qualitätsanforderungen landen selten in einem Backlog. Man setzt sie voraus, also müssen Sie sie herauslocken. Beginnen Sie bei den Stakeholdern: Kunden geht es um Tempo, dem Betrieb um Wiederherstellung, der Finanzabteilung um Betriebskosten. Geschäftsziele setzen Qualitäten voraus. Die Expansion in drei neue Länder setzt Lokalisierung, Datenresidenz und Skalierbarkeit voraus. Vorschriften schaffen Randbedingungen, über die sich nicht verhandeln lässt. Jeder frühere Ausfall und jede Datenpanne zeigt eine Qualität, die zu ungenau spezifiziert war. Und wenn die Konkurrenz in einer Sekunde lädt, sind zwei Sekunden ein Qualitätsproblem. Messen Sie schließlich das bestehende System. Seine tatsächliche Last und Latenz liefern eine Basislinie, die aus „schneller“ eine Zahl macht.
Qualitäten zeigen sich am besten, wenn Stakeholder einander zuhören. Das ist die Idee hinter dem Quality Attribute Workshop des Software Engineering Institute. Er dauert meist einen Tag, mit fünf bis dreißig Personen, und findet statt, bevor die Architektur feststeht. Die ersten vier Schritte schaffen den Kontext: Vorstellung, die Geschäftsziele, die aktuellen Architekturpläne und die bisher gehörten wichtigsten Treiber. Dann folgt die Arbeit an den Szenarien. Alle schlagen reihum Szenarien vor, und fast gleiche werden zusammengeführt, aber nur, wenn die Vorschlagenden zustimmen. Danach wird abgestimmt. Jede Person erhält Stimmen in Höhe von etwa dreißig Prozent der Anzahl der Szenarien. Knappe Stimmen legen echte Prioritäten offen. Zum Schluss werden die vier oder fünf wichtigsten Szenarien mit allen sechs Teilen vollständig ausformuliert.
Um die Ergebnisse zu ordnen, nutzen Architekten einen Utility Tree. Die Wurzel ist der Nutzen: die Gesamtgüte des Systems. Er verzweigt in Qualitätsmerkmale und dann in spezifische Anliegen wie Bestelllatenz oder Checkout-Uptime. Die Blätter sind konkrete Szenarien, jeweils nach geschäftlicher Bedeutung und technischer Schwierigkeit bewertet: hoch, mittel oder niedrig. Szenarien mit hoch und hoch sind am wichtigsten und am schwierigsten. Hier ist eines das Bestellen bei Spitzenlast. Das andere ist das Überstehen eines Ausfalls des Zahlungsanbieters. Diese beiden erhalten als Erste Aufmerksamkeit im Design. Dieses Änderbarkeitsszenario hat mittlere Bedeutung und geringe Schwierigkeit, also genügt gewöhnliches gutes Design.
Sehen wir uns das in der Praxis an. Ein zweistündiger Workshop für eine Essenslieferplattform ergab sechsundzwanzig Szenarien. Bei zwölf Teilnehmenden erhielt jede Person acht Stimmen: dreißig Prozent von sechsundzwanzig sind sieben Komma acht, aufgerundet. Ein führendes Szenario: Bei der Freitagsspitze von dreitausend Bestellungen pro Minute kommen fünfundneunzig Prozent der Bestätigungen innerhalb von anderthalb Sekunden zurück und neunundneunzig Prozent innerhalb von drei. Eine kurze Kapazitätsprüfung. Dreitausend pro Minute sind fünfzig pro Sekunde. Das Unternehmen plant, das Volumen zu verdoppeln, also hundert pro Sekunde. Nach Littles Gesetz wären selbst dann, wenn jede Bestellung die vollen anderthalb Sekunden bräuchte, höchstens etwa hundertfünfzig gleichzeitig in Bearbeitung. Das zweite Szenario mit hoch und hoch: Gibt es beim Zahlungsanbieter ein Timeout, kommen Bestellungen in eine Queue, keine geht verloren, und Kunden werden innerhalb von zehn Sekunden informiert. Einen neuen Anbieter von Restaurantkassen hinzuzufügen hat mittlere Bedeutung und geringe Schwierigkeit. Also setzt das Team zuerst den Bestellpfad und den Entwurf mit Zahlungs-Queue prototypisch um und testet sie unter Last.
Qualitäten stehen oft im Konflikt, weil eine Taktik, die einer hilft, einer anderen schadet. Verschlüsselung und Prüfungen erzeugen bei jeder Anfrage Mehrarbeit. Bei einem Netzwerkausfall muss ein repliziertes System wählen, ob es mit womöglich veralteten Daten antwortet oder die Antwort verweigert. Die Position eines Kuriers darf leicht veraltet sein. Eine Zahlung nicht. Schichten und Schnittstellen erleichtern Änderungen, fügen aber Hops hinzu. Redundanz und zusätzliche Regionen kosten Geld, also kaufen Sie Neunen nur dort, wo ein Ausfall mehr kostet als seine Verhinderung. Und starke Authentifizierung erzeugt Reibung. Die richtige Antwort hängt immer vom Kontext ab: welchem Geschäftsziel jede Seite dient und was jede Option kostet.
Eine Abwägung, die nicht aufgeschrieben ist, wird erneut diskutiert. Halten Sie wesentliche Abwägungen in Architecture Decision Records fest, einschließlich dessen, worauf Sie bewusst verzichtet haben. Machen Sie jedes Ziel messbar. Für die Bestelllatenz ist die Skala Sekunden beim fünfundneunzigsten Perzentil, das Messverfahren Real-User-Monitoring bei der Freitagsspitze. Fail über drei Sekunden, Goal anderthalb, Stretch eine. Dann prüfen Sie es automatisch. Eine Fitness Function ist eine automatisierte Prüfung, etwa ein Lasttest, der den Build scheitern lässt, wenn die Latenz abdriftet. Damit endet dieses Kapitel: Ein vager Wunsch wird zu einem Szenario, erhält eine Priorität und wird zu einer Prüfung.
Der vollständige Abschnitt enthält jeden Workshop-Schritt, das vollständige Utility-Tree-Beispiel, eine Tabelle der Konflikte und eine Checkliste für Ihren eigenen Workshop. Damit ist Kapitel 2 abgeschlossen. Wenn Sie bereit sind, probieren Sie den optionalen Kapiteltest, um Ihr Verständnis zu prüfen. Gut gemacht.
Was Sie wissen müssen
- Qualitätsanforderungen müssen bei Stakeholdern, aus Geschäftszielen, Vorschriften, früheren Vorfällen, Wettbewerbern und Messungen am bestehenden System erhoben werden, weil sie selten ungefragt genannt werden.
- Der Quality Attribute Workshop des SEI hat acht Schritte; seine Ergebnisse sind Architekturtreiber und priorisierte, verfeinerte Szenarien, gewichtet durch eine Abstimmung mit festem Stimmenbudget.
- Ein Utility Tree verfeinert den Nutzen zu Qualitätsmerkmalen, Verfeinerungen und konkreten Szenarien, die jeweils bewertet werden (geschäftliche Bedeutung, technische Schwierigkeit); (H,H)-Szenarien erhalten als Erste Aufmerksamkeit im Design.
- Qualitäten stehen im Konflikt (Performance und Sicherheit, Verfügbarkeit und Konsistenz, Änderbarkeit und Performance, Kosten und fast alles, Benutzbarkeit und Sicherheit), und die richtige Lösung hängt vom Kontext und vom Geschäftswert ab.
- Halten Sie wesentliche Abwägungen in Entscheidungsdokumenten fest, machen Sie jedes Ziel mit einer Skala, einem Messverfahren und Stufen messbar und verfolgen Sie es über die Zeit.
- Fitness Functions machen aus den Antwortmaßen der Szenarien automatisierte Prüfungen, die laufen, während sich das System weiterentwickelt.
Woher Qualitätsanforderungen kommen
Funktionale Anforderungen landen meist in einem Backlog. Qualitätsanforderungen selten: Stakeholder setzen sie voraus („natürlich muss es schnell und sicher sein“) oder wissen nicht, dass sie sie nennen müssen. Architekten müssen sie deshalb aktiv erheben, und zwar aus mehreren Quellen.
Stakeholder. Jede Gruppe hat andere Anliegen: Kunden geht es um Tempo und einfache Bedienung, dem Betrieb um Monitoring und Wiederherstellung, der Finanzabteilung um Betriebskosten, dem Support um die Diagnose von Problemen, der Compliance um Audit-Trails. Die Stakeholder-Landkarte aus Kapitel 1 ist der Ausgangspunkt. Geschäftsziele. „Nächstes Jahr in drei neue Länder expandieren“ setzt Lokalisierung, Datenresidenz und Skalierbarkeit voraus; „die Kosten des Kundensupports um 20 % senken“ setzt Benutzbarkeit und Self-Service voraus. Vorschriften und Verträge. Datenschutz, Barrierefreiheitsrecht, Branchenregeln und Kunden-SLAs schaffen nicht verhandelbare Randbedingungen. Vorfälle. Jeder frühere Ausfall, jede Datenpanne und jeder langsame Tag zeigt eine Qualität, die zu ungenau spezifiziert war; Post-Incident-Reviews sind eine ergiebige Quelle. Wettbewerber und Markt. Wenn die Konkurrenz in einer Sekunde lädt, sind zwei Sekunden ein Qualitätsproblem. Das bestehende System. Sein heute gemessenes Verhalten (tatsächliche Last, tatsächliche Latenzperzentile, tatsächliche Durchlaufzeit von Änderungen) liefert eine Basislinie, die aus „schneller“ eine Zahl macht.
Interviews und Fragebögen funktionieren, doch Qualitätsmerkmale zeigen sich am besten, wenn Stakeholder einander zuhören. Ein Product Owner, der von der Betriebsleitung erfährt, was eine Stunde Ausfall zur Abendessenszeit am Freitag kostet, priorisiert anders. Das ist die Idee hinter strukturierten Workshops.
Der Quality Attribute Workshop
Der Quality Attribute Workshop (QAW), entwickelt am Software Engineering Institute (Barbacci und Kollegen; die dritte Ausgabe des Methodenberichts erschien 2003), ist eine moderierte Sitzung, typischerweise einen Tag lang, die früh stattfindet, bevor die Architektur feststeht. Er bringt 5 bis 30 Stakeholder zusammen, um priorisierte, verfeinerte Qualitätsszenarien zu erarbeiten. Er hat acht Schritte.
Die acht Schritte des QAW
Was in jedem Schritt geschieht
- 1. Präsentation und VorstellungDie Moderation erklärt Zweck und Methode; die Teilnehmenden stellen sich und ihre Anliegen vor.
- 2. Präsentation von Geschäft oder AuftragEine Vertretung des Geschäfts beschreibt Kontext, Ziele und übergeordnete Anforderungen: warum das System existiert und worauf es am meisten ankommt.
- 3. Präsentation des ArchitekturplansEine technische Leitung stellt aktuelle Pläne, bestehende Systeme, bekannte Randbedingungen und technologische Festlegungen vor, so früh sie auch sein mögen.
- 4. Ermittlung der ArchitekturtreiberDie Moderation verdichtet die bisher gehörten wichtigsten Architekturtreiber (Ziele, Qualitäten, Randbedingungen) und prüft sie mit der Gruppe.
- 5. Szenario-BrainstormingDie Teilnehmenden schlagen reihum Szenarien vor; die Moderation sorgt dafür, dass jeder Treiber mindestens eines hat und dass Szenarien für normale Nutzung, Wachstum und Erkundung (Stress) alle vertreten sind.
- 6. Bündelung der SzenarienFast gleiche Szenarien werden zusammengeführt, aber nur, wenn die Vorschlagenden zustimmen, damit sich die Stimmen nicht aufteilen.
- 7. Priorisierung der SzenarienAlle Teilnehmenden erhalten ein Stimmenbudget von etwa 30 % der Anzahl der Szenarien und verteilen es in zwei Runden, mit beliebig vielen Stimmen pro Szenario. Die Auszählung ergibt die Rangfolge der Szenarien.
- 8. Verfeinerung der SzenarienDie vier oder fünf wichtigsten Szenarien werden vollständig ausformuliert: Quelle, Stimulus, Artefakt, Umgebung, Antwort und Antwortmaß, mit den Geschäftszielen, denen sie dienen, und offenen Fragen.
Teams, die keinen ganzen Tag erübrigen können, führen oft einen kürzeren „Mini-QAW“ durch, eine schlankere Variante, die Praktiker wie Michael Keeling, Will Chaparro und Thijmen de Gooijer beschrieben haben: mit einer Taxonomie von Qualitätsmerkmalen als Denkanstoß und ein paar Stunden in einer kleineren Gruppe. Das Wesentliche bleibt: Stakeholder gemeinsam, Szenarien statt Adjektiven, ausdrückliche Abstimmung und Verfeinerung der Gewinner.
Der Utility Tree
Ein Utility Tree ist eine Methode, Qualitätsanforderungen zu ordnen und zu priorisieren; er wurde als Teil der Architecture Tradeoff Analysis Method (ATAM) eingeführt, die Rick Kazman, Mark Klein und Paul Clements am SEI entwickelt haben; die Bewertungsmethode selbst wird in Kapitel 11 behandelt. Die Wurzel ist der Nutzen (Utility), die Gesamtgüte des Systems. Die zweite Ebene enthält Qualitätsmerkmale (Performance, Verfügbarkeit und so weiter). Die dritte Ebene verfeinert jedes zu spezifischeren Anliegen (für Performance: Bestelllatenz, Aktualität der Sendungsverfolgung). Die Blätter sind konkrete, messbare Szenarien.
Jedes Blatt wird mit einem Paar bewertet: geschäftliche Bedeutung (wie wichtig das Szenario für das Geschäft ist: High, Medium oder Low) und technische Schwierigkeit oder Risiko (wie schwer es mit der Architektur zu erreichen ist: High, Medium oder Low). Das Paar wird (B,T) geschrieben, zum Beispiel (H,M). Mit (H,H) bewertete Szenarien sind die obersten Prioritäten der Architektur: Sie sind am wichtigsten und am schwierigsten und verdienen daher frühen Entwurfsaufwand, Prototypen und Analyse. (H,L)-Szenarien sind wichtig, aber leicht, sodass ein Standardansatz genügt; (L,H)-Szenarien sind Kandidaten zum Streichen oder Verschieben, weil sie schwer, aber wenig wert sind.
Der Baum ist auch außerhalb einer formalen Bewertung nützlich. Er macht Abwägungen auf einer Seite sichtbar, zeigt Lücken (eine Qualität ohne Szenarien) und verhindert, dass der lauteste Stakeholder die Prioritäten allein festlegt.
Ein Utility Tree für eine Essenslieferplattform
Ausgearbeitetes Beispiel
Ausgearbeitetes Beispiel: der Utility Tree für eine Essenslieferplattform
Eine Essenslieferplattform verbindet Kunden, 4000 Restaurants und 9000 Kuriere in einem Land. Das Unternehmen plant, das Bestellvolumen innerhalb von 18 Monaten zu verdoppeln. Die Spitze am Freitagabend liegt heute bei 3000 Bestellungen pro Minute. Ein zweistündiger QAW ergab 26 Szenarien; bei 12 Teilnehmenden hatte jede Person 8 Stimmen (30 % von 26 sind 7,8, aufgerundet auf eine gerade 8). Die Szenarien mit den meisten Stimmen wurden Blätter des Baums.
| Performance: Bestelllatenz (H,H) | Kunden geben Bestellungen mit der Spitzenrate von 3000 pro Minute auf; 95 % der Bestellbestätigungen kommen innerhalb von 1,5 s zurück und 99 % innerhalb von 3 s. Hohe Bedeutung: abgebrochene Warenkörbe sind entgangener Umsatz. Hohe Schwierigkeit: Die Anfrage durchläuft die Services für Warenkorb, Preisgestaltung, Zahlung und Restaurant |
|---|---|
| Kapazitätsprüfung für dieses Szenario | 3000 Bestellungen/Min. = 50 Bestellungen/s. Verdoppeltes Volumen ergibt 100 Bestellungen/s. Nach Littles Gesetz wären selbst dann, wenn jede Bestellung die vollen 1,5 s bräuchte, höchstens etwa 100 x 1,5 = 150 Bestellungen gleichzeitig in Bearbeitung (Abschnitt 2.4); der tatsächliche Durchschnitt ist niedriger, weil die meisten Bestellungen schneller fertig sind |
| Verfügbarkeit: Checkout-Uptime (H,H) | Wenn beim Zahlungsanbieter während der Spitze ein Timeout auftritt, werden Bestellungen angenommen und zur Zahlung in eine Queue gestellt, keine bestätigte Bestellung geht verloren, und Kunden werden innerhalb von 10 s informiert. Schwierig, weil es asynchrone Zahlung, idempotente Wiederholungen und eine Nutzererfahrung für „ausstehend“ erfordert |
| Verfügbarkeit: Regionsausfall (H,M) | Fällt die Cloud-Region aus, läuft der Dienst innerhalb von 15 Minuten (RTO) in einer zweiten Region weiter, mit höchstens 1 Minute verlorener Bestelldaten (RPO). Wichtig, aber technisch gut verstanden |
| Sicherheit: Kontoübernahme (H,M) | Ein Credential-Stuffing-Angriff wird innerhalb von 2 Minuten erkannt und blockiert; kein durch Multi-Faktor-Authentifizierung geschütztes Konto wird übernommen |
| Performance: Aktualität der Sendungsverfolgung (M,M) | Die Position eines Kuriers auf der Karte des Kunden ist unter Spitzenlast nie älter als 5 s |
| Änderbarkeit: neuer Kassenanbieter (M,L) | Ein neuer Anbieter von Restaurant-Kassensystemen wird in 5 Personentagen integriert, indem ein Adapter hinzugefügt wird (Abschnitt 2.6) |
| Daraus folgende Prioritäten | Zuerst den Bestellpfad und den Entwurf mit Zahlungs-Queue prototypisch umsetzen und unter Last testen; für Regionsausfälle bewährte Multi-Region-Muster nutzen; die Adapterschnittstelle einfach halten |
Bewertungen sind von der Gruppe vereinbarte Einschätzungen, keine Berechnungen. Halten Sie fest, wer was wie bewertet hat und warum, damit sich die Bewertungen später hinterfragen lassen.
Der Baum steuert den Arbeitsplan: Die beiden (H,H)-Szenarien erhalten in den ersten Sprints architektonische Spikes, während das (M,L)-Szenario keine besondere Aufmerksamkeit braucht.
Die Sendungsverfolgung der Kuriere wurde nur als mittel wichtig bewertet, was die Entwickler überraschte; der Product Owner erklärte, dass Kunden meist die geschätzte Ankunftszeit prüfen, nicht die Karte.
Priorisieren, wenn alles „kritisch“ ist
Jeder Stakeholder wird sein eigenes Anliegen hoch bewerten. Techniken, die echte Entscheidungen erzwingen, helfen. Ein festes Stimmenbudget (wie im QAW) zwingt dazu, knappe Stimmen gezielt einzusetzen. Paarweiser Vergleich („Wenn Sie nur eines haben könnten: Suche unter einer Sekunde oder null Datenverlust beim Failover?“) legt die wahre Reihenfolge offen. Geld oder Zeit neben jedes Ziel zu stellen („vier Neunen kosten zusätzlich £9000 im Monat und zwei Monate Arbeit“) ändert viele Meinungen. Und die Unterscheidung von Randbedingungen (gesetzliche Anforderungen an Barrierefreiheit, Datenresidenz) und Präferenzen verhindert, dass Nicht-Verhandelbares versehentlich weggehandelt wird.
Prioritäten sind nicht fest. Ein Start-up, das seine ersten Kunden sucht, stellt Time-to-Market und Änderbarkeit zu Recht über eine Verfügbarkeit von fünf Neunen; dasselbe Produkt muss drei Jahre später, mit Unternehmenskunden und vertraglichen SLAs, neu gewichten. Überprüfen Sie den Utility Tree, wenn sich das Geschäft ändert.
Konflikte zwischen Qualitäten
Qualitäten wirken aufeinander. Manche verstärken sich gegenseitig: Modularität hilft der Testbarkeit, die wiederum der Deploybarkeit hilft. Viele stehen im Konflikt, weil die Taktik, die einer Qualität hilft, einer anderen schadet. Die ATAM, beschrieben von Bass, Clements und Kazman, nennt die Stellen, an denen eine Architekturentscheidung mehrere Qualitäten beeinflusst, Trade-off-Punkte. Wer die üblichen Konflikte kennt, kann sie ansprechen, bevor sie jemanden überraschen.
Häufige Konflikte zwischen Qualitäten und wie der Kontext sie auflöst
| Konflikt | Warum sie auseinanderstreben | Wege, ihn im Kontext aufzulösen |
|---|---|---|
| Performance vs. Sicherheit | Verschlüsselung, Authentifizierungsprüfungen, Eingabevalidierung und Audit-Logging erzeugen bei jeder Anfrage Mehrarbeit | Den tatsächlichen Overhead messen (mit modernem TLS und moderner Hardware oft gering); Autorisierungsentscheidungen kurz cachen; teure Prüfungen an den Rand verlagern; nie Sicherheit bei Daten opfern, deren Offenlegung ernsten Schaden anrichten würde |
| Verfügbarkeit vs. Konsistenz | Während einer Netzwerkpartition muss ein repliziertes System zwischen Antworten (womöglich mit veralteten Daten) und Verweigern wählen | Pro Operation entscheiden: Eine Speisekarte oder Kurierposition darf leicht veraltet sein, eine Zahlung oder Bestandsreservierung nicht. Siehe CAP und PACELC in Kapitel 6 |
| Änderbarkeit vs. Performance | Schichten, Schnittstellen, Vermittler und spätes Binden fügen Indirektion und zusätzliche Hops hinzu | Die Indirektion dort beibehalten, wo Änderungen wahrscheinlich sind; den gemessenen Hot Path optimieren; einige bewusste Abkürzungen akzeptieren, dokumentiert in einem Entscheidungsdokument |
| Kosten vs. fast alles | Redundanz, zusätzliche Regionen, mehr Tests und schnellere Hardware kosten alle Geld | Jedes Qualitätsziel an seinen Geschäftswert knüpfen; Error Budgets und Stückkosten nutzen; Neunen nur dort kaufen, wo ein Ausfall mehr kostet als seine Verhinderung |
| Benutzbarkeit vs. Sicherheit | Starke Authentifizierung, Timeouts und Bestätigungen erzeugen Reibung | Risikobasierte Authentifizierung (Step-up nur bei riskanten Aktionen), Passkeys und Single Sign-on, sinnvolle Sitzungsdauern; Nutzer in Tests einbeziehen |
| Time-to-Market vs. Wartbarkeit | Abkürzungen beschleunigen das erste Release und bremsen spätere | Technische Schulden bewusst aufnehmen, festhalten und ihre Tilgung einplanen (Kapitel 1) |
Die richtige Lösung hängt immer vom Kontext ab. „Sicherheit schlägt Performance“ ist ein Slogan, keine Entscheidung: 2 ms zusätzlicher TLS-Handshake auf einer öffentlichen Website sind belanglos, während synchrone Betrugsprüfungen bei jeder Kartenzahlung in einem vollen Stadion ein echtes Problem sein können, das eine architektonische Antwort verdient (ein Modell „erst genehmigen, dann prüfen“ mit Limits). Fragen Sie: Welchem Geschäftsziel dient jede Seite, was kostet jede Option, und wer muss zustimmen?
Entscheidungen festhalten und Qualitäten verfolgen
Eine Abwägung, die nicht aufgeschrieben ist, wird erneut diskutiert, oft von Leuten, die nicht dabei waren. Halten Sie wesentliche Abwägungen als Architecture Decision Records fest (Kapitel 4): den Kontext, die Qualitäten im Spannungsfeld, die erwogenen Optionen, die Entscheidung und ihre Konsequenzen, einschließlich dessen, worauf Sie bewusst verzichtet haben.
Machen Sie dann jedes Qualitätsziel messbar und sichtbar. Tom Gilbs Planguage bietet ein diszipliniertes Format: eine Skala (was gemessen wird, in welcher Einheit), ein Messverfahren (wie gemessen wird) und Stufen wie Fail (die Schwelle, unterhalb derer die Anforderung nicht erfüllt ist), Goal (das Ziel) und Stretch oder Wish (ehrgeizigere Stufen). Angewandt auf das Szenario zur Bestelllatenz: Skala, Sekunden vom Absenden bis zur Bestätigung beim 95. Perzentil; Messverfahren, Real-User-Monitoring während der Freitagsspitze; Fail über 3 s; Goal 1,5 s; Stretch 1 s.
Verfolgen Sie die Maße schließlich über die Zeit auf einem Dashboard, das die Stakeholder einsehen können, neben den SLOs (Kapitel 9), und überprüfen Sie sie, sobald sich Geschäft, Last oder Team ändern.
Von Szenarien zu Fitness Functions
Der stärkste Weg, eine Qualitätsanforderung dauerhaft zu erfüllen, ist, sie bei jeder Änderung des Systems automatisch zu prüfen. Neal Ford, Rebecca Parsons und Patrick Kua nennen eine solche Prüfung in Building Evolutionary Architectures (2017; zweite Ausgabe mit Pramod Sadalage, 2022) eine architektonische Fitness Function: eine objektive Bewertung, wie gut das System ein Architekturmerkmal erfüllt. Ein Lasttest in der Pipeline, der den Build scheitern lässt, wenn die p95-Bestelllatenz bei 100 Bestellungen pro Sekunde 1,5 s übersteigt, ist eine Fitness Function. Ebenso ein Test, der fehlschlägt, wenn irgendein Modul außerhalb von payments die Bibliothek des Zahlungsanbieters importiert (zum Schutz des Änderbarkeitsszenarios), eine geplante Failover-Übung, die die Wiederherstellungszeit misst, oder ein Abhängigkeitsscan, der bekannte verwundbare Bibliotheken blockiert.
Fitness Functions sind der natürliche Endpunkt der Arbeit in diesem Kapitel: Ein vager Wunsch wird zu einem Szenario (Abschnitt 2.3), das Szenario erhält eine Priorität im Utility Tree, und das Antwortmaß des Szenarios wird zu einer automatisierten Prüfung. Nicht jede Qualität lässt sich günstig automatisieren (Benutzbarkeit braucht weiterhin Menschen), doch jede, die Sie automatisieren, verhindert eine schleichende Erosion. Kapitel 11 behandelt ihren Entwurf ausführlich: Fitness Functions und evolutionäre Architektur.
Checkliste: einen Quality Attribute Workshop durchführen
Angepasst für eine halb- oder ganztägige Sitzung; ein kürzerer „Mini-QAW“ kann mit einer kleineren Gruppe dasselbe abdecken.
- Die richtige Mischung einladen5 bis 30 Personen: Fachverantwortliche, Nutzer oder deren Vertretungen, Betrieb, Sicherheit, Support, Entwicklung und alle, die Compliance abzeichnen. Am häufigsten fehlt der Betrieb.
- Eine kurze Vorablektüre verschickenDie Geschäftsziele, bekannte Randbedingungen und ein Entwurf der Liste der Qualitätsmerkmale (ISO/IEC 25010 als Denkanstoß), damit alle schon nachdenkend ankommen.
- Mit Geschäftszielen beginnen, nicht mit TechnologieEin ranghoher Stakeholder erklärt, warum das System existiert, wie Erfolg aussieht und was ein Scheitern kosten würde.
- Die Architekturtreiber vereinbarenEine kurze Liste der Ziele, Qualitäten und Randbedingungen, die die Architektur prägen werden, mit der Gruppe geprüft, bevor die Szenarien beginnen.
- Szenarien in Runden sammelnAlle tragen reihum mindestens zwei bei, damit auch leise Stimmen gehört werden. Berücksichtigen Sie normale Nutzung, Wachstum („in zwei Jahren“) und Stress („wenn der Zahlungsanbieter ausfällt“).
- Duplikate nur mit Zustimmung zusammenführenDas Bündeln verhindert, dass sich Stimmen aufteilen, doch die vorschlagende Person muss zustimmen, dass zwei Szenarien wirklich dasselbe meinen.
- Mit festem Budget abstimmenJede Person erhält Stimmen in Höhe von etwa 30 % der Szenarienzahl, verteilt auf zwei Runden. Das legt echte Prioritäten offen und vermeidet „alles ist kritisch“.
- Die wichtigsten wenigen vollständig verfeinernSchreiben Sie die vier oder fünf wichtigsten als sechsteilige Szenarien mit messbaren Antwortmaßen aus und notieren Sie das Geschäftsziel, dem jedes dient.
- Offene Fragen und Konflikte festhaltenMeinungsverschiedenheiten über Priorität oder Machbarkeit sind wertvolle Ergebnisse; listen Sie sie mit einer verantwortlichen Person auf.
- Das Ergebnis innerhalb weniger Tage veröffentlichenTeilen Sie die priorisierten Szenarien, nehmen Sie sie in die Architekturdokumentation und das Backlog auf und planen Sie, wann jedes geprüft wird.
Prüfen Sie Ihr Verständnis
Wie viele Stimmen erhält jede teilnehmende Person in einem QAW mit 20 gebündelten Szenarien ungefähr?
Etwa 30 % von 20, also 6 Stimmen, verteilt auf zwei Runden zu je 3.
Ein Blatt des Utility Tree ist mit (L,H) bewertet. Was legt das nahe?
Es ist für das Geschäft wenig wichtig, aber schwer zu erreichen; es ist also ein Kandidat zum Streichen, Verschieben oder Neuverhandeln, statt die Architektur zu bestimmen.
Warum ist „Sicherheit schlägt immer Performance“ ein schlechter Weg, einen Konflikt zu lösen?
Weil die richtige Antwort vom tatsächlichen Overhead, vom Schaden, den die Sicherheitsmaßnahme verhindert, und vom Geschäftswert der Performance abhängt; der Konflikt muss im Einzelfall mit Zahlen gelöst und festgehalten werden.
Nennen Sie ein Beispiel für eine Fitness Function für eine Anforderung an die Änderbarkeit.
Ein automatisierter Test im Build, der fehlschlägt, wenn irgendein Modul außer dem Zahlungsadapter die Bibliothek des Zahlungsanbieters importiert, sodass der Anbieter austauschbar bleibt.
Quellen und weiterführende Literatur
Haben Sie eine Frage zu diesem Abschnitt? ArchitectBot, der KI-Lernassistent des Kurses, antwortet zuerst aus dem Kurs.
Fragen: „Unser Product Owner sagt, jede Qualität sei kritisch. Wie kann ich eine kurze Sitzung durchführen, die eine ehrliche Rangfolge ergibt?“