Why Becoming an Architect Is Really About Upgrading Your Cognition

Background

The author, an experienced architect at Alipay, writes down the knowledge and insights accumulated over years of practice, aiming to help others understand what an architect’s ability really entails.

Core Idea: Cognition as Ability

According to the author, the essence of any capability is cognition; an architect is simply someone who possesses the right architectural cognition together with general technical skills. Growth, therefore, is a process of upgrading one’s cognition.

Illustrative Example: Multithreading Interview Question

When asked in interviews how to handle multithreading and concurrency in Java, a senior engineer typically mentions using Thread, Runnable, thread pools, sync, and locks. The author’s own answer is "don’t use multithreading"—a response that received positive feedback in more than 99% of cases—demonstrating how different levels of understanding lead to different answers.

Systematic Thinking Methods

The author introduces several structured thinking frameworks that can be applied to architectural problems:

MECE Principle : Ensure analysis is mutually exclusive and collectively exhaustive.

5W2H : Break down problems into Why, What, When, Who, Where, How, How Much to cover all dimensions.

3‑Why Method : Keep asking "why" three times to uncover the root cause of any issue.

Practical Steps for Growth

To become a better architect, the author suggests three concrete habits:

Abstraction : Identify common patterns (e.g., a generic counting service) and extract reusable components.

Layered Definition : Clearly separate responsibilities across layers (e.g., business logic, platform products, service capabilities).

Business‑First Thinking : Understand the business problem, its value, and how code delivers that value; then design the architecture accordingly.

Architecture Design Components

The design process is divided into three parts:

Architecture Positioning

Define the high‑level purpose of a system (e.g., "transaction system" handles order flow, "payment system" handles asset settlement). This positioning guides all subsequent design decisions.

Business Architecture

Describe the functional responsibilities of the system, how it interacts with upstream/downstream services, and how to achieve code reuse and risk isolation.

Application Architecture

Translate the business architecture into concrete implementation structures (e.g., onion architecture, module organization, DSL frameworks, extension engines).

Design Patterns and Technical Solutions

The author lists common technical solutions and design patterns that architects should master, including distributed transaction models (TCC, JTA/XA, Saga), idempotency, sharding, high‑concurrency splitting, clustering, multi‑active/hot‑standby, distributed locks, and uniqueness control. Design patterns such as ACL, template method, strategy, workflow, AOP, and classic design patterns are also highlighted.

Conclusion

Architectural competence is not about memorizing frameworks but about continuously upgrading one’s cognition, applying systematic thinking, and aligning technical design with business value. By following the presented methods and habits, engineers can evolve into architects capable of designing sustainable, extensible systems.