Software teams that are smaller and/or agile tend to be staffed with people that are generalised specialists; people that have a core specialism along with more general knowledge and experience. In an ideal world, these cross-discipline team members would work together to run and deliver a software project, undertaking everything from requirements capture and architecture through to coding and deployment. Although many software teams strive to be self-organising, in the real world they tend to be larger, more chaotic and staffed only with specialists. These teams, therefore, tend to need and have somebody in a technical leadership role.
There are a lot of people out there calling themselves "solution architects" or "technical architects" (particularly in larger organisations) who define a software architecture and then throw their solutions over the wall to a separate design and development team. What's worse is that often nobody takes ownership of the architecture, and the original architect takes only a cursory glimpse at the progress from time to time.
I've met a number of such architects in the past and one particular interview epitomises this approach to software development. After the usual "tell me about your role and recent projects" conversation, it became clear to me that this particular architect (who worked for one of the large "blue chip" consulting firms) would create and document a software architecture for a project before moving on to the next to repeat the process. After telling me that he had little or no involvement in the project after he handed over the "solution", I asked him how he knew that his software architecture would work. Puzzled by this question, he eventually made the statement that this was "an implementation detail". Essentially, his view was that his software architecture was correct and it was the development team's problem if they couldn't get it to work for any reason. Outrageous!
For me, the the role of a software architect is that of a generalising specialist and different to your typical software developer. It's about steering the ship, which at the start of a software project includes things like managing the non-functional requirements and putting together a high-level design that is sensitive to the context and environmental factors. But it's also about continuously steering the ship because your chosen path might need some adjustment en-route.
A successful software project requires the initial vision to be understood, communicated and potentially evolved throughout the entirety of the software development lifecycle. For this reason alone, it doesn't make sense for one person to create that vision and for another team to (try to) deliver it. When this does happen, the software architecture document is essentially a baton that gets passed between the architect and the development team. This is ineffective, doesn't work in most cases and the exchange of a document means that a lot of the decision making context associated with creating the vision is also lost.
This problem goes away with truly self-organising teams, but most teams haven't yet reached this level of maturity. Therefore, somebody needs to take ownership of the bigger picture throughout the project and they also need to take responsibility for ensuring that it's delivered successfully. If somebody has defined an architecture, why shouldn't they own and take responsibility for it throughout the rest of the project? Software development is not a relay sport and successful delivery is not an implementation detail.