Oh My Learning

Architectural Thinking

fundamentals/01 senior drafted · 4 min read

Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapters 1 & 2

Prerequisites hard-parts/01

Architectural Thinking#

TL;DR#

Architectural thinking shifts focus from technical details to broad systems, trade-offs, and business alignment. It means seeing how decisions affect the entire system over time. You stop looking for the single best tool and start assessing the cost of each option.

The idea#

Developers solve concrete coding problems. They focus on how to build a feature cleanly. Architects must focus on the business context, structural trade-offs, and breadth of solutions. Why does it exist? To prevent teams from building highly optimized solutions to the wrong problems or creating rigid systems that fail under shifting business requirements.

If you only focus on code design, you might build a perfectly clean codebase that cannot scale or costs too much to operate. Architectural thinking bridges the gap between raw code and business success.

How it works#

Architectural thinking relies on four key dimensions: balancing architecture and design, maintaining breadth of knowledge, understanding business context, and analyzing trade-offs.

Architecture vs Design#

There is no hard line between these two concepts. Instead, they exist on a continuum:

+-------------------------------------------------------+
|  ARCHITECTURE                                 DESIGN  |
|                                                       |
|  Structure & Styles       Continuum       Class Design |
|  Quality Attributes  ===================>  Refactoring |
|  System Decisions                         Code Patterns|
+-------------------------------------------------------+

Architecture focuses on the overall structure, decisions, and quality attributes. Design focuses on class implementation, refactoring, and code patterns. Both roles must collaborate. An architect's decisions constrain what developers can design, while developer feedback must shape future architectural choices.

Breadth over Depth#

As a developer, your value comes from depth. You know a language or framework inside and out. As an architect, your value shifts to breadth. You must know many patterns, styles, and tools, even if you don't write code in them daily.

Knowledge Pyramid:
+------------------------------------------+
|           Breadth (Stuff You Know)       | <-- Architect focus (many options)
+------------------------------------------+
|        Depth (Stuff You Know Well)       | <-- Developer focus (few options)
+------------------------------------------+

This breadth is vital because you cannot choose an alternative you don't know exists. You trade deep implementation expertise for a wider menu of design solutions.

Business Context and Trade-offs#

Systems do not exist in a vacuum. Every technical decision must support a business goal. For example, choosing microservices for a tiny startup might kill the company due to operational overhead. The startup needs speed to market, not infinite scalability.

Furthermore, there are no "best practices" in architecture. Every decision has a downside. You must analyze the trade-offs of every option.

Worked Example: The Modernization Dilemma#

Suppose a company called Sysops Squad wants to migrate their legacy desktop ticket system to a web-based setup.

Developer Perspective: - Focuses on the database schema, choosing a modern Web framework, and writing clean, reusable components. - Chooses a popular reactive library to handle real-time ticket updates because it's technically elegant.

Architect Perspective: - Focuses on the architecture style. Should they use a modular monolith or event-driven microservices? - Analyzes the reactive library choice. While developers love it, the operational complexity and team learning curve might delay the migration. - Decides to use simple polling first. This meets the immediate business goal of a quick release, with a plan to transition to WebSockets later once the core system is stable.

Pros#

  • Direct alignment between technical architecture and business strategy.
  • Reduced risk of project failure caused by choosing wrong technologies.
  • Clear, documented trade-offs that make future maintenance predictable.

Cons#

  • Slower initial decision-making because you must weigh multiple forces.
  • High cognitive load from constantly balancing conflicting requirements.
  • Risk of over-engineering simple solutions if breadth is applied without discipline.

Alternatives#

  • Feature-driven development: Teams build whatever is needed immediately without thinking about overall structure. It's fast at first but leads to spaghetti code.
  • Framework-driven design: Choosing a framework early and letting its opinions dictate the whole system. This saves time if your system matches the framework's sweet spot perfectly, but it locks you into its limitations.

When to use it#

  • When systems grow beyond a single team or a simple service.
  • When business requirements change frequently.
  • When operational problems like high latency or downtime start hurting the business.

When NOT to use it#

  • Tiny prototypes or simple CRUD applications with a short lifespan.
  • Static marketing websites.

Key takeaways / mental model#

Stop looking for the "best" framework or pattern. Ask: "What are the trade-offs of this option in our specific business context?" Breadth of knowledge is your primary tool for finding these trade-offs.

Self-check questions#

  1. How does architectural thinking differ from developer thinking when picking a technology?
  2. Why is breadth of knowledge more critical than depth for a software architect?
  3. What is a concrete example of a technical decision that makes perfect technical sense but fails in its business context?

References#

  • Fundamentals of Software Architecture (Richards & Ford, O'Reilly 2nd ed. 2025), Chapters 1 & 2
  • hard-parts/01