One point that a lot of these articles seem to gloss over, even in their discussions of changing software engineering culture, is that UML - used as a formal sp

One point that a lot of these articles seem to gloss over, even in their discussions of changing software engineering culture, is that UML - used as a formal specification cast nearly in stone by a software architect - emerges from a time when the software architect was not very involved in the software implementation, which was done by programmers who received the specification. In this stratified approach, the specification had to be highly formalized and specific, since the architect had little role in the implementation - hence approaches like UML. For many good reasons, including the rise of bottom-up hacker and startup culture, and the need for flexibility/iteration between the design and implementation, we've shifted to a paradigm where the architect is also usually the programmer, especially at the early stages of the software creation process. The architect themselves usually writes the core functionality of the software. This is true even at big modern tech companies. Furthermore, "Software architect" is far less a distinct job description like it used to be, but now refers to the degree of responsibility an individual has for the software's structure and design, which usually correlated with experience and the project scope.