Architectural Katas

inspired by Ted Neward’s original Architectural Katas

  "How do we get great designers?
  Great designers design,
  of course."
                          Fred Brooks

  "So how are we supposed to get great architects, if
  they only get the chance  to architect fewer than
  a half-dozen times in their career?"

                         Ted Neward

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.

Rules

Doing an Architectural Kata requires you to obey a few rules in order to get the maximum out of the activity. Read Rules »

Rules

The rules are broken down by the different Phases of the exercise. However, one rule trumps all the others: Any other questions that are not already covered by these rules, you may ask the Moderator about. When in doubt, ask.

Preparation: Getting your project team together

The first step is to assemble your project team. There are only a few rules regarding the composition of your team:

Co-workers may not be in a group together. Obviously in some cases (such as when this is being done internally within a company) this will be impossible; in that case, seek to avoid teaming up with people with whom you work regularly.
Make sure you’re sitting a little distance from any other project team. You’ll want to make sure you can converse with your team without a lot of competition noise from other teams.
None of you will really need a laptop. The point of this exercise is not to spend the entire time looking stuff up on StackOverflow or on Google/Bing/Yahoo. At the worst, you’ll want a silicon-based device to access this site, and to maybe help organize your thoughts.
Procure supplies. However, having notepads, whiteboards (if they are available in the room), and/or flip-charts to scribble on and debate over are very helpful, and it might not hurt to score a few before the other project teams take them all.

Once that’s done, select your kata and proceed on to the Discussion Phase.

Discussion Phase: Figuring out what you’re building and building it

For the next “N” minutes or hours (depending on what the Moderator tells you), your project team will now examine the requirements for the kata as given, and work out a rough vision of what the project’s architecture will look like.

You may ask the Moderator any questions you have about the project. The Moderator is your customer, your boss, your project manager, your IT ops guy…. Basically, the Moderator is everybody except you.
Any technology is fair game. Customers really don’t care, most of the time, what kind of technology you use… until they care, anyway. Just because this exercise is being done at a particular conference or user group doesn’t imply the Moderator requires you to use that technology; if something else makes more sense, run with it! Just be prepared to defend its use during the Peer Review Phase.
You may safely make assumptions about technologies you don’t know well. However, any assumptions you make under this rule must be clearly defined and described during the Peer Review Phase.
You may not assume you have hiring/firing authority over the development team. No assumptions of developer All-Stars; assume that a development team roughly as skilled as the one you work with on a daily basis will be doing the implementation.

The Moderator will give you some kind of audio and visual cue when your time is getting low, and then at some point, time will run out and it will be time to move on to the Peer Review Phase.

Peer Review Phase: Presenting your architecture to the rest of the group

During this phase, your project team will be doing one of two things, either presenting to the rest of the group, or listening to other groups’ presentations.

If you are presenting, you must…

… present a vision of your proposal to the rest of the group. If you have not yet selected a speaker (or speakers) for the project team, now’s probably a good time to do so. Remember that “brevity is the soul of wit”, and keep the presentation to a speedy minimum. The Moderator can describe the requirements of the project to the rest of the group if necessary, and will speak with the customers’ voice during your presentation if required.
… answer questions from the others about your proposal. Remember, these are questions about the project, not about you or your overall technical skills. As difficult as it can be sometimes, try to remember that these are not personal assaults on your character or your professional integrity, but attempts to find the holes in your thinking that you’d rather be found before the project ships.

If you are listening to the other groups, then your job is to ask questions of the project team currently presenting. Please try to keep the questions constructive, but feel free to openly question any choice or decision that you think might not have been carefully examined or thought out. If the conversation devolves into a shouted “Yes it does!”/”No it doesn’t!” kind of back-and-forth, the Moderator may send you both to your room without dessert. Remember that project teams may assume anything about a technology they don’t know well, so long as that assumption is clearly spelled out; if they assumed something that you know to be false, by all means inform them of that, but bear in mind that someone else in the room may have different experience with it than you, and keep an open mind.

Voting Phase: Final feedback on the proposal

After each project team has finished their presentation, then we move to the voting phase. The Moderator will call out a “1-2-3”, and you will each individually give the project team an overall feedback vote:

Thumbs up: You thought they nailed it. They had answers for all of the obvious questions, they had chosen tech that at least seems credible and feasible, and they have a basic vision of the project that doesn’t have many (or any) murky areas. This doesn’t mean they have every answer, or that they have already produced a UML diagram, it means that you have every confidence they could produce them given enough time.
Thumbs “meh” (out to the side): You thought they missed a few things, enough to make you a bit uncomfortable that they really have a clear vision of what they’re trying to build. They forgot some key questions to ask the customer, they forgot some important aspect of the project, or they just in general didn’t give you the feeling that they really “got it”.
Thumbs down: You thought they missed it, badly. They made major assumptions that you think had no validity to it. They never asked the customer any questions and got burned on a few bad assumptions as a result. They thought that using assembly language to build a website was a good idea. They really bungled the job, and you would never want to work on this project.

But all is not finished! Once the voting is complete, the ancient Klingon proverb must be heeded: “Revenge is a dish best served cold”. The project team departing the stage chooses the next project team, and we repeat again by going back to the Peer Review Phase for a new project team.

List Katas »

Random Kata »

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.