How Structured Thinking Can Transform Your Technical Architecture Design

Common Thinking Methods

Technical thinking is essentially structured thinking, so common structured‑thinking techniques apply. Below are two groups of methods: one for technical architecture design and another for technical leaders.

Technical Architecture Thinking Methods

0→1

When faced with confusion, first restore the objective facts of the problem and quickly create a minimal version (the "1") that can drive discussion. Everyone iterates on this simple version until consensus is reached.

User‑Perspective Objective World Restoration : Describe the scenario from the user’s view using interaction flows or simple tables, not complex module diagrams.

Structured Integration and Refinement of Objective Information : Transform the initial "1" into structured knowledge by consolidating and refining data, e.g., merging similar data streams or balancing validation logic.

Multi‑Perspective Validation and Abstraction : Enrich the "1" with additional dimensions such as exceptions, ROI, and feasibility to ensure a complete, implementable solution.

1→0

If a proposal becomes tangled, use the deletion method: remove elements to see which are truly decisive, ensuring you focus on the key factor.

1→2

Break complex problems into smaller parts (divide‑and‑conquer) and solve each sub‑problem, reducing overall difficulty.

Depth Decomposition : Perform organic, not purely physical, decomposition to identify key actions rather than assigning responsibilities arbitrarily.

Horizontal Dissection : Layer the problem (business, product, technical) to clarify each aspect and avoid cross‑talk.

1→N

When scaling from 1 to N, consider three production assets: business scenarios, team organization, and technical architecture, and apply limited yet clear implementation while leaving room for future expansion.

Architect All Possibilities but Implement Clearly : List possible scenarios, propose concrete work estimates, and provide business choices without over‑engineering.

No Reliable People, Only Reliable Machines : Embed validation into the system rather than relying on manual checkpoints.

Anticipate "Happiness" Problems Early : Design for high concurrency and robustness from the start, even if current traffic is low.

-1↔1

Adopt opposite‑thinking: complement positive analyses with thorough examination of negative or failure scenarios to uncover hidden risks.

Positive‑Negative Thinking : Balance detailed normal flow descriptions with equally detailed exception handling.

Extreme Thinking : Ask what the worst‑case business impact would be to surface critical risks.

Symmetry Thinking : Ensure logical structures are balanced (e.g., always include an else branch) for clarity and maintainability.

M×N→M+N

Consider system coupling: replace a fully meshed network (M×N) with a backbone‑plus‑branch architecture (M+N) to achieve decoupling and scalability.

Decouple Up‑stream/Down‑stream Dependencies : Redefine module boundaries to allow independent evolution.

Decouple Role Dependencies : Separate technical architecture from business and product decisions to enable flexible choices.

Summary

The methods above are practical thinking tools for technical architecture design. They do not solve every problem but serve as prompts to inspire solutions. In the next article, the author will discuss these ideas from a technical leader’s perspective.