What Makes a Great Software Architect? Insights from Meituan’s Logistics Lead

Many people want to become architects, but the industry lacks a consensus definition. What is architecture? How does an architecture become practical? What are the responsibilities and core value of an architect? To answer these, we interviewed Xu Po, architect at Meituan Selection.

My Architecture Experience: Logistics Architecture Balances Process Quality and Result Quality

InfoQ: Please briefly introduce your background and current responsibilities at Meituan.

Xu Po: I have been working for fourteen years, spanning traditional industries and internet software, including communications, games, social, automotive O2O, travel e‑commerce, physical retail e‑commerce, and community group buying. I joined Meituan in 2016, leading supply‑chain product, in‑store product platform, Meituan Selection product, and logistics architecture. I have served as IC, team lead, and architect, and now I am an architect focusing on logistics at Meituan Selection.

InfoQ: How does logistics architecture differ from other architectures you have worked on?

Xu Po: The logistics system is a B‑side system and the logistics domain is highly specialized with many business concepts and high complexity. It combines internet‑scale high concurrency with enterprise‑level complexity.

If we classify the SQALE quality model by process and result quality, process quality includes Maintainability, Changeability, Testability, and Reusability, while result quality includes Reliability, Efficiency, and Security. Traditional architectures focus more on result quality, whereas logistics architecture emphasizes both process and result quality equally.

InfoQ: What key points or trade‑offs should be considered to make an architecture land?

Xu Po: Architecture is both a design and an execution issue. Architects must ensure the architecture lands, which is a major challenge. According to Wang Gai‑kai, architects need the ability to mobilize resources, but this can be achieved through empowerment rather than direct authority. Four essential points are clear direction, detailed solutions, practical methods, and balanced stakeholder interests.

Clear direction means having foresight and articulating a long‑term vision to the team.

Detailed solutions require both high‑level design and attention to key details, offering multiple options and evaluating them comprehensively.

Practical methods mean guidance must be realistic and problem‑oriented.

Balanced stakeholder interests involve respecting all parties involved in the architecture, empathizing, seeking common ground, and reaching consensus.

What Is an Architect? Delivering Business Value by Ensuring System Quality Attributes

InfoQ: The industry lacks a clear definition of an architect, and some HR use the title loosely. What are the duties of an architect and its core value to a company?

Xu Po: An architect defines problems, identifies direction, creates or adjusts architecture, and selects the most suitable approach to help the team solve issues. The quality of an architecture is judged by its ability to support business growth with minimal development cost. As Martin Fowler says, one of the most important tasks of an architect is to eliminate irreversible decisions in design.

The core value of an architect is to improve business support efficiency and reduce development cost by safeguarding system quality attributes. High quality at the architectural level translates to lower cost.

Studies show that low‑quality architectures quickly degrade development efficiency, while high‑quality architectures require far less time for the same incremental functionality.

InfoQ: Architecture work relies on team support. What organizational forms can architecture teams take?

Xu Po: Architecture teams generally fall into three types: consulting‑type, team‑type, and tiered‑type.

Consulting‑type architects act as professional consultants.

Team‑type can be further divided into solid‑line or dotted‑line structures, and into project‑based or BP‑based collaboration.

Tiered‑type combines architecture positions and roles into a ladder, enabling top‑down and bottom‑up feedback loops. For example, some companies classify architects as Enterprise Architect, Solution Architect, and Application Architect.

How to Become an Architect: Be a Bird in a Flock, a Beast in a Herd

InfoQ: How should technologists make career choices?

Xu Po: Technologists should recognize their strengths, understand available roles, and set clear career goals early.

Many view IT as a “youth job” and seek rapid transitions from programmer to architect or manager, often struggling between the two. Regardless of the target, continuous knowledge‑system building and methodical experience accumulation are essential.

InfoQ: What core abilities must an architect have and how can they be cultivated?

Xu Po: The key abilities are macro‑thinking, abstraction, and deep‑dive research. Architects must “stand high, see far, dig deep.” Macro‑thinking involves viewing the whole system before diving into details. Abstraction helps handle inevitable change by creating stable, extensible models. Deep‑dive research enables solving critical technical challenges, which requires a solid engineering foundation.

InfoQ: With rapid tech evolution (AI, low‑code, etc.), should architects master these details? How to build a knowledge system?

Xu Po: Engineers should master core fundamentals while expanding their technical horizon. Architects need to stay aware of industry trends, but not every technology requires deep mastery. Focus on selective, high‑ROI learning.

Domain‑driven design (DDD) is a mainstream business‑architecture theory. Its adoption faces two challenges: high knowledge threshold and lack of localized guidance for domestic business contexts. Successful DDD implementation requires solid foundations in OOA, OOD, and related design principles.

Guest introduction: Xu Po, Meituan Selection architect with fourteen years of experience in software development and architecture, specializing in software architecture, domain‑driven design, micro‑services, and refactoring.