Architectural Kata – Budapest

The book Facilitating Technical Events is for technical trainers, coaches, events organizers who want to have a good event flow and happy attendees.

Architectural Kata Budapest

Following the invitation of Zsolt Bodo I facilitated an Architectural Kata in the Budapest Agile community. The purpose of the session was to let the attendees speak about architecture and I was merely a facilitator. My other role was the customer, clarifying the requirements whenever the audience requested.

The concept remains the same as for the first Architectural Kata I facilitated: you cannot be a good architect if you do not have the experience. An architect creates 10-15 architectures during the whole career, so we need to practice to become better architects. This session is exactly a repetitive exercise of creating architectures for given, unclear, requirements.

Architectural Kata Budapest

I explained briefly the concept: we are here to practice, I will not teach anyone architecture, you will learn one from the other. The most important restriction is that we focus on non-functional requirements; some of the groups had issues with defining “non-functional requirements”. For the session I used these slides.

We formed three groups of roughly five people. All of them had paper and markers to create the architecture. Two out of the three groups would present their architectures to the audience. The audience needed to ask the annoying questions.

The first requirement set was an application that enabled a national sandwich shop chain to sell their products on an online platform.

The first set of requirements

We had two out of the three groups presenting their architectures. Both of them were interesting and captured some of the requirements. You cannot create a whole architecture with people you do not know in 30 minutes. That is the whole idea in fact, we just need to focus on the most important parts of the system. All the other parts we can ignore, or we can make assumptions that they are externalized or will be dealt with later.

Both of the architectures had the cloud somewhere out there. It seemed to be the theme of the day: how to architect with the cloud.

We had a pizza break, talked a bit and then we went on, with the energy that we had left, to create wonderful architectures.

The second set of requirements were for a publisher that wants to have a system to publish books in beta version. During this period the authors could publish chapters and the early buyers could review them. At one point when the book is finished the published may take the decision to publish the book also in the form of dead trees. This is why the name of the requirements is called Agile Dead Trees:

The second set of requirements

The general feeling was that these requirements are simpler. Nevertheless all the groups expressed the nice technical details, but the business essentials were lost. The architectures did not express that well how could you sell a book, so which is the purpose of a publisher if not selling books? Here is one of the architectures that was created:

It was Friday evening and we were dealing with architecture. This says a lot about the group being passionate and willing to learn. And because during this session learning comes from interactions I asked everyone to write kudo cards. Anyone that told you something new or helped you should receive a kudo card, mentioning why you want to thank that person. Here is one nice kudo card I found laying on the table after everyone had left:

Of course, learning comes from both directions. So I asked everyone to write on post-its what was good about this session and how could we improve it. Here are the results: