Architect Should Be a Role, Not a Fixed Position: A Critical Perspective

Yesterday I read an article titled “Architect Should Be a Role, Not a Position” and decided to translate it for Chinese developers because I largely agree with the author’s viewpoints.

The piece observes that when senior developers become even more senior they are often promoted to "architect"; sometimes architects are not developers at all, but they are expected to see the larger blueprint, and large companies may even have an "architect council" where designated architects from each team convene to make strategic decisions.

The author contends that creating a dedicated "architect" position is a bad idea because software architecture is inherently flexible and should not be rigidly defined in advance; development and architectural design are tightly coupled, so letting a single person dictate what to do and what not to do without deep implementation knowledge is unscientific and leads to problems.

The first argument is that without writing detailed code you cannot become an excellent architect; most of the time it is not just "simple coding," and a long‑time architect who no longer writes code is unlikely to be effective.

Even if an organization places an architect in an ivory tower, there are better approaches than isolating the role.

Architecture should be viewed as a role rather than a fixed position; every senior team member should be able to act as an architect, and it is preferable to have multiple people share this responsibility, discussing design in meetings and proving the necessity of any over‑design.

Positions can be "software engineer," while roles can be "agile master," "architect," "continuous integration officer," etc.; a company may still form an architect council to handle macro‑level integration, nominating the most knowledgeable developers.

The author warns that developers must understand higher‑level architectural plans; otherwise they will encounter issues because the code must align with the broader blueprint.

Team dynamics matter: promoting a less‑respected developer to architect can harm harmony, and an overconfident architect may make unilateral decisions without considering dissenting arguments.

The second argument is to eliminate the architect position altogether, ensuring senior members participate in architectural decisions, keeping them motivated and aligned with realistic development contexts, thereby avoiding unnecessary complexity.

Source: http://michael-j.net/