For larger or more complex systems, focusing on a subsystem software architecture from a purely technical execution point of view is myopic, since the overall a

For larger or more complex systems, focusing on a subsystem software architecture from a purely technical execution point of view is myopic, since the overall architecture is much more than a subsystem architecture. Even if a senior developer ends up "implementing the actual architecture", if that does not mesh with the other subsystems and the other stakeholders, their conflicting requirements, and their weighting of the architectural quality attributes, and so on, the end result misses the goal. Details become more concrete the more closer one gets to the developer. Conversely, if one goes the other way, things become more abstract. You need people for the topmost abstraction level, people in the middle levels who understand both the abstract and the concrete, as well as the people at the lowest abstraction level where the implementation happens. Of course, sometimes the systems are small enough or well-defined enough so that the person in the middle level can be the same as the highest-level keeper of abstractions. I don't think having a separate role of an architect is always counter-productive. The architect as a separate role can be useful: that person listens to other people and teams and filters and translates their desires into something which can be defined unambiguously to be actually implemented. If the architect has time to code too, that's great. If not, then there must be those senior developers who can create the more technical parts and write code, too.