My First Architecture Kata — and Why You Should Experience One

There’s something uniquely transformative about entering a session with nothing but a blank page and a burning curiosity to learn. My first Architecture Kata session was exactly that. What I found was a space where exploration, learning, and hands-on collaboration met.

I got an invite to join an Architecture Kata that came highly recommended for anyone eager to stretch themselves. I was excited but also unsure. What even is a Kata? What makes an Architecture Kata different? Will I be able to keep up? Do I even belong in a space like that?

I didn’t have a detailed plan. Just enough curiosity, a few Google searches, and a willingness to say yes. That’s all it took.

Here’s what I found out:

Kata, unlike the martial arts reference you might expect, is a structured, repeatable learning exercise. It uses real-world problems to encourage deep thinking and collaborative problem-solving. Might be a 2+ hour(less or more) focused session, working with others to break down a challenge, design a solution, and reflect.

Architecture Kata takes it a step further. It’s a practice space for software and systems architects. You take a real problem, team up with others, and design a solution using frameworks like the C4 model. It’s less about theory, more about working things out in real time, then stepping back to reflect on the approach and what can be improved.

Designing "Where’s Fluffy?"

The project for the day was as human as it gets. We were tasked with designing a solution for a missing pets platform: Where’s Fluffy? A community-based service to help locate lost pets, track sightings using GPS, and manage rewards for finders.

It might sound straightforward at first glance, but designing such a system meant thinking deeply about scalability, user experience, and, importantly, how to communicate our design using clear and relatable concepts.

Team Green, Let’s Go!

Our team was dubbed Team Green. We started by understanding the problem in depth. Then we mapped our solution using the C4 model. We discussed trade-offs. We considered scale, accessibility, and clarity.

At first, I was quiet. Everyone in my breakout group seemed to know more. But I asked questions anyway, about the C4 model, about the terms flying around. Looked things up on the go. And that changed everything. My questions opened up the room. The more I asked, the more I understood. It stopped being about having the perfect answer, it became about being present, curious, and engaged. That choice changed everything. The minute I allowed myself to not know, deeper conversations opened up. And I felt it, real learning.

We came up with this problem statement:

People who lose pets often post on Craigslist or paste fliers. This platform should help manage sightings, confirmations, and rewards in an organized, local, scalable way.

We broke it down further:

Users:

• Pet owners

• Pet finders (everyday people)

• Local businesses and admins

Key Use Cases:

• A pet owner reports a missing animal and optionally adds a reward

• A finder spots a pet, uploads a picture, shares the location

• The system verifies the sighting, notifies the owner, and processes the reward

• Other users can comment (e.g., “I searched this street, no sign,” or “Saw the pet near the park yesterday”)

The C4 Model was our guiding framework. Here’s a brief look at its layers and how we applied them:

System Context: This top layer defines the scope by identifying who interacts with the system and their needs. This is all about understanding the big picture. Who uses the system? What external actors interact with it? For “Where’s Fluffy?”, stakeholders ranged from pet owners and finders to local businesses that could get involved.

Containers: Here, we envisioned the major technology components. Containers are like the large building blocks of the system. This level focuses on the major applications or services that make up the system, like the web interface for pet owners, the mobile app for finders, and the backend servers handling data.

Components: Each container was further broken down. For instance, the mobile app needed distinct modules for notifications, verification of pet sightings, and social interactions (like comments or feedback).

Code (Optional): While we didn’t dive deep into code-level details in our session, the C4 model reminded us every component leads back to real code. Architecture isn’t just abstract, it’s what helps code make sense at scale.

Taking an "abstraction first" approach helped. We could focus on the big picture before worrying about details. It reminded me of experience in product design, where clarity, empathy, and purpose guide the process. We used Miro to design everything visually. It felt quick, clean, and collaborative. Coming from a product design background, I noticed the parallels, where product design leans into aesthetics and usability, architecture leans into structure and stability. Both crave clarity. One shapes the interface, the other the engine under the hood. With limited time, we couldn’t flesh out everything, but the process was enriching. We wrapped up the session by presenting our design and articulating our rationale. I appreciated that the exercise wasn’t about perfection. Instead, it was a raw, iterative process, highlighting what we planned, what worked well, and what needed further thought.

Reflections, Takeaways & Why I’ll Be Back

The final reflection exercise was the most rewarding part prompting us to think critically about both successes and shortcomings. It made me think beyond deliverables, what went well, what I’d improve, and how to approach the next challenge differently. That moment of reflection tied everything together for me and I’ve come to realise these are the moments that shape confidence, not just competence.

A few takeaways:

• Don’t be afraid to say you’re new. It opens doors.

• Architecture is as much about collaboration as it is about code.

• Always do a bit of research, it adds depth to your contribution.

•Curiosity is the best prep tool. Even better than perfect diagrams.

Although I briefly mentioned the importance of speaking up, the real learning came from actively questioning and exploring best practices during the session. Toward the end, I asked the host for extra tips on:

Tool Selection: We discussed the effectiveness of digital tools like Miro, in translating complex ideas into clear diagrams and how the right tool can simplify the design process.
Best Practices: The response was nuanced, there isn’t a one-size-fits-all. Instead, use what works best for your team and context. The key takeaway was to balance practicality with proven architectural principles.

That one session prompted hours of follow-up learning, and I’m glad for it. Architecture Katas aren’t just for architects. They’re for thinkers. For builders. For explorers. For anyone curious about the “why” behind the systems we build.

If you're even slightly curious, check out my project:
GitHub: Where-s-Fluffy-C4-System-Architecture

And if you’re thinking of joining a Kata, do it! From the calm and professional facilitators to my fellow architects-in-training, the vibe was wholesome and welcoming. It reminded me that we all start somewhere, and starting with questions is more than okay. I also recently joined the Group Coding Session (GCS) a hands-on coding meetup where we tackle katas, Test-Driven Development (TDD), and software design in a fun, supportive environment. So, if you’re an aspiring architect, developer or just someone who wants to understand systems a bit better, trust me this is a community you want to be part of. Join them here: Tech Risers Women

And bring your blank page. You’ll be amazed at what fills it.

Till next time,

Love & Cloud,

Babsbarokah