Once upon a time, every project began with the creation of a canonical design document. This was called the system architecture, because it "rightly...

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

The post outlines the evolution of software design methodologies from traditional, design-first approaches to Agile and Extreme Programming (XP) methodologies. It emphasizes the shift from exhaustive, initial design documents to iterative and flexible development processes. While XP's early focus on system metaphors was later abandoned, the Agile Manifesto's preference for responding to change over following a plan remains central to modern software design. The post critiques the current state of software design, highlighting a need to reclaim more explainable and systematic design practices.

the death of the architect

While I agree in principle, in enterprise software and especially when dealing with legacy code you do need a design/architecture plan in order to communicate the new state of affairs and draw a roadmap. This doesn’t mean that things have to be built 100% like in the design documents, but it serves as a guide and helps facilitate conversations about non function requirements, data flows, dependencies, etc.

The book <code>Domain-driven design</code> addressed this issue a million years ago.
The design didn’t die.
We just need to design in another way. Lightweight, iterative, and concise communication.

Working on a software company where we have many different clients a products. In a company like ours I see the role of the architect as the one who initiates the fire. He puts all the initial pieces in place with a basic understanding of the clients need. His role is really more as an internal consultant and is the go-to person to discuss any fundamental changes to the system architecture.