Why Traditional Software Architects Fail and How Everyone Can Be an Architect

I was a self‑proclaimed troublemaker at Alibaba, constantly criticizing the middle platform, architects, and technical managers, including myself.

Critiquing the Architect

Martin Fowler, in his IEEE paper “Who Needs an Architect?”, argues that architects who only make decisions become bottlenecks; the more agile a team, the less valuable a decision‑only architect.

Fowler even suggests calling them “guides” rather than architects, emphasizing mentorship over authority.

Personal experience at eBay

At eBay’s payment division, a single architect had to approve every design, causing delays and becoming a bottleneck.

The architect was outside the execution team, lacked detailed knowledge, and his proposals were often unconvincing.

Problems with a dedicated architecture department

In Alibaba’s B2B unit, an architecture group was created. When its purpose was merely to produce diagrams for presentations, it felt harmless, but when the group tried to “do work” it became dangerous, amplifying problems.

The group attempted business, application, and technical architecture, but each effort clashed with product managers, operations, and developers, leading to friction and failure.

Generally, establishing a separate architecture department should be handled with great caution; in mature technical systems it is often unnecessary and can hinder progress.

Everyone is an architect

Instead of relying on a single architect or department, every engineer should develop architectural thinking.

According to the IEEE definition, architecture consists of components, relationships, and guidelines (see image).

Thus, architecture capability is a methodology for analyzing and solving problems, and every engineer should cultivate it.

How to grow architectural capability

(1) As a frontline engineer – continuous learning and long‑term practice are required.

(2) As a team leader (TL) – you must understand both business and application architecture to identify core issues and guide the team.

(3) As a CTO – you must master business and technical architecture and design organizational structures that align production relationships with productivity.

In many internet companies without a CTO, each business unit builds its own stack, leading to duplicated effort; a CTO can enforce reuse of common solutions such as big‑data processing or middleware.