Book Club: Fundamentals of Software Architecture – Architecture, Metrics, and Leadership
This is an AI translation from the original post here.
We held our first book club session and reviewed the opening chapters of the book along with our observations on software architecture. Many focused on modularity. The discussion moved from practical examples to the architect’s role and even to technology tracking.
Modularity and How to Measure It
The section on modularity sparked the most discussion. The book’s mathematical models for cohesion and dependencies felt useful. They offered a new angle for the architect’s work, where metrics are often missing.
We noted that metrics could be weighted so that low-use parts with poor cohesion do not skew the overall picture. We also compared the ideas with Clean Architecture, which is practical even if it measures things less precisely.
On the tooling side, ArchUnit from the Java world came up as a way to enforce package-level dependencies. We also noted that build-time restrictions can help maintain modularity. The frontend side has fewer tools, and component-based development brings its own challenges.
We also discussed how organisational culture and the tech stack affect modularity. Node projects and enterprise systems live in different worlds, and this shapes architectural choices.
Architecture Katas and Workshops
The architecture katas found on the book’s website drew interest. They offer exercises to test design thinking.
We introduced a few exercises and suggested running a workshop. Hands-on work grows skills better than reading alone. We agreed to share materials in Slack and find a suitable time.
Bringing the Technology Radar Into Development
ThoughtWorks’ Technology Radar received positive feedback. We saw it as a helpful way to track technology and guide competence development.
The radar works well for consultants and developers as part of career growth. It also offers a tool to align technology choices at a company level. It can reduce hype and help ensure investments go to the right areas.
We also discussed how the radar could link to performance reviews and competence matrices. It gives a clear basis for which technologies to deepen and which ones matter less.
The Architect’s Role in Practice
The book described the architect’s role in a way that prompted a lot of discussion. The author wrote from an enterprise background where architects act separately from developers. This does not match everyone’s experience, but it offered a useful comparison.
We highlighted that the architect’s main job is to justify and sell solutions to the business. One example was the debate around a 99.99% availability requirement and choosing the right level.
We shared experiences where an architect coaches teams and explains solutions across team boundaries. Active participation and working together was crucial for effective development work.
We also discussed responsibility and accountability. The book Elastic Leadership came up as good further reading, and we will add it to the Bytecraft’s library.
Next Steps
We agreed to continue the discussion in Slack and plan the next reading round for next year. We will consider shorter and more frequent reading segments to make participation easier and to welcome new readers.
Workshops on the architecture katas are on the way. We will also explore how to integrate the Technology Radar into the team’s competence development.
