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 formulierte Geschäftsproblematik, entwirft eine Architekturskizze, präsentiert diese den Teamkollegen und beantwortet kritische Fragen. In Fachkreisen wird sie auch Architektur-Kata genannt. Das Format wurde von Ted Neward als Workshop entwickelt und ist mit seinen Regeln und der Rolle des Moderators auf Neal Fords Webseite zu Architektur-Katas dokumentiert . Newards dort zitierte Leitfrage lautet: Wie sollen Organisationen hervorragende Architekten entwickeln, wenn Ingenieure im Laufe ihrer Karriere weniger als ein halbes Dutzend Mal die Gelegenheit haben, Architekturen zu entwerfen? Eine Kata bietet ihnen zusätzliche Übungsmöglichkeiten 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. Überprü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 welche Vorlage verwenden Sie für Ihre Designprüfung? Selbstgesteuertes Lernen eignet sich für diese Phase; eine kurze Wissensüberprüfung bestätigt lediglich die vorhandenen Voraussetzungen.
Üben Sie. 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 geben („Super!“); ein neutrales Feedback („Noch nicht ganz gelungen!“); oder ein negatives Feedback („Total 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 veränderliche Bedingung hinzu. Die Standard-Kata bietet ein festes Problem. Um die in diesem Leitfaden beschriebene Fertigkeit zu trainieren, füge nach der Hälfte der Übung eine zweite Karte hinzu: eine veränderte Bedingung, die das Team berücksichtigen muss. Dies ist eine von uns vorgenommene Designentscheidung und nicht Teil der ursprünglichen Regeln. Teste sie daher zunächst.
Feedback. Beziehen Sie Feedback auf Entscheidungen, nicht auf eine Gesamtpunktzahl. „Sie sind in zwei Regionen umgezogen, haben aber nicht angegeben, was mit einer während des Wechsels aufgegebenen Bestellung passiert“ ist hilfreicher als „3 von 5“.
Live-Feedback oder asynchrone Überprüfung? Live-Moderation ist besonders hilfreich, wenn eine Entscheidung unklar ist und Entwickler von einem erfahrenen Kollegen lernen, der seine Vorgehensweise erläutert. 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 Bezahlvorgang.
Die geänderte Vorgabe. Nach der Hälfte der Veranstaltung fügt der Veranstalter hinzu: Der Ticketverkauf muss auch dann weitergehen, wenn ein Rechenzentrum ausfällt, und Tickets dürfen nicht doppelt verkauft werden.
Ein erster Versuch. „Ein zweites Rechenzentrum hinzufügen und die Datenbank replizieren.“ Das Team greift auf eine bekannte Komponente zurück, hat aber nicht erklärt, was mit der Regel zum Verbot von Doppelverkäufen geschieht, wenn die beiden Standorte nicht miteinander kommunizieren können.
Feedback und Wiederholungsversuch. Der Moderator bittet das Team, die beiden strittigen Ziele zu benennen und anzugeben, welches Ziel sie bei einer Netzwerkaufspaltung schützen würden. Im Wiederholungsversuch sollen sie sich entscheiden und beschreiben, welche Kundenerfahrung das mit ihnen macht.
Ein überzeugenderer Versuch. „Wir würden die Regel gegen Doppelverkäufe schützen. Bei einer Aufteilung des Ticketverkaufs verkauft nur die primäre Website Tickets, die andere zeigt eine Warteliste an. Wir akzeptieren kurzzeitig eine geringere Verfügbarkeit, um zu vermeiden, dass derselbe Sitzplatz doppelt verkauft wird. Wir gehen davon aus, dass solche Aufteilungen selten und kurz sind und bitten den Veranstalter um Bestätigung, dass eine Warteliste akzeptabel ist. Falls beide Websites Tickets verkaufen müssen, würden wir im Voraus separate Sitzplatzkontingente für jede Website reservieren, was allerdings zu Lasten einiger unverkaufter Plätze geht.“ Diese Antwort benennt den Konflikt, bezieht Stellung, nennt die Kosten und weist auf Unklarheiten hin.
Warum die einzelnen Antworten vertretbar bzw. unvollständig sind. Bewerten Sie jede Antwort anhand genehmigter Kriterien, nicht anhand der bevorzugten Architektur des Gutachters. Der erste Versuch nennt zwar eine Komponente, aber keine Abwägung. 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, sollten separat definiert werden, 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 zur Gestaltung interaktiver Übungen mit hilfreichem Feedback beschreibt, wie Sie Feedback formulieren, das zu Entscheidungen führt.
Planen Sie den Transfer bewusst. Bitten Sie nach der Kata jeden Ingenieur, eine aktuelle Designentscheidung in eine Überprüfung einzubringen und dieselben Fragen zu stellen. Eine ergebnisoffene Überprüfung eines vergangenen Vorfalls ist eine weitere gute Brücke zur eigentlichen Arbeit; siehe unseren Leitfaden zur Durchführung ergebnisoffener Vorfallüberprüfungen.
Wo interaktive Bereitstellung hilft
Interaktive Formate sind hilfreich, wenn sich alle vor der Präsentation auf die jeweilige Gruppe festlegen. In einer Live-Kata-Session kann der Moderator die geänderte Einschränkung präsentieren, jedes Teammitglied bitten, den jeweiligen Kompromiss mit Begründung einzugeben und anschließend die Ergebnisse vor Diskussionsbeginn zu präsentieren. Die Peer-Abstimmung am Ende des ursprünglichen Formats lässt sich genauso einfach durchführen. Derselbe Fall kann auch im Selbstlernmodus zur Vorbereitung oder für Entwickler, die die Session verpasst haben, bearbeitet werden. AhaSlides unterstützt interaktives Lernen und den Wechsel zwischen Live- und Selbstlernphasen. 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 zur Erstellung, zum Feedback und zur Berichterstellung, die Sie nutzen möchten, anhand Ihres eigenen Workflows. Hinweise zur Auswahl des passenden Formats finden Sie in unserem Artikel „ Wann Sie 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.
