I finished reading Fundamentals of Software Architecture Book, and these are my personal notes based on my understanding of the book. It’s like a documentation for myself first to back into it for refreshing my mind when needed.
I didn’t take everything, only what stood out to me or what I had time to write down back at the moment. Some chapters I didn’t go deep into also. The last section includes my personal takeaways.
What Defines Software Architecture?
Software architecture consists of four main components:
1. Architecture Characteristics
These describe what the system should do, its capabilities and qualities. Examples include performance, scalability, security, and reliability.
2. Logical Components
These define the behavior of the system and its workflows, how different parts interact and function together.
3. Architecture Style
Once characteristics and components are clear, we can choose the appropriate architecture style (example: monolithic, microservices, event-driven).
4. Architecture Decisions
These are the rules and choices that guide the system’s building:
- Which database to use
- Monolith or microservices
- Communication patterns, etc…
The Laws of Software Architecture
The authors define three main laws:
1. Everything is a Trade-off
There is no perfect solution. Every decision comes with advantages and disadvantages.
2. “Why” is More Important than “How”
Understanding why decisions are made is more important than the implementation itself. Context, constraints, and trade offs matter.
3. Decisions Exist on a Spectrum
Most architecture decisions are not binary. They exist between extremes, and the best choice depends on context. Its depends!!
Expectations of an Architect
An architect’s role goes beyond just designing systems:
- Make architecture decisions: guide the team in choosing technologies and approaches.
- Continuously analyze the architecture: architecture evolves with the system and must adapt to changes.
- Stay up to date with trends: be aware of modern technologies (cloud, AI, deployment…), even at a high level.
- Ensure compliance with decisions: make sure the team follows agreed architectural guidelines.
- Understand diverse technologies: not an expert in everything, but familiar with many tools and approaches.
- Know the business domain: understanding the domain leads to better architectural decisions.
- Lead and communicate effectively: facilitate collaboration and guide the team.
- Navigate organizational constraints: technical decisions always have business and organizational impacts.
Architecture vs Design
The line between architecture and design can be blurry, but generally:
- Architecture
- Involves significant trade-offs
- High-level and strategic
- Requires more effort
- Design
- More tactical and detailed
- Easier to change
- Involves fewer trade-offs
Risk Storming
Risk storming is a technique used to identify and evaluate risks in technical decisions.
- Risks are categorized (low, medium, high)
- If someone marks something as high risk, it’s discussed
- A major red flag is when someone doesn’t understand a technology being used AT ALL.
It’s not a one time activity, it continues throughout the system lifecycle, in dev and in support.
Architecture Diagrams
Being able to visualize architecture clearly is a critical skill.
Popular diagramming standards:
- UML
- C4 Model
- ArchiMate
Building Effective Teams
An architect’s role is not the same as a developer’s.
- Define boundaries
- Guide collaboration
- Enable teams to work effectively
This is often harder than it looks.
Leadership and Communication
Strong negotiation and leadership skills are essential.
Architecture decisions often involve balancing different perspectives and constraints.
My Personal Takeaways From Reading This Book
- Developers should learn software architecture, even if they’re not architects yet
- Architectural knowledge improves how you design and build systems
- I want to continue growing as a software engineer FIRST,
- In the future, I’m interested in moving toward architecture
- But I don’t want to detach myself from coding