Architectural Kata
Mon, May 20, 2024, 3:00 PM - 6:00 PM (UTC)
Event information
Do you know the Architectural Kata exercise? And would you like to participate in it? 📅 Join us on May 20 and come enjoy an evening full of teamwork, interesting discussions and new perspectives on software architecture! 🙌🏻
How will it work? Find out below.
The goal of the Architectural Kata is to create a software architecture design 👉🏻 to try out a new approach that would not be possible in your regular work, 🪄 to incorporate new technologies, 💬 to discuss, 🧑🏻⚖️ to be able to justify your choices, 💡 to learn something from others.
The whole Kata will consist of 3 steps:
1️⃣ Preparation:
Introduction to what an Architectural Kata is
Grouping into teams of 3-5 people (it is better if co-workers are not in the same group)
Each group receives an assignment that is the same for all
2️⃣ Software Architecture Design:
90-minute session where all groups design a software architecture
Questions are directed to the moderator, who moves between groups
Groups can use any technologies, but must be able to justify why they used it
3️⃣ Presentation and Evaluation:
Each group presents its design, others can ask questions
Following the presentation, there's a thumbs-up evaluation, the group with the most thumbs-up wins
Overall, it will take 2-3 hours.
Other information
More sneek peak information 👀 ⬇️
Every team may interpret the Architectural Kata a little differently. Generally, delving into aspects such as codes is quite a significant detail. What is meant by the “architecture” term is whether it will be a monolith? Or microservices? In case it's microservices, what types? How will they communicate? Through APIs? Message queues? Which one? RabbitMQ? Why? What about the database? Relational? NoSQL? Is one database enough or do we need more? Replication? Data synchronization? Do we need caching? Why? What kind? Redis? Why? What about scalability? Is one server enough? Multiple servers? Do we need a load balancer? Will the traffic be evenly distributed throughout the day/week/month or will there be peaks? How will we handle that? In what technology should we write it? Java? Node.js? PHP? Go? And why?
These and other questions need to be answered with consideration for the specific task, which may have various constraints such as time or budget. For example, if the system needs to be completed in 2 months with a limited budget, then simpler solutions must be chosen compared to a project with a 2-year timeline and practically unlimited budget.
The exercise is time-limited (90 minutes), and within this time, it's obviously not possible to design the entire system perfectly. It depends on each group what they want to focus on more and which direction their design will take. It would be good to have an output at the end that can be presented to others. But if a group, even after 90 minutes, has nothing to present, no one will be penalized. You can at least learn something from others, and next time, you'll do better.