In our last post, Scott talked about code katas as a tool for learning a language. Today, I’m going to introduce you to another type of kata!
At CodeMash 2024, I was able to catch the workshop on “Thinking Architecturally” by Nate Schutta. I was excited to hear he was going to use architecture katas, as I had run into Ted Neward’s collection of architectural katas in my software architecture studies. In this post, I will introduce you to this exercise and share lessons learned.
What’s an Architecture Kata?
I like how Ted Neward put it:
“So how are we supposed to get great architects, if they only get the chance to architect fewer than a half-dozen times in their career?” —Ted Neward
As software architects, we should be able to look at these katas, apply the skills we already know, and sharpen the skills we’re learning. The architecture katas allow us to practice being software architects with sample projects that are relatable. When architecture katas are worked on in a workshop environment, they are typically done in groups of 3-5 people with about 4-10 groups. The facilitator of the workshop acts as both the timekeeper of the overall workshop as well as the product owner/customer for the selected kata. The groups review their project, ask the customer questions, discuss options that could work, and then present a solution to the other teams. As teams present their solutions, other teams can challenge their decisions. At the end of the peer review, there is a voting phase - where you rate how the team finished - great solution, meh solution, or a scary solution.
CodeMash 2024 Workshop Ideas
During Nate’s workshop, we took a different approach.
- Find a team and a kata.
- Review the kata and seek out more clarifications on requirements from the customer.
- Identify quality attributes within the project.
- Rank quality attributes on importance.
- Think through possible fitness functions for the kata.
- Decide what
Exploring Quality Attributes
He introduced the concept of quality attributes, a term he prefers rather than the traditional “non-functional requirements”. We also know these to be known as “-ilities”, as many attributes end in “-ility”. Some examples of quality attributes are performance, scalability, reliability, security, maintainability, and usability.
In this workshop, we used katas from the Fundamentals of Software Architecture. My group was made up of the guys sitting near me and me. We decided to leave our fate in the hands of the random kata link and ended up with Tales of a Fourth Grade. As a mom to a 4th grader, I found it very funny that the randomness came out like this.
Once we were in our groups and found a kata, we needed to look at the requirements and question them. As we reviewed requirements, we also made note of the quality attributes. It’s interesting to see all the quality attributes we identify, especially as we all came from different background and different experiences.
After we identified the quality attributes, then we prioritized our quality attributes. With this group, I don’t think we stressed Security enough. Between compliance, recently added security (which could be something reliable or something roll-your-own and shady or somewhere in between), and a competitor’s data breach, we saw a hot bed of security issues. These were how we ranked our quality attributes:
Identifying Fitness Functions
After ranking the quality attributes, Nate introduced fitness functions. Fitness functions in software architecture are criteria used to evaluate the suitability of a software system or architecture to meet specific quality attributes. Fitness functions help ensure that the system behaves as expected under various conditions and that it meets the desired standards.
Fitness functions act as measurable objectives or constraints that guide developers and architects throughout the software development process. They serve as benchmarks against which the system’s performance and behavior can be assessed.
These are seen as “to-do lists” for developers from architects. This allows architects to set the goals of the system, possibly with some automation to help ensure that the guidance is followed. Fitness tests could be implemented through practices such as automated tests, monitoring and metrics, code analysis, and including these in CI/CD. Some of these tests may be able to be automated through something like ArchUnit (Java) or ArchUnitNet (C#).
For our team, we had to identify potential fitness functions. For our guidance, we had recommendations both in the software level and at the network level, recommending firewall configurations, multi-factor authentication, Sonar for code analysis, looking at usability tests, and adding accessibility checks in our CI/CD pipelines.
Architectural Decisions
In the last part of the workshop, we needed to consider some of the solutions for our kata. As we talked through potential solutions, we also walked through which of those would work well and which would not.
Nate introduced the concept of Architectural Decision Records (ADRs) at the end. As soon as he mentioned documentation, the room cleared out a bunch. With ADRs, we can make our documents as rich or as lightweight as needed by the organization. However, these are some things you will want to capture:
- Title
- Status: such as Proposed, Accepted, Deprecated, and Obsoleted
- Problem Definition
- Options to Consider
- Pros and Cons of each Option
- What options were eliminated? Why were they eliminated?
- What option was chosen?
- What are any expected consequences or outcomes from this decision?
The key is that you want to capture these in context. Future you does not have the context of the chaos around current you’s decision, so if you need to document for anyone, document for future you!
Conclusion
Throughout this workshop, it was great to think like an architect. It was great to be reminded of all the things that happen up front ahead of the coding. Too often, we want to jump into code to help get to our solutions, when in reality, you aren’t going to need it. Start with conversations and assessing the situation from a high level standpoint. Question the scenario. Come up with as many solutions as you can - even if they sound totally absurd. Eliminate the obviously not right ones, and then work on finding one solution that works. Rather than waiting until the end - work on the ADR while talking through these decisions.
If you want to be a better architect, sharpen your skills with an architecture kata today!