Ein Team entwickelt einen Ticketbuchungsservice für ein regionales Festival. Er bewältigt die erwartete Last problemlos, und die Designprüfung endet mit Zustimmung. Doch dann ändert sich die Aufgabenstellung: Der Veranstalter garantiert nun, dass der Ticketverkauf auch dann weiterläuft, wenn ein Rechenzentrum während des Vorverkaufszeitraums ausfällt. Derselbe Entwurf weist nun einen Single Point of Failure auf, und die Entwickler müssen entscheiden, was geändert, worauf verzichtet und wie sie ihre Entscheidung begründen.
Dies ist ein beispielhaftes Szenario, kein dokumentierter Vorfall. Es beschreibt eine Situation, die in einer Systemdesign-Kata geübt wird: Ein Design, das unter bestimmten Bedingungen funktionierte, trifft auf neue, und die Entwickler müssen es begründen und gegebenenfalls verteidigen oder überarbeiten. Dieser Leitfaden richtet sich an Verantwortliche für die Mitarbeiterentwicklung und an Entwicklungsmanager. Er erklärt, was eine Systemdesign-Kata ist, wie man sie erstellt, durchführt und bewertet und wann Schulungen allein nicht mehr ausreichen. Jeder Fall und jedes Kriterium sollte vor der Anwendung von einem erfahrenen Entwickler validiert werden.
Was ist eine Systemdesign-Kata?
Eine Systemdesign-Kata ist eine kurze, zeitlich begrenzte Designübung. Ein kleines Team erhält eine in einem Absatz beschriebene Geschäftsproblematik, entwirft eine Architekturskizze, präsentiert diese den anderen Teammitgliedern und beantwortet kritische Fragen. Sie wird auch Architektur-Kata genannt. Das Format wurde von Ted Neward als Workshop entwickelt und ist mit seinen Regeln und der Rolle des Moderators dokumentiert. Neal Fords Architektur-Katas-SeiteNewards zentrale Frage, die er dort zitiert, lautet: Wie sollen Organisationen herausragende Architekten hervorbringen, wenn Ingenieure in ihrer gesamten Laufbahn weniger als ein halbes Dutzend Mal die Gelegenheit haben, Architektur zu entwerfen? Eine Kata bietet ihnen zusätzliche Wiederholungen ohne Produktionsrisiko.
Schnelle Fakten
| Frage | Kurze Antwort |
|---|---|
| Was ist die Aufgabe? | Verteidige eine Architektur, wenn sich eine Einschränkung ändert. |
| Wie groß ist die Gruppe? | Das ursprüngliche Format sieht kleine Gruppen von 3 bis 5 Personen mit einem Moderator vor. |
| Welche Punktzahl erreichst du? | Abwägungsprozesse und die Reaktion auf eine neue Einschränkung, nicht das schönste Diagramm. |
| Reicht ein Quiz über Entwurfsmuster aus? | Nein. Es bestätigt zwar die Voraussetzungen, aber nicht, ob ein Ingenieur seine Entscheidung unter Druck begründen kann. |
| Wer bestätigt den Fall? | Ein technischer Leiter oder ein leitender Architekt. |
| Was kann eine Kata nicht beheben? | Fehlende Designkompetenz, unklare Anforderungen und keine Zeit für eine ordnungsgemäße Planung am Arbeitsplatz. |
| Woran erkennt man, dass es funktioniert hat? | Ein neuer, bisher unbekannter Fall wurde anhand vereinbarter Kriterien bewertet, zusätzlich wurden reale Designprüfungen im Anschluss durchgeführt. |
1. Beschreiben Sie das Leistungsproblem
Beginnen Sie mit der Aufgabe, nicht mit dem Thema. Die Aufgabe besteht darin, eine Architektur unter sich ändernden Rahmenbedingungen zu verteidigen. In der Praxis geschieht dies in Design-Reviews, der Nachverfolgung von Störungen und Planungsbesprechungen, in denen sich die Anforderungen ändern: mehr Datenverkehr, eine strengere Verfügbarkeitsgarantie, eine neue Datenresidenzregel, ein knapperes Budget.
Viele Ingenieure können eine sinnvolle Architektur entwerfen. Weniger jedoch können sie sagen, worauf sie verzichten würden, wenn zwei Ziele kollidieren, und welche Beweise ihre Meinung ändern würden. Genau diese zweite Fähigkeit wird in der Kata geübt.
Verfassen Sie eine einzeilige Leistungsbeschreibung und lassen Sie diese von einem technischen Leiter überprüfen: „Angesichts einer gegebenen Architektur und einer geänderten Einschränkung benennt der Ingenieur, was nicht mehr funktioniert, schlägt eine Änderung vor, erläutert die damit verbundenen Kompromisse und gibt an, was er noch nicht weiß.“
2. Lern- und Kontextlücken diagnostizieren
Bevor Sie mit dem Bauen beginnen, vergleichen Sie die Aufgabe mit dem, was in Ihrem Programm heute praktiziert und bewertet wird.
- Wird in der Praxis die reale Aufgabe verwendet? Wenn im Training Muster isoliert vermittelt werden und die Bewertung aus einem Multiple-Choice-Test besteht, hat niemand geübt, eine Entscheidung zu verteidigen.
- Welche kognitiven Anforderungen werden gestellt? In Blooms überarbeiteter Taxonomie befindet sich der Vergleich von Optionen und Einschränkungen im Stadium der Analyse und Bewertung, während das Vorschlagen eines überarbeiteten Designs dem Stadium der Gestaltung zugeordnet ist. Unser Leitfaden dazu Zuordnung von Lernaktivitäten zu Blooms Taxonomie zeigt, wie die Aktivität dem entsprechenden Niveau zugeordnet werden kann.
- Steht da noch etwas anderes als Können im Weg? Prüfen Sie, ob die Entwickler Zeit für die Konzeption haben, ob jemand die Verantwortung für Architekturentscheidungen trägt und ob die Anforderungen schriftlich festgehalten sind. Wenn eine Entscheidung von jemandem außerhalb des Teams getroffen wird, kann auch keine Kata etwas daran ändern, was das Team tun kann. Leiten Sie diese Probleme an die Personen weiter, die sie beheben können.
3. Entwurfsvorbereitung und -durchführung
Jeder Phase sollte eine klar definierte Aufgabe zugewiesen werden.
Vorbereitung. Prüfen Sie die Voraussetzungen mit einer kurzen Diagnose: Welche Begriffe verwendet Ihr Team (Verfügbarkeit, Konsistenz, Latenz, Kosten)? Welche Grundlagen sollten die Teammitglieder beherrschen? Und wie sieht Ihre Vorlage für Designprüfungen aus? Selbstgesteuertes Lernen eignet sich für diese Phase; eine kurze Wissensüberprüfung bestätigt lediglich die vorhandenen Voraussetzungen.
Praxis. Führen Sie die Kata selbst durch. Im Format, das auf Neal Fords Website beschrieben wird, läuft die Übung nach der Teambildung in drei Phasen ab: einer Diskussionsphase, in der das Team das zu entwickelnde Projekt erarbeitet; einer Peer-Review-Phase, in der jedes Team seine Ergebnisse präsentiert und Fragen beantwortet; und einer Abstimmungsphase, in der die Teammitglieder ein positives Feedback (Daumen hoch) geben („Perfekt!“); ein neutrales Feedback (Daumen runter) („Völlig daneben“). Einige Regeln können direkt übernommen werden: Teams dürfen Annahmen über unbekannte Technologien treffen, müssen diese aber angeben und dürfen nicht davon ausgehen, ein Team von absoluten Experten zusammenstellen zu können.
Füge die Änderungsbedingung hinzu. Die Standard-Kata bietet ein festes Problem. Um die Fertigkeit in diesem Leitfaden zu trainieren, fügen wir nach der Hälfte der Übung eine zweite Karte hinzu: eine veränderte Bedingung, die das Team erfüllen muss. Dies ist eine von uns vorgenommene Designentscheidung und nicht Teil der ursprünglichen Regeln. Testen Sie es daher bitte.
Feedback bekommen. Verknüpfen Sie Feedback mit Entscheidungen, nicht mit einer Gesamtpunktzahl. „Sie sind in zwei Regionen umgezogen, haben aber nicht angegeben, was mit einer Bestellung passiert, die während des Wechsels aufgegeben wurde“ ist hilfreicher als „3 von 5“.
Live-Eingabe oder asynchrone Überprüfung? Live-Moderation ist besonders hilfreich, wenn eine Entscheidung mehrdeutig ist und Ingenieure von einem erfahrenen Kollegen lernen, der erklärt, warum er an seiner Position festhalten würde. Eine asynchrone Überprüfung genügt, um eine schriftliche Begründung mit einem kommentierten Beispiel zu vergleichen.
4. Arbeiten Sie ein realistisches Beispiel durch.
Zur Veranschaulichung. Ein erfahrener Ingenieur sollte den Anwendungsfall und die Antwortkriterien vor der Verwendung prüfen.
Der Fall. Ein regionales Festival verkauft an einem Wochenende 20,000 Tickets, die meisten davon in den ersten zehn Minuten. Die erste Version des Briefings fordert ein Buchungssystem, das diese Spitzenzeiten bewältigen kann. Der Entwurf: eine Web-Ebene, eine Datenbank, ein Zahlungsanbieteraufruf beim Checkout.
Die geänderte Einschränkung. Nach der Hälfte der Veranstaltung fügt der Veranstalter hinzu: Der Verkauf muss auch dann weitergehen, wenn ein Rechenzentrum offline geht, und es darf kein Ticket zweimal verkauft werden.
Ein erster Versuch. „Fügen Sie ein zweites Rechenzentrum hinzu und replizieren Sie die Datenbank.“ Das Team greift auf eine altbekannte Komponente zurück, hat aber nicht gesagt, was mit der Regel des Nicht-Doppelverkaufs passiert, wenn die beiden Standorte nicht miteinander kommunizieren können.
Feedback geben und es erneut versuchen. Der Moderator bittet das Team, die beiden konfliktbehafteten Ziele zu benennen und anzugeben, welches Ziel sie bei einer Netzwerkaufspaltung schützen würden. Im Wiederholungsdurchgang sollen sie sich erneut entscheiden und die Kundenerfahrung erläutern.
Ein stärkerer Versuch. „Wir würden die Regel zum Verbot von Doppelverkäufen wahren. Bei einer Aufteilung des Ticketverkaufs verkauft nur die primäre Website Tickets, während die andere Website eine Warteliste anzeigt. Wir akzeptieren kurzzeitig eine geringere Verfügbarkeit, um zu vermeiden, dass derselbe Sitzplatz doppelt verkauft wird. Wir gehen davon aus, dass eine solche Aufteilung selten und von kurzer Dauer ist und bitten den Veranstalter um Bestätigung, ob eine Warteliste akzeptabel ist. Sollte der Ticketverkauf auf beiden Websites erforderlich sein, würden wir im Voraus separate Sitzplatzkontingente für jede Website reservieren, was allerdings zu Lasten einiger unverkaufter Plätze gehen würde.“ Diese Antwort benennt den Konflikt, bezieht Stellung, nennt die Kosten und weist auf Unklarheiten hin.
Warum jede Antwort vertretbar oder unvollständig ist. Bewerten Sie jeden Versuch anhand der festgelegten Kriterien, nicht anhand der vom Gutachter bevorzugten Architektur. Der erste Versuch nennt zwar eine Komponente, aber keine Kompromisse. Der überzeugendere Versuch ist konkret, legt seine Annahmen dar und bietet eine Alternative mit Preisangabe.
5. Fähigkeiten einschätzen und Transfer planen
Der Nachweis der Kompetenz erfolgt durch die Bearbeitung eines neuen, dem Ingenieur unbekannten Falls. Bewertet werden die Abwägungsstrategien und die Reaktion auf eine neue Einschränkung. Ein einfacher Bewertungsbogen verwendet eine Skala von 0 bis 2 pro Kriterium.
| Kriterium | Sichtbare Beweise |
|---|---|
| Aufgabenausführung | Verteidigt die Architektur unter den geänderten Rahmenbedingungen und dokumentiert die der Entscheidung zugrunde liegenden Beweise. |
| Argumentation | Erläutert die relevanten Einschränkungen, die in Betracht gezogenen Alternativen und was noch ungewiss ist. |
| Boundaries | Hält sich an genehmigte Konstruktionsverfahren und bittet um Hilfe, wenn Informationen oder Befugnisse fehlen. |
Bewertungskriterien: 0 bedeutet fehlend oder nicht begründet, 1 bedeutet teilweise mit relevanten Auslassungen und 2 bedeutet vollständig und anhand der vereinbarten Kriterien begründet. Kritische Fehler, wie z. B. das Ignorieren einer festgelegten Sicherheits- oder Datenschutzanforderung, sind separat zu definieren, damit sie nicht in der Gesamtbewertung verborgen bleiben. Diese Bewertungsmatrix ist ein Vorschlag, kein validierter Bereitschaftsstandard: Passen Sie sie gemeinsam mit einem technischen Leiter an und erproben Sie sie. Unser Leitfaden dazu Gestaltung interaktiver Übungen mit hilfreichem Feedback behandelt die Frage, wie man Feedback verfasst, das mit Entscheidungen verknüpft ist.
Planen Sie den Transfer bewusst. Bitten Sie nach der Kata jeden Ingenieur, eine aktuelle Designentscheidung in die Überprüfung einzubringen und dieselben Fragen zu stellen. Eine unvoreingenommene Überprüfung eines vergangenen Vorfalls ist eine weitere gute Brücke zur eigentlichen Arbeit; siehe unseren Leitfaden dazu. Durchführung von unschuldigen Vorfallsanalysen.
Wo interaktive Bereitstellung hilft
Interaktive Formate sind hilfreich, wenn sich alle vor der Präsentation in der Gruppe festlegen müssen. In einer Live-Kata-Session kann der Moderator die geänderte Einschränkung präsentieren, jedes Teammitglied bitten, den jeweiligen Kompromiss und dessen Begründung schriftlich festzuhalten, und anschließend die Ergebnisse vor Diskussionsbeginn anzeigen. Die Peer-Abstimmung am Ende des ursprünglichen Formats lässt sich genauso einfach durchführen. Derselbe Fall kann auch im Selbststudium zur Vorbereitung oder für Entwickler, die die Session verpasst haben, bearbeitet werden. AhaSlides unterstützt interaktives Lernen und den Wechsel zwischen Live- und Selbststudium. Es handelt sich um ein Präsentations- und Lernwerkzeug, nicht um eine Plattform zum Zeichnen oder für Architekturdarstellungen. Diagramme sollten daher auf einem Whiteboard oder in Ihrem Design-Tool erstellt werden. Überprüfen Sie alle Funktionen zum Erstellen, Feedbackgeben und Berichten, die Sie nutzen möchten, anhand Ihres eigenen Workflows. Hinweise zur Formatauswahl finden Sie in unserem Artikel zu [Link einfügen]. Wann sollte man adaptives, interaktives und Live-Lernen einsetzen?.
Messen Sie, was sich verändert hat
Legen Sie im Vorfeld fest, woran Sie erkennen, dass Ingenieure eine Architektur unter sich ändernden Bedingungen verteidigen können. Vergleichen Sie die Abwägungsargumente anhand eines unbekannten Falls mit einer vor Programmbeginn erstellten Basislinie. Definieren Sie die Einschlusskriterien, den Nenner und den Zeitraum. Verbessern sich die Ergebnisse, prüfen Sie, welche anderen Faktoren sich im selben Zeitraum geändert haben, z. B. eine neue Vorlage für Designprüfungen, eine Personalveränderung oder ein Vorfall, der Aufmerksamkeit erregte, bevor Sie die Schulung als Erfolg werten.
Einschränkungen, die möglicherweise bestehen bleiben
- Designautorität. Wenn das Team die Entscheidung nicht trifft, hat das Üben nur begrenzten Nutzen.
- Zeit. Eine Kata dauert Stunden; reale Entwürfe benötigen Wochen und beinhalten Daten, die eine Kata nicht liefern kann.
- Fallabdeckung. Ein einzelner Fall verdeutlicht einige Abwägungen. Eine Punktzahl beschreibt nicht generell das Urteilsvermögen eines Ingenieurs.
- Komplexität. Mehr Komplexität bedeutet nicht unbedingt eine bessere Architektur, daher sollte man nicht die meisten Komponenten belohnen.
- Übertragung. In einem Workshop gut abzuschneiden ist nicht dasselbe wie in einer angespannten Prüfungssituation gut abzuschneiden. Überprüfen Sie daher die Leistung nach der Kata in der realen Situation.
Benennen Sie diese Punkte frühzeitig gegenüber den Sponsoren und planen Sie separate Korrekturen. Eine Kata verbessert die Fähigkeit der Ingenieure, das zu erklären und zu verteidigen. Sie schafft jedoch weder Autorität noch Zeit.
Häufig gestellte Fragen
Was ist eine Systemdesign-Kata?
Eine kurze, zeitlich begrenzte Designübung, bei der ein kleines Team eine Architektur für ein betriebliches Problem entwirft, diese den Kollegen präsentiert und anspruchsvolle Fragen beantwortet. Sie wird auch Architektur-Kata genannt.
Wie viele Personen sollten in einem Team sein?
Das ursprüngliche Format sieht kleine Gruppen von 3 bis 5 Personen vor, üblicherweise eine von 4 bis 10 Gruppen in einem Raum. Die Gruppen sollten so klein sein, dass jeder zu Wort kommt.
Wie bewertet man eine Systemdesign-Kata?
Stellen Sie einen neuen Fall vor und bewerten Sie die Abwägungsargumentation sowie die Reaktion auf eine geänderte Einschränkung anhand vereinbarter Kriterien. Eine Bewertung durch Kollegen ist hilfreiches Feedback, stellt aber allein keine Bewertung dar.
Wo soll ich anfangen
Wählen Sie eine wiederkehrende Designentscheidung in Ihrem Unternehmen und verfassen Sie dazu eine kurze Fallstudie (ein Absatz). Fügen Sie eine geänderte Randbedingung hinzu, lassen Sie die Fallstudie und die Antwortkriterien von einem Entwicklungsleiter prüfen und erstellen Sie eine dreistufige Bewertungsmatrix mit einer Liste kritischer Fehler. Testen Sie die Methode zunächst mit einem Team, bevor Sie sie flächendeckend einführen.
Um zu sehen, wie eine Kata live mit Ihrem eigenen Team durchgeführt und anschließend im eigenen Tempo wiederholt werden kann, erkunden Sie AhaSlides.
