I first got into contact with this notion at the SoCraTes conference in 2012 when Benjamin facilitated not one, but two sessions. Unfortunately then I could not have attended as I was too tired from the sessions I had facilitated.
Last year I met again Benjamin at the XP Germany conference. Then I really attended his session. You can read more about that here.
We (mostly my brother Alex) decided to bring this Architectural Kata to the Bucharest community. And last week we had the first one.
The main idea behind this concept is that you cannot be a good architect if you do not have the experience. If you are an architect you create maybe 10-15 systems in your life, so that is surely not enough to be a good one. So with this session we do a repetitive exercise of creating architectures for some requirements.
The requirements are not at all complete, and the architects need to ask a lot of questions to the facilitator to help them guide towards the good system. Often the groups do not ask enough questions, as I did not ask enough questions when I was in the group at XP Germany.
Probably the most important restriction in this session is that we focus on non-functional requirements, which is what architecture should be. This may be difficult, even if it seems simple, because if we are programmers we are so used to thinking about functionalities. It is a very useful exercise to understand another totally different point of view when looking at a system.
I chose to be a facilitator and not an annoying facilitator as I usually am. I did not ask a lot of questions, I just answered the questions from the audience; answers useful for completing the requirements. The main objective was to help everyone have anything they need so they could learn from the interactions and discussions, and nothing more. My specific message was “I will not teach you architecture”.
I made a short introduction by using these slides, used throughout the session because they contain the requirements. During the introduction I mentioned as well that they will work in groups of five people, for half an hour. After this work period two of the three groups needed to present their architectures to the world, and defend them from the questions of the audience. After that the groups would change and they would work on the second set of requirements. Again after the half an hour period they two of the three groups will present their work. It is very important that in the groups the people do not know each other, if possible.
Another very important aspect of the session was that we do not care about the technology, but all the assumptions the team makes need to be made clear. I recommended several times to everyone to make the explicit ideas implicit and note them down.
After this first set all the three teams said they thought about the same concepts, and only one of them made a longer presentation. It was not really true, there were some differences between the three architectures, but you cannot force anyone to present something, right?
We discussed a bit over the architectures of these requirements and here is an example of architecture made by a group:
It’s not a good or a bad sample, is just one that I could get my hand on.
I was happy towards the end of the session that everyone was so involved, and wanted to add their contribution to the final architecture. Nevertheless, for continuous improvement, I asked everyone to write on yellow post-its what they liked about the session, and on pink post-its what could be improved. Here is the result:
Many thanks to everyone that attended and to UberVu for hosting this meeting.
You can find more about Architectural Katas on the website http://architecturalkatas.site44.com