# Architecture Kata Brief: [Kata name]

> Practice brief for an architecture kata: a short, time-boxed exercise in
> which small teams design an architecture for an invented client, then
> present and defend it. The page holds the client brief that teams
> receive, the facilitator's hidden answers, the session plan and a judging
> rubric. The format follows common practice for architectural katas, an
> exercise first run as a conference workshop by Ted Neward. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Teams get section 1 only. Sections 2 to 4 are for the facilitator, who
  also plays the client and answers questions.
- Keep the brief vague on purpose: real requirements are found by asking.
  Hide the important constraints in section 2 and reveal them only when a
  team asks the right question.
- Teams of 3 to 5 people work best. Use at least three teams so the
  challenge round has enough voices.
-->

| Field | Value |
|---|---|
| Kata ID | [KATA-007] |
| Level | [Junior / Mid / Senior architects] |
| Duration | [2 hours 30 minutes] |
| Facilitator (client) | [@facilitator] |
| Last used | YYYY-MM-DD |

## 1. Client brief (handed to teams)

*Example:* **Harbourline Ferries** (an invented regional ferry operator)
runs 14 routes between islands and the mainland. It wants passengers to
book, change and board with a phone, and wants crews to see live passenger
counts per sailing.

- **Users**: passengers, booking agents in 6 ports, crews on 9 vessels,
  operations staff.
- **Requirements**: book and pay up to 90 days ahead; change or cancel
  until departure; board by scanning a code; crew view of counts and
  vehicle deck space.
- **Context**: vessels have unreliable connectivity at sea; current
  booking runs on a 20-year-old desktop system.
- **Deliverables**: a context diagram, the main containers or services,
  three key decisions with reasons, and the top two risks.

## 2. Facilitator notes (hidden)

| Hidden constraint | Reveal when a team asks about |
|---|---|
| *Example:* Peak season traffic is about 8 times the winter average | Load, scaling, seasonality |
| *Example:* The maritime authority needs a passenger list before each departure | Regulation, safety, manifests |
| *Example:* Budget allows two developers to run the system after launch | Operations, team, cost |
| [Constraint] | [Trigger topic] |

## 3. Session plan

| Step | Minutes | What happens |
|---|---|---|
| Brief and questions | 20 | Facilitator reads section 1; teams ask the client questions |
| Design | 60 | Teams agree requirements, options and a sketch |
| Presentations | 40 | Each team presents for about 8 minutes, then takes questions |
| Challenge and vote | 20 | Other teams challenge fairly; the room scores with section 4 |
| Retrospective | 10 | What surprised people, which question unlocked the design |
| **Total** | **150** | |

## 4. Judging rubric

Score each criterion 1 (weak) to 4 (strong). Maximum 20 points.

| Criterion | 1 | 4 |
|---|---|---|
| Requirements discovery | Designed from the brief only | Found and used the hidden constraints |
| Fit to quality attributes | Qualities not named | Named the top qualities and showed how the design meets them |
| Decisions and trade-offs | Choices without reasons | Three decisions with alternatives and trade-offs |
| Risk awareness | No risks | Top risks with a mitigation or a test |
| Communication | Hard to follow | Clear diagram and story in the time slot |

Related templates: Architecture Decision Record (`architecture/adr-full`),
C4 Architecture (`architecture/c4-architecture`), Quality Attribute
Workshop Report (`architecture/qaw-workshop-report`).

## Standard and licence note

Based on the general practice of architectural katas (history and format
described at https://nealford.com/katas/about.html, checked 2026-10-30).
The brief, the invented client, the session plan and the rubric are
original to this collection. Template licence: MIT.