Qualitätsmerkmale und architekturrelevante Anforderungen

Willkommen zu Kapitel 2: Qualitätsmerkmale und architekturrelevante Anforderungen. Architektur ist dazu da, Qualitäten zu liefern: Geschwindigkeit unter Last, Betrieb trotz ausfallender Teile, gefahrlose Änderbarkeit, Geheimhaltung von Daten. Dieses Kapitel zeigt, wie man vage Wünsche wie schnell, zuverlässig und sicher in präzise, testbare Anforderungen verwandelt, die Designentscheidungen lenken können.

Fragen Sie eine Gruppe von Stakeholdern, was ein System tun muss, und Sie erhalten eine Liste von Features: einen Flug suchen, einen Warenkorb bezahlen, einen Termin buchen. Fragen Sie, wie gut es das tun muss, und die Antworten werden vager: Es soll schnell sein, nicht ausfallen, sicher sein. Diese zweiten Antworten sind Qualitätsmerkmale, und um sie geht es in der Architektur vor allem. Eine Anforderung, die eine messbare Wirkung auf die Struktur eines Systems hat, heißt architekturrelevante Anforderung. Die meisten davon erweisen sich als Qualitätsmerkmale oder Randbedingungen, nicht als Funktionen.

Dieses Diagramm aus Abschnitt zwei Punkt eins verdeutlicht das. Zwei Ticketsysteme haben identische Features: Veranstaltungen ansehen, Plätze reservieren und bezahlen. Das eine verkauft Tickets für einen Gemeindesaal mit dreihundert Plätzen. Sein geschäftigster Moment bringt ein paar Anfragen pro Sekunde, also ist eine Webanwendung mit einer Datenbank die richtige Antwort: günstig, einfach und leicht zu ändern. Das andere verkauft eine Stadiontournee mit sechzigtausend Plätzen. Es muss einen tausendfach größeren Ansturm abfangen und darf nie denselben Platz zweimal verkaufen. Deshalb braucht es einen Seiten-Cache, einen virtuellen Warteraum, einen sorgfältig entworfenen Sitzplatzbestand, partitionierte Speicherung und eine Zahlungswarteschlange. Gleiche Funktionen, völlig verschiedene Architekturen. Der Unterschied kommt allein von Qualitätsmerkmalen und Randbedingungen.

Dieses Kapitel eignet sich für Entwicklerinnen und Entwickler auf dem Weg zur Architektur. Es eignet sich auch für alle, die Anforderungen schreiben oder prüfen. Sie brauchen etwas Sicherheit im einfachen Rechnen: Prozente, Multiplikation und Division. Es baut auf dem Gedanken aus Kapitel 1 auf, dass Architektur dazu da ist, die Anliegen der Stakeholder durch Abwägungen zu erfüllen. Dieses Kapitel macht diese Anliegen präzise. Und es führt zu Kapitel 3, das die Designprinzipien vorstellt, mit denen Architekten diese Qualitäten erreichen.

Es gibt acht Abschnitte. Abschnitt zwei Punkt eins trennt funktionale Anforderungen, Qualitätsmerkmale und Randbedingungen und spielt ein Konzertticketsystem am ersten Verkaufstag einer großen Tournee durch. Abschnitt zwei Punkt zwei stellt die internationale Norm für Produktqualität mit ihren neun Merkmalen vor und zeigt, wie man sie als Gedächtnisstütze statt als Formular nutzt. Abschnitt zwei Punkt drei vermittelt die nützlichste Technik des Kapitels: das sechsteilige Qualitätsszenario, das „muss schnell sein“ in eine testbare Aussage verwandelt.

So ist es aufgebaut. Ein Szenario erzählt eine kurze Geschichte, von links nach rechts. Eine Quelle, jemand oder etwas, erzeugt einen Stimulus: ein Ereignis, auf das das System reagieren muss, etwa ein Ansturm von Anfragen oder ein Serverabsturz. Der Stimulus trifft ein Artefakt, das ganze System oder einen Teil davon, in einer Umgebung: Normalbetrieb, Spitzenlast, ein eingeschränkter Zustand oder ein Angriff. Das Artefakt antwortet, und die Antwort wird an einem Antwortmaß gemessen: der Zahl. Stimulus und Antwortmaß sind die beiden Teile, die am häufigsten fehlen, und die beiden wichtigsten. Das Beispiel darunter fügt alles zusammen: Am Black Friday rufen fünfhundert Kunden pro Sekunde den Checkout auf, und Bestellungen werden im neunundneunzigsten Perzentil innerhalb von anderthalb Sekunden bestätigt, ohne verlorene Bestellungen.

Die Abschnitte zwei Punkt vier bis zwei Punkt sieben besuchen die Qualitäten, die Architekturen am häufigsten prägen. Abschnitt zwei Punkt vier behandelt Performance und Skalierbarkeit mit echter Arithmetik: Latenz und Durchsatz, Perzentile, Warteschlangen und die Grenzen zusätzlicher Prozessoren. Abschnitt zwei Punkt fünf tut dasselbe für Verfügbarkeit und Zuverlässigkeit: die Neunen, die Zeit zwischen Ausfällen, die Reparaturzeit und das Zusammenwirken von Komponenten in Reihe und parallel. Abschnitt zwei Punkt sechs behandelt die Qualitäten der Veränderung: Änderbarkeit, Testbarkeit und Deploybarkeit. Abschnitt zwei Punkt sieben fasst Sicherheit, Benutzbarkeit und Barrierefreiheit, Interoperabilität, Kosten, Energieeffizienz, Betriebssicherheit und regulatorische Qualitäten zusammen.

In diesem Kapitel beginnt der Kurs zu rechnen. Sie sehen, warum eine Anfrage an einen zu neunzig Prozent ausgelasteten Server im Mittel das Zehnfache seiner Bedienzeit braucht. Keine der Rechnungen ist schwerer als Schularithmetik. Zahlen entlarven auch falsche Sicherheit. Eine mittlere Antwortzeit von hundertzwanzig Millisekunden kann verbergen, dass eine von fünfzig Anfragen länger als eine Sekunde dauert. Deshalb spezifizieren Fachleute Perzentile. Abschnitt zwei Punkt acht schließt den Kreis. Kein System kann zugleich schnell, verfügbar, sicher, günstig und leicht änderbar sein. Er zeigt, wie ein Workshop und ein Utility Tree aus einer Vielzahl von Meinungen eine Rangliste machen und welche Qualitäten im Konflikt stehen.

Wenn Sie sich nur eines aus diesem Kapitel merken, dann dies: Eine Qualität ist erst dann eine Anforderung, wenn sie einen Stimulus, einen Kontext und ein Maß hat. „Der Bezahlvorgang muss schnell sein“ ist ein Wunsch. Wenn in der Freitagabendspitze zweitausend Kunden pro Minute Bestellungen absenden, werden neunundneunzig Prozent der Bezahlvorgänge innerhalb von anderthalb Sekunden abgeschlossen: Das ist eine Anforderung. Man kann darauf hin entwerfen, sie testen, überwachen und mit Belegen über sie streiten.

Die Abschnitte zwei Punkt eins bis zwei Punkt drei lesen Sie am besten der Reihe nach, weil der Rest des Kapitels ihr Vokabular verwendet. Danach können Sie gezielt zu den Qualitäten springen, die Sie brauchen. Das ganze Kapitel zu lesen dauert etwa drei Stunden. Wenn ein Abschnitt rechnet, rechnen Sie selbst mit. So werden die Zahlen zu Werkzeugen, die Sie in einem echten Gespräch nutzen können. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie nachsehen. Wenn Sie so weit sind, legen Sie den optionalen Kapiteltest ab: zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten, in etwa fünfundvierzig Minuten. Die Bestehensgrenze liegt bei achtzig Prozent.

Das ist der Überblick über Kapitel 2. Beginnen Sie mit Abschnitt zwei Punkt eins, wo wir funktionale Anforderungen, Qualitätsmerkmale und Randbedingungen trennen und ein Ticketsystem an seinem geschäftigsten Tag kennenlernen. Bis gleich.