I don't believe in architecture being done fully via a separate role, it's counterproductive.
What you need instead is developers on the team who also understand software architecture, and implement it especially in it's initial phases.
This takes more senior developers, then later on less experienced developers can jump in once the structure is in place.
But a completely separate person external to the development team, which is going to define the architecture using text and diagrams only?
That doesn't exist, it's a myth. What ends up happening in practice is that some senior developer on the team ends up implementing the actual architecture, and those documents are used just as broad guidelines at most.
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.
What you need instead is developers on the team who also understand software architecture, and implement it especially in it's initial phases.
This takes more senior developers, then later on less experienced developers can jump in once the structure is in place.
But a completely separate person external to the development team, which is going to define the architecture using text and diagrams only?
That doesn't exist, it's a myth. What ends up happening in practice is that some senior developer on the team ends up implementing the actual architecture, and those documents are used just as broad guidelines at most.