Reading Notes: The Fundamentals of Software Architecture

These notes are from The Fundamentals of Software Architecture by Mark Richards and Neal Ford. I enjoyed it because it explains architecture clearly and helped me connect my past enterprise architecture work at Huawei to software architecture.

Why I Chose This Book

At Huawei, part of my responsibility was improving end-to-end enterprise processes. I needed to understand enterprise architecture across the entire workflow. This book helped me see the connection between enterprise architecture and software architecture:

Enterprise architecture sets the direction; software architecture makes it real.

Enterprise Architecture vs. Software Architecture

During my time at Huawei, enterprise architecture meant:

• Understanding how the whole company operates.
• Mapping end-to-end processes.
• Identifying bottlenecks, inefficiencies, and handoffs.
• Improving workflows across multiple teams and systems.

Software architecture is different:

What This Book Does Really Well

1. Architecture Is About Tradeoffs

There is no perfect architecture. Only tradeoffs.

Every architectural style (microservices, modular monolith, event-driven, and more) has strengths and weaknesses. The job of an architect is not to choose the best, but to choose what fits the business drivers, team skills, domain complexity, and operational needs.

This aligned with my Huawei experience. Enterprise architects make tradeoff decisions for processes; software architects do it for systems.

2. Architecture Is Engineering, Not Just Diagrams

Richards and Ford emphasize that real architecture involves:

• Measuring decisions.
• Evaluating coupling and cohesion.
• Understanding data ownership.
• Considering operational characteristics like latency, resiliency, and scalability.
• Documenting decisions (ADR).

This engineering mindset separates real architecture from "draw-a-box-and-call-it-architecture."

3. Architecture Characteristics (Non-Functional Requirements)

Architecture is mainly about quality attributes, not features. Examples:

• Performance
• Scalability
• Maintainability
• Observability
• Deployability
• Testability
• Reliability

This resonated with me because improving end-to-end processes at Huawei often meant optimizing for process quality attributes: reduced waiting time, reduced rework, better transparency, and more predictable flow.

Key Concepts I Found Most Valuable

1. The Architecture Quantum

A "quantum" is the smallest unit of architecture that can be independently deployed. This helped clarify when microservices make sense and when they do not.

2. Architectural Styles Explained Practically

The book does not just define styles. It compares them based on:

• Operability
• Deployability
• Testability
• Development speed
• Team autonomy

Context matters more than the style itself.

3. The Importance of Technical Breadth

Architects should:

• Understand multiple paradigms.
• Stay hands-on.
• Keep learning new patterns.
• Avoid "golden hammer" thinking.

4. How to Evolve Architecture Safely

• Incremental architecture.
• Strangler patterns.
• Fitness functions.
• Measuring success.
• Avoiding big-bang redesigns.

This is especially useful for modernizing legacy systems.

5. Leadership as an Architect

Architecture is not only technical, it is leadership. Key skills:

• Influence over authority.
• Clear communication.
• Guiding change through uncertainty.
• Empathy for developers.
• Aligning technology with business.
• Growing other engineers.

Architecture leadership is about clarity, empathy, influence, and aligning the system with both technical and business needs.

Reflecting on My Huawei Experience

Reading this book helped me reinterpret my enterprise architecture responsibilities.

At Huawei, I tried to:

• Understand how different departments interacted.
• Identify bottlenecks.
• Improve workflows.
• Help the organization move faster end-to-end.

Now I see the connection:

• Both require a big-picture view.
• Both aim to reduce friction, latency, and waste.
• Both require communication across teams.
• Both rely on measurable improvements.
• Both require managing tradeoffs.
• Both require thinking in systems.

The scale is different, but the thinking is similar.

Final Thoughts

This book is practical, real-world, and grounded in engineering discipline. For me, it created the missing bridge between my enterprise architecture experience at Huawei and my ongoing software architecture journey.