If you assume these are only needed in the first weeks of a project then it sounds like the classic waterfall fallacy. Preserving architectural consistency and evolving tech choices and adapting dev processes is a continuous process as a project grows and its easy to generate waste by front-loading too much of this.
My feedback on the list is that some of these qualities like handling risk, reuse, company/customer knowledge etc. should be expected of all senior devs. Other items like decision making, design diagrams, identifying standards etc. should be treated as tasks just like design, development and testing. They will regularly arise during a project and can be delegated across the team.
I would consolidate governance in the lead dev role - they are where the buck stops for all decisions, quality, consistency, delivery etc. but they do this by leading a team and delegating unlike an architect role that ring-fences categories of task for themselves.
Good points. We usually prefer to keep the lead developer responsible for all the project's architecture needs. This is more of a role in case the lead is not able to --from early on-- oversee the technical complexity of the project.
My feedback on the list is that some of these qualities like handling risk, reuse, company/customer knowledge etc. should be expected of all senior devs. Other items like decision making, design diagrams, identifying standards etc. should be treated as tasks just like design, development and testing. They will regularly arise during a project and can be delegated across the team.
I would consolidate governance in the lead dev role - they are where the buck stops for all decisions, quality, consistency, delivery etc. but they do this by leading a team and delegating unlike an architect role that ring-fences categories of task for themselves.
Hope that helps!