I think you are missing some key aspects of the architect role in that you don't mention requirements (apart from hardware requirements which are always funny c

I think you are missing some key aspects of the architect role in that you don't mention requirements (apart from hardware requirements which are always funny coming from a developer...) and you only point the communication towards peers but not clients and business partners. The architecture process can be summed up along these lines: - Identify stakeholders, their concerns and objective. Translate these into goals and requirements; - Understanding, validating and designing the requirements; - Identifying possible solutions but also constraints, risks and assumptions. Document and validate them; - Document decisions and solutions with blueprints and design documents (diagrams, tables, natural text, etc) that are actionable and can be used as reference material; - Limit the scope of the development activity to the requirements in order of relevance (to the sprint, or other time-bound metric); Behalve dat, goed geddan jonge! (edited for clarity)