Architecture Kata Exercises

Architecture katas are short, deliberate design exercises. Like code katas, they trade realism for repetition: you practise making and defending decisions under time pressure, in a safe setting. Running a kata every few weeks builds shared vocabulary and exposes how different people weigh trade offs.

Learning goals

Practise turning a vague brief into architectural drivers
Compare options and justify choices with trade offs
Present a design clearly in a few minutes
Give and receive constructive feedback

Step-by-step procedure

Form groups of three to five and choose a facilitator. Allocate ninety minutes in total.
Hand out a short brief, a few paragraphs describing a business need, such as an app to coordinate neighbourhood food sharing. Leave gaps on purpose.
Spend ten minutes extracting requirements and quality attributes. Ask the facilitator questions, who plays the stakeholder.
Pick the top three drivers, for example availability, privacy and cost, and write them at the top of the page.
Sketch the system context and a container level diagram. Name each component and its responsibility.
Identify two or three key decisions and write a decision record for each, with options, choice and consequences.
Spend five minutes per group presenting to the others, focusing on the drivers and decisions rather than every box.
Use feedback prompts: what is the riskiest assumption, what would you change if scale grew tenfold, and which decision is hardest to reverse.

Worked example

A group receives the food sharing brief. They extract that most users are mobile, listings expire in hours, and location privacy matters. Drivers: privacy, low cost and fast search by distance. They sketch a mobile app, an API, a geospatial search index and a notification service. Decision one: store only approximate locations until two users agree to meet. Decision two: use a managed database with geospatial support rather than a dedicated search cluster, accepting a lower ceiling in exchange for simplicity. During feedback another group asks how listings are moderated, which the team had ignored. They add a lightweight review queue and record the open risk. The exercise took ninety minutes and surfaced three assumptions worth validating.

Exercises and templates

Run a kata on a brief of your choice, such as a ride sharing service for a campus.
Write a decision record for the hardest choice your group made.
Redo the same kata with a changed driver, such as extreme cost limits, and compare designs.

Template:

Decision: Store approximate location until meeting is agreed
Options: Exact location, approximate location, none
Choice: Approximate
Consequence: Extra step to share exact address

Common pitfalls

Spending the whole time drawing and none on trade offs.
Choosing familiar technology by habit instead of by the drivers.
Presenting every component equally rather than the decisions that matter.
Letting feedback sound like criticism. Phrase it as questions about assumptions and consequences.

Follow-up and continuous improvement

Rotate the facilitator and the brief each session, and keep a shared archive of decision records from past katas. After a few rounds, compare how designs differ across groups and what that reveals about unstated team preferences. Those conversations often lead to updated engineering guidelines.

Adapting this to your team

Treat everything above as a starting point rather than a rulebook. Smaller teams can compress the sessions and merge roles, while larger organizations may need written templates, a shared calendar and a named owner for the practice. Begin with one pilot on a real project, collect honest feedback from participants, and adjust the format before you roll it out more widely. Consistency matters more than perfection, so favour a simple routine you will actually repeat.

Key takeaways

Katas build judgement through repetition and feedback
Name the drivers before drawing boxes
Decisions with consequences matter more than diagrams
Challenge assumptions during feedback, not after launch