Architectural katas are a great way to spice up the architectural skills of your team or community, and practice to have productive discussions about architecture.
I always receive great feedback after (co)-organizing architectural katas 1 and I regularly get questions on organizing them with others. So with Matteo Pierro, I did run a session at XP-days Benelux 2019 on how you can organize these katas yourself, sharing experiences to encourage others organizing the same kind of katas.
Why architectural katas?
Ivory tower architects defining the architecture for your team are from a bygone era. The general trend is that development teams define their software architecture, or at least that teams are strongly involved in defining the architecture.
But people cannot learn architecture well out of thin air, they need a way to learn and practice. This was also the main motivation of Ted Neward when coming up with architectural katas illustrated by the following two quotes.
“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
Ted was searching for a way to practice defining architectures and, inspiration by code katas, came up with the concept of architectural katas.
What are architectural katas?
Architectural katas are a workshop were several small groups (3-5 people) practice discussing and designing architectures. Typically the workshop involves several iterations.
At the start of an iteration, each group gets a project description and some constraints, and gets some time to discover what is needed, ask clarifying questions to the “customer” (often the facilitator), discusses technology options, and design a vision for the architecture.
After discussing for a while, each group presents their results to the other groups to gather feedback. The iteration ends with some reflection and a break.
For more information, check out the description on the architectural kata website.
Practical organization of architectural katas
Organizing a good workshop asks for proper preparation and facilitation. It might look daunting at first, but I hope the next sections can help you on your way.
The learnings in this post are extracted from organizing events like this over 2 years, from evening meetups, conference sessions, open full-day sessions till closed company sessions. The audience for those sessions varied between 10 people and 40 people.
Preparation
Who to invite?
You can invite any team members or people in the community interested in discussing the architecture. This includes, but is not limited to, developers, testers, product owners, analysts, scrum masters, architects … It helps if the majority of the people have software development experience or affinity, but it is not a strict requirement for all participants.
No prior experience as an architect is required. I prefer a mixture of roles and backgrounds to have healthy discussions and to make assumptions explicit.
When
I run architectural katas as a workshop on a meetup, conference or in a company. As far as I understood, Ted did run it as a regular event with the same community.
What kind of environment?
Some important aspects of the environment setup are:
- Provide unlimited modeling Space: You need a good modeling space per group. To often, people will stop architecting as soon as the allocated space is full and you might miss out on some nice creativity or discussion. My experience is that very large (magic) whiteboard2 trumps a smaller whiteboard, which trumps a Flipchart, which trumps a table with Flipchart paper, which trumps table with smaller size papers.
- Room: The above requirements for a modeling space in combination with a lot of people discussing in small groups ask for a spacious room (or several rooms). People need space to discuss comfortable and the noise level must remain acceptable so people can understand each other. For larger workshops with more than 4 groups, I prefer to use several break-out rooms.
- Materials: Bring enough post-its of several sizes and forms, papers, good whiteboard, and permanent markers.
- Food / drinks: These types of workshops can be very exhausting, especially if you keep on iterating all day long. Catering for sugar dips and the need for drinks helps people to stay focused.
Projects?
Each kata starts from a brief (and intentionally vague and incomplete) project description. Ted Neward did the effort to set up a website to gather and share these project descriptions on http://www.architecturalkatas.com/.
Although the Ted talks about drawing a random kata for each group until now I always preselected the project and asked all groups to do the same project. My main motivation is to allow for a more efficient exchange in the feedback and reflection phase.
When selecting a kata it is important to think about your audience. Are they completely new to the format? Are there people with an architectural background in the groups? Do they know about embedded development? Some challenges are a lot more complex to break into than others or require specialized knowledge your audience might not have.
I like the “Room with a View” as starter kata, as most people have been in contact with hotels and thus have a basic knowledge of the domain.
Room With A View
A large hotel reservation company wants to build the next generation hotel reservation and management system specifically tailored to high-end resorts and spas where guests can view and reserve specific rooms.
Users: Guests (hundreds), hotel staff (less than 20)
Requirements:
Registration can be made via web, mobile, phone call, or walk-in.
Guests have the ability to either book a type of room (standard, deluxe, or suite) or choose a specific room to stay in by viewing pictures of each room and its location in the hotel.
The system must be able to maintain room status (booked, available, ready to clean, etc.) as well as when the room will be needed next.
It must also have state-of-the-art housekeeping management functionality so that cleaning and maintenance staff can be directed to various rooms based on priority and reservation need using proprietary devices supplied by the reservation company attached to the cleaning carts.
Standard reservation functionality (e.g., payments, registration info, etc.) will be done by leveraging the existing reservations system.
The system will be web-based and hosted by the reservation company.
Additional Context: ‘Peak season is quickly approaching, so the system must be ready quickly or we have to wait until next year!'; Company is also investing heavily in cutting edge technology like smart room locks that open via a cell phone; Only interested in the high-end market; Sales people have tremendous clout in the organization; people often scramble to make their promises true
Others I often use in the beginning are ‘Check your work’, ‘Am I Sick’ or ‘All stuff no cruft’.
Another one I always keep around for more challenge is ‘World of web craft’ because it goes beyond a simple website and thus contains a lot more challenges for most people.
Additional constraints
Similar to coding katas, I try adding additional constraints to maximize the learning effect and focus on a specific learning goal. For example, you could use a kata to learn a new modeling language or practice. Or through a constraint, you can exaggerate a practice you get it into your muscle memory.
Examples of constraints are:
- Use the C4 model to document your architectural vision. The C4 model is a simple set of models to visualize the static structure of a software architecture. By giving people a simple and standardized way to visualize their decisions in architectural models, there are suddenly a lot fewer misunderstandings and a more high-quality discussion. I typically use the following flip charts where I add the post-its one by one to introduce the C4 model.
- Explicitly try to use only existing cloud services and build nothing.
- Use all cloud services.
- A component should have only two other components to talk to.
- Use event storming to identify the behavior, and update your C4 with this.
The constraints might vary in different iterations. For example, I might give no constraint in the first iteration, use C4 as a constraint in the second iteration, use event storming to discover more behavior in the third iteration and finally update the C4 model to represent that behavior.
Facilitating the workshop
Agenda and timing
A typical cycle for a single kata session takes about 1u20 min:
- 10min: Introduction to the kata and the constraints
- 45min: Team discussion
- 15min: Review and share architecture
- 10min: Reflect and share observations
I experimented with longer and shorter discussion slots, but 45min seems to be the sweet spot where people are still engaged, but also need a trigger for new ideas. Reviewing, reflecting and starting a new cycle is a perfect way to bring inspiration.
Depending on the amount of time you have, you can repeat the cycle several times. Including a 10 minute break, a cycle then takes 1:30.
Some of the things I did:
- Session of 1h30 to 2h: A single iteration is too short to get a lot of in-depth learning about architecture. I did this several times, but I would only advise running such short sessions to convince people to try this themselves (as was my goal on some conferences and this blogpost). Or maybe if you repeat this weekly it could work, but I never tried.
- Session between 3h and 4h30: Two to three iterations start to be interesting. People can apply the things they learned during the sharing and reflection in future sessions. If I do only two iterations I typically do not change the application or groups but provide an extra constraint for the second iteration.
- Full day sessions: We got a lot of positive feedback on full-day sessions. Once you get over 4h you typically need to take a lunch break. In my experience, it is hard to do more than 4 iterations on a day. People are exhausted after that.
An example agenda for about 8h:
- 0:10 General introduction
- 1:20 Iteration 1
- 0:10 break
- 1:20 Iteration 2
- 1:00 Lunch
- 1:20 Iteration 3
- 0:10 break
- 1:20 Iteration 4
- 0:10 Closing
Your role as facilitator
Being a facilitator for architectural kata sessions is not that easy and asks for a few things
- Facilitation and time keeping: A key factor to make architectural katas a success is the facilitation. It is about organizing the room for optimal group discussion, coming up with the appropriate challenge or constraint, use the appropriate formate for sharing and the timekeeping, help groups that are stuck, …. Especially facilitation for larger groups is extra challenging, as you have to use different techniques in this context. If you feel overwhelmed by the thought of doing this, look if you can join another architectural kata session or pair with an experienced facilitator.
- Customer questions: A large part of being the facilitator is coming up with answers to questions towards the customer. The project descriptions are (purposefully) vague and short, so there is a lot of room for interpretation. Most of the time you have to make up answers on the fly or encourage them to make assumptions (and make them explicit!).
- Technical experience: It helps if you have some technical experience and some experience with architecting yourself, especially to get groups going that are a bit stuck.
- Observe and help to reflect: An important part of iterations is to reflect on what just happened, and to share what you learned from it. As a facilitator, you can ensure everyone gets the chance to share their learnings, and in the end, add some of your observations to emphasize certain aspects or strengthen certain learnings.
As you can see above there are a lot of expectations towards a facilitator of these events, and often it is hard to fulfill all these all by yourself. I advise you to pair if you can. My rule for the number for facilitating this type of event is: I can handle until 20 people on my own (but prefer to pair), and I would add one helper for 10 people above that.
Conclusion
Architectural katas are a great way to practice discussing architecture. In this modern age, Agile teams are supposed to define (or at least be involved) in architecture. So it is a good idea to practice these modeling and architectural discussion skills with teams.
I hope this post helps people to organize architectural katas in their companies or their community. If you still have doubts or if there is anything else I can do to help you organize an architectural kata, do not hesitate to contact me through twitter.
Now take up the challenge, go forth, and organize katas!
Some external links:
-
Thanks to Erik Talboom, Michel Daviot and Matteo Pierro for co-organising some of the architectural katas. ↩︎
-
Magic whiteboard seems to stick very well. ↩︎
Mastodon
