In case I haven’t mentioned it yet, the word of the year for me in 2024 is architecture. It’s what I’ve been eating, sleeping, and dreaming of for awhile now. When I was doing session review for CodeMash, I couldn’t be any more excited about this workshop when I read about it. An opportunity to talk with other architect minds?! Let’s go!
Architect without the Title
In this session, Nate Schutta got us thinking about being software architects. For many of us, we’ve held the role without the title – and for some of us, we have a lot of imposter syndrome because we haven’t had an official architect title.
This was critical for me to hear, as I’ve had to make architectural decisions on applications a lot throughout my career. I don’t stay in one lane, and I do the research, which is why I tend to be the go-to for many people when there are tech questions on projects. I’ve been an architect without a title, and it means a lot to hear others’ adventures in that world as well.
Architectural Katas
Much like there are coding katas to sharpen your coding skills, there are also architectural katas to test your software architectural chops. Before getting into the activity part, Nate presented the katas as well as quality attributes and “-ilities”.
Nate used a demo kata about self-driving cars in order to talk us through how to work through an architectural kata. He showed us some requirements and notes on this project and had us challenge some of the attributes using questions like:
- How?
- Why?
- Always? Never? Really?
- What is “extremely high”?
After identifying the quality attributes, Nate mapped each of those attributes to the various “-ilities” – such as:
- Security
- Availability
- Maintainability
- Usability
- Scalability
- Reliability
- Efficiency
(Yeah, they don’t all end in “ility” – just run with it.)
After mapping quality attributes to their respective categories, then it comes time to prioritize the categories.
Some key points Nate stressed for us as architects is:
- Establish guidance for the system with the understanding that…
- You can’t be in all places at all times.
- You can’t be involved in every decision.
- Deploy and release do not have to be the same things. Use Feature Flags!
- Write tests to ensure your guidance is being followed.
- Use fitness functions as a to-do list for devs from architects.
- Alert when things get out of the acceptable ranges.
- Chaos Engineering is awesome – stress our own systems before our customers do. Test our systems for resiliency and scalability. Identify potential outages and remediate them before the code gets to production. (This sounds like a topic I need to explore more! Did someone say chaos?! See also EventStorming.)
Activity – Architectural Katas with our Neighbors
In this workshop, Nate had us work with the people around us and either select a kata or let the Fundamentals of Architecture site select a kata at random. My group – Jeffrey Miller, Cameron Vetter, David (I didn’t catch his last name), and I – went with the random option and ended up with Tales of a Fourth Grade.
During the first part of our group activity, we reviewed the requirements and additional context proposed in the kata. It was interesting to see that the things we questioned often came back to Security – FERPA, recently added security, and competitor damaged by data breach. There were other “-ilities” that we had as well, but Security was our top one consistently.
In the second part of the group activity, we identified fitness functions that we wanted to implement for this kata. I’m not going to spoil any of that here in case someone else is going through this kata. However, in talking through our fitness functions, we also talked about how to automate these functions using libraries and frameworks such as ArchUnit and ArchUnitNET. We all agreed that having these as well as accessibility checks in CI/CD would be desirable.
Architectural Decision Records
The last topic Nate presented in the “Thinking Architecturally” workshop was architectural decision records. At the mention of ADRs and documentation, you could see people checking out and leaving. There were about 12 of us who stayed through the very end.
We talked about the things that need to appear in these documents:
- Title of the ADR + ID
- Status – such as Proposed, Accepted, Deprecated, Obsoleted
- Problem Definition/Description
- Options Considered
- Pros & Cons
- Why some options were eliminated
- Why the selected option was the one selected
- Consequences / Outcomes
Some questions came up as we talked about these.
Where should ADRs live?
Source control! And when you put them in source control, remember to link ADRs as necessary. So if an ADR is superseded by another one, link them and note it accordingly.
We don’t have ADRs currently. Could we create ADRs retroactively?
Retroactive ADRs may be better than no ADR. The downfall to creating them retroactively is that there is lost context that would have been there when the decision was made.
How long should they be?
Long enough to capture the points listed above.
Conclusion
My main goal for going to this workshop was to learn with others who are either architects by title or by experience. It was great to get some reaffirmation that my mindset is in the right place. It was good to learn about quality attributes – much better sounding than “non-functional requirements” – and how to map them to the “-ilities”. It was also great to get further insight on ADRs.
[…] Thinking Architecturally – Nate Schutta […]