Lessons learned from an architecture kata: Workshop insights and design approaches
1 Introduction
Last week, I had the opportunity to lead a workshop on Software Architecture at Riviera Dev.
With the help of my colleague Yassine Benabbas, more than sixty participants learned and improved their design and architecture skills through a three-hour Architecture Kata based on a (not so) real-life use case.
If you are not familiar with Architecture Katas, I suggest you take a look at the following links:
- A video captured during a conference and the slides where I introduce the concept.
- An article from the Worldline Tech Blog.
In this article, as a follow-up, I will present some of the solutions proposed by the participants and then share my own proposition.
2 The Kata
Before diving into the different solutions, here is the Kata (in French).
In short, the main objective was to design an innovative digital platform to promote sustainable and solidarity-based tourism. The platform targeted eco-conscious travelers, local ecological associations, and responsible tourism service providers.
Key features included user profiles with eco-friendly booking options, carbon footprint dashboards, gamification, and activity tracking. Associations could publish volunteer initiatives and gather support, while service providers could manage eco-labeled offers and reservations. IoT sensors monitored environmental quality, and integration with connected mobility enhanced eco-actions.
During this workshop, my colleague and I did our best to help more than ten teams design this platform. We assisted them in making assumptions, overcoming the blank page challenge, and validating their designs.
I present here three solutions. The first two drafts were created by two different teams and are published with their agreement.
3 First proposition
Most of the attendees worked at Amadeus. They definitively used to with this kind of use case. Among of them, Christian Ceelen and his team proposed this solution.
Here are some the diagrams made by Christian, and to be honest I was totally impressed!
4 Second proposition
This proposition was submitted by Nikita Rousseau and his teammates:
You could find below his feedback and take-aways in French:
Les challenges :
- très peu de temps avec beaucoup de personnes 6P
- Faire un tour de table pour identifier les contributeurs et adapter le niveau de langage entre les acteurs
- Clarifier les termes et objets métiers qui vont être impliqués lors du design (parler d > experience pour coupler les notions du transport + hébergement + activité écolo + score)
- Faire des workflows pour expliciter l’aspect fonctionnel de haut de niveau et vérifier que l’on répond au besoin
- Construire une maquette HLD qui implèmente les workflows (on parcours les fleches pour vérifier que l’on construit un système cohérent)
- Grouper par aspect fonctionnel pour ensuite proposer une implémentaiton technique
They started working on a whiteboard but switched on DrawIO.
Below their design:
4.1 High level design
4.2 Low level design
5 My proposition
Although I tried to create this design under similar conditions as the participants (within about 2 hours), it doesn’t fully represent what can be achieved during a real Kata. In an actual session, you spend time debating and understanding the perspectives of different stakeholders. Among other things, it needs to be challenged by peers.
In summary, this is just an example of what could be designed based on the Kata topic. Feel free to reach out if I missed something (and I probably did!).
5.1 My approach (in nutshell)
Here are some of the guidelines I gave to the attendees:
- Start asking “Why a new app?
- Pinpoint the Business & Non-Functional Requirements and the key figures
- Dig into the design step by step
Furthermore, when some of them were completely stuck, I gave this pice of advice: start identify the main business flows and design your platform upon these ones.
Finally, throughout the design, it’s really important to focus on the core business and give the opportunity to re-use external services.
5.1.1 Business Flows
- Searching, booking, traveller profile & dashboard
- Local & sustainable activities publishing, enrollment & management
- Communication
- Payment, donations
- IoT metrics gathering & dashboards
- Mobile & Web interactions
5.1.2 NFRs
The NFRs (RTO, RPO) are very well described in the document. Both the RTO & RPO definition are prioritized according to the business functionalities.
For instance, we can check that the financial transactions are highly criticals. Therefore, it makes sense to reuse and buy an external service which could handle such a requirements.
5.1.3 High level design (System View)
5.1.3.1 Assumptions
As said above, I chose not to implement the payment/donations functionality and use/buy an external service. It helps me avoid dealing with the strong RTO & RPO and the related compliancy (i.e., PCI-DSS).
Then, I chose not to include the IoT sensors in my design. Instead, I decided to require all sensors to comply with a mandatory service contract.
5.1.3.2 Actors & external systems
I identified the different actors :
- Traveller
- Sustainable Travel Service Provider
And the external services:
- IOT Devices
- PSP (Payment Service Provider)
5.1.3.3 Design
5.1.4 Low Level Design (Container View)
5.1.4.1 Traveller Portal view
5.1.4.2 Local Organisation Portal view
5.1.4.3 Service Provider Portal view
5.1.4.4 IOT Carbon Efficiency Monitoring
If you want to browse the documentation with the help of Structurizr, you can check out the model here.
6 Conclusion
You probably noticed some differences between the three propositions. This is perfectly normal—depending on background, experience, and available time, people may choose different approaches.
As the saying goes: put three architects in a room with one platform to design, and you’ll probably end up with four solutions.
Jokes aside, when faced with such dilemmas, it’s best to choose the simplest and most adaptable solution.
Furthermore, I explained the whole approach in these slides.
Finally, the final design diagrams are only a part of the take aways.
Practising Architecture katas on a regular basis also enable:
- Learning from the experience of his/her peers
- Deep diving into a new subject in a short time
- Taking decisions, assumptions
- Communicating and explain the design decisions (perhaps the most important part)