From time to time I get asked a question: "how to get better at designing systems and software architecture?". I could recommend a number of books or videos, but as you know these two alone aren't going to magically teach us how to do design. What we also need is some concrete & deliberate practice.

Unfortunately it's not so easy to get to practice architecting systems. I think one of the reasons might be that we rarely switch projects, and have opportutnity to learn about new domain and its architecture. The cycle time is long (sometimes as long as employment), and learning is slow. What we can do instead, is to set up an exercise where together with other people we can practice designing systems during short, dedicated sessions.

I've run such 2h software architecture katas during meetups and conferences in US, UK and Netherlands. I've received positive feedback, and some people asked me to share the exercises with them. Because of that it makes sense to post them publicly so you can also practice designing skills together with your colleagues or friends.

Running the workshop

Why

At the beggining of the 2h session I always state and dicsuss why we are doing it. The main reasons for me are:

• To assess and improve design and architecture skills
• Discover new techniques and heuristics
• Practice and share your skills in a minimal-constraints context

Feel free to ask participants what are their goals. They've came to the session for some reason so it's important to align the expectations.

Setup

We can't run a session without a room and some materials. In order to create a good learning environment we will need:

• A room with up to 4 working stations in a cabaret layout (4 peopl each)
• Each working station needs whiteboard or flipchart and a wall
• Pens, sticky notes and paper roll (if wall is used)

With a single facilitator in the room I recommend running the session with up to 4 groups of 4 people. There are two reasons:

• To ensure proper facilitation and make sure everyone gets attention
• To ensure that each grup has time to present at the end

Agenda

I usually run the workshop using following agenda, but it's flexible and I sometimes change it (e.g. when the group is large or small). All depends on the room, number of people and experience of the audience:

• 5 min - Introduction - explain the goals of the session (see section Why)
• 5 min - Ask participants to form groups of 4, assign working stations to them, hand over the domain descriptions
• 20 min - Ask participants to familiarise themselves with the domain:
  • Read through the description
  • Together with your group conduct a discovery phase
  • Use any technique or tool you like
• 5 min - Conduct a short retrospective (what worked, what didn't, which techiques they've used)
• 25 min - Ask participants to create a system architecture:
  • Analyse the domain and model the architecture of the system
  • List or visualise major components
  • Choose technologies and patterns
  • Focus on modelling of one of the flows
• 5 min - Conduct a short retrospective (what worked, what didn't, which techiques they've used)
• 25 min - Ask participants to prepare presentations:
  • High level overview of architecture and how it will solve business goals
  • Summary of components
  • Description of a one of the flows
  • Brief summary of the technology choices and patterns
• 20 min - Ask groups to present their solutions
• 10 min - Conduct a retrospective and wrap up

Toolbox

During the session I like to capture the tools and techniques people used and shared with each other. I write them on a separate whiteboard or flipchart, and then at the end people can take a picture of it. It's a great way of summarising what they've learned and making sure they can take something away:

Bonus: The Domain