Reviving the Software Architect: Lessons from Interviews and Real‑World Projects

The author revisits an old interview story where Simon, a software‑company manager, questions a junior candidate about becoming a "architect," exposing the candidate's shallow understanding of the role and the common misconception that many developers aspire to be architects without grasping the responsibilities.

Through a series of probing questions, Simon highlights that being an architect involves more than choosing frameworks like Spring or Struts; it requires the ability to justify decisions, persuade others, and understand the deeper impact of architectural choices.

Drawing from personal experience as a web developer, the author describes how direct database access, duplicated login logic, and ad‑hoc integrations between a CMS, an image‑management system, and an attendance system create unhealthy coupling and maintenance burdens.

The piece calls for the revival of the software architect role, likening it to a city planner who must understand every building, market, and hospital, and orchestrate their relationships to achieve a balanced, cohesive system architecture.

Benefits of having a proper architect include more stable programs, reduced duplicated logic and data, lower maintenance effort, and easier development of new systems through shared, well‑designed modules.

To fulfill this role, an architect must be proficient in coding, skilled in system design, possess a global view of the enterprise, and have strong coordination abilities to align multiple projects and stakeholders.