Why Every Developer Should Think Like an Architect: A Practical Guide

1. Preface

Inspired by Martin Fowler’s view that an architect should raise the whole team’s capability, the author argues that architects should focus on improving team skills rather than being sole decision‑makers.

Improving the development team’s ability gives an architect much greater leverage than being the sole decision maker. — Martin Fowler

The article defines two types of architects: vertical architects who concentrate on business and system design, and horizontal architects who solve cross‑team, cross‑domain problems, set standards, and promote a unified language.

2. What Is an Architect

According to Wikipedia, a software architect designs modular systems, defines interactions, UI style, external interfaces, and high‑level logic. Core responsibilities include:

Requirement extraction : Clarify concepts and align language with stakeholders.

Identify key quality attributes : Define non‑functional requirements such as scalability, availability, consistency.

Architectural design : Choose technologies, patterns, and make trade‑offs.

Implementation : Collaborate with developers to realize the design.

Quality attributes are non‑functional requirements used to evaluate system performance.

3. Methodology

The author emphasizes a learning‑practice‑reflection loop. By internalising formulas like Vt²‑V0² = 2as, developers can free mental effort for more complex problems.

4. Vertical Architect Mindset

The article asks three questions: What is architecture? What problems must an architect solve? What methodology addresses those problems?

4.1 What Is Architecture?

ISO/IEC 42010 defines architecture as the fundamental organization of a system embodied in its components, their relationships, and governing principles.

Key elements are modules , relationships , and principles .

4.2 Problems Architects Solve

Inputs are business/technical requirements; outputs are software system architectures. Architects must understand stakeholder goals, constraints, quality attributes, major functional needs, and other influencing factors.

4.3 How to Solve Those Problems

The process includes:

Understand requirements : Identify stakeholder goals and motivations.

Identify key architectural requirements : Constraints, quality attributes, high‑impact features, and other influences.

Define use‑case set : Describe actors, preconditions, actions, rules, and outcomes.

5. Architectural Description

Various viewpoints (C4 model, 4+1 view) help communicate architecture. The article outlines the following viewpoints:

C4 Model – Context, Container, Component, Code.

4+1 View – Scenario, Logical, Development, Process, Physical.

Four main diagrams are recommended:

Business domain model.

System module diagram.

Object model diagram.

Data storage architecture diagram.

5.1 System Module Architecture

Describes layered modules, domain dependencies, and data flow. Evolution from MVC to Hexagonal to Clean Architecture is illustrated.

5.2 Object Architecture

Maps business domain models to code using DDD concepts: entities, value objects, aggregates, services, factories, repositories, and anti‑corruption layers.

5.3 Storage Architecture

Shows database tables, sharding strategies, and relationships, often using ER diagrams.

6. Conclusion

The author reflects on the month‑long writing process, emphasizing continuous learning cycles—analysis, design, iteration, and reflection—as essential for both personal growth and architectural practice.