Architectural Katas

About

Architectural Katas are intended as a small-group (3-5 people) exercise, usually as part of a larger group (4-10 groups are ideal), each of whom is doing a different kata. A Moderator keeps track of time, assigns Katas (or allows this website to choose one randomly), and acts as the facilitator for the exercise.

Each group is given a project (in many ways, an RFP–Request For Proposal) that needs development. The project team meets for a while, discovers requirements that aren’t in the orignal proposal by asking questions of the “customer” (the Moderator), discusses technology options that could work, and sketches out a rough vision of what the solution could look like. Then, after they’ve discussed for a while, the project team must present their solution to the other project teams in the room, and answer challenges (in the form of hard-but-fair questions) from the other project teams. Once that challenge phase is done, the room votes on their results, and the next project team takes the floor.

History

From the creator of the original Katas site, Ted Neward:

The Architectural Katas were born out of a simple desire: software architects need a chance to practice being software architects, just as programmers need a chance to practice being programmers. Dave Thomas created the concept of the “Code Kata” while watching his son at karate practice, and that turned out to be a popular concept: a series of exercises that programmers can attempt in a variety of different languages, as a way to help master the language.

A few years later, while contemplating what kind of workshop I could run at a Java/Open Source/Agile conference, I thought about combining Code Katas but at a higher level. Some Google searches made it pretty apparent that nobody had tried this before, so… what the hell? Let’s give it a shot.

The Architectural Katas ran for 18 months straight, and each time they ran, they were a huge success–most participants found them useful, regardless of skill level. Experienced architects thought they were a great way to try something different; novice architects loved the chance to try something without the pain of failing; and senior developers who’d never really known what architecting was like found it an easy way to get a glimpse of the architecture exercise.