Which "software architecture certifications" did you get and which do you think were the most useful?
To me, an architect is also a good programmer that is able to get work done - learn good coding practices (DRY comes up a lot), be up to date on your stack (latest language features). Practice Clean Code (e.g. some of what Bob Martin writes about, some of it is a bit...special).
Learn about pipelines, version control schemes, and the "best" way to implement it given your constraints. Specifically, how code gets merged, when it gets built, in what environment. I can answer questions about details here. Edit: You will also need to know how to organize your board in Jira, Rally, Azure DevOps, or whatever, especially if you don't have a Scrum master.
Understand how to decouple code into micro-services (and why it's mostly unnecessary to do so). Have a solid understanding of testing principles, and what you want your TDD to look like (if at all) - mocks of everything or small units of functionality.
Understand database performance, modern authentication (JWT, OAuth2, intercepting requests).
This was all specific to Line of Business web apps btw..so may not relate to you.
When I play "architect", I also need to draw diagrams and clearly split up work, so you need to learn to do that. I found it super helpful to have a high-level vision (as pretentious as that word is) for the software. Usually, no one has that.
I have also found that a lot of architects irl are just career bsers, so I might be going about it the wrong way, and I don't have the title.
80% of the architects I know just say random stuff that makes no sense like "Everything will go through an API", "Use attributes everywhere", "everything will be a microservice" and tell you to implement their high level goals, but could never do it themselves. I have zero respect for them.
Since I am just ranting - some of the best advice I have heard (from the Python docs, though I don't use Python). Have one, and ideally only one, way of doing certain things. Clarity is king.
To me, being an architect (not by title, but while leading fairly large teams) always meant being an example (at least in terms of code quality) and always being able to pick up a story from another dev if I dictated something - e.g. not asking devs to do what I am not willing to. This, combined with the vision of the whole product, often means refactoring and helping resolve merge conflicts for others - whether it's in code, Entity Framework migrations, etc.
To me, an architect is also a good programmer that is able to get work done - learn good coding practices (DRY comes up a lot), be up to date on your stack (latest language features). Practice Clean Code (e.g. some of what Bob Martin writes about, some of it is a bit...special).
Learn about pipelines, version control schemes, and the "best" way to implement it given your constraints. Specifically, how code gets merged, when it gets built, in what environment. I can answer questions about details here. Edit: You will also need to know how to organize your board in Jira, Rally, Azure DevOps, or whatever, especially if you don't have a Scrum master.
Understand how to decouple code into micro-services (and why it's mostly unnecessary to do so). Have a solid understanding of testing principles, and what you want your TDD to look like (if at all) - mocks of everything or small units of functionality.
Understand database performance, modern authentication (JWT, OAuth2, intercepting requests).
This was all specific to Line of Business web apps btw..so may not relate to you.
When I play "architect", I also need to draw diagrams and clearly split up work, so you need to learn to do that. I found it super helpful to have a high-level vision (as pretentious as that word is) for the software. Usually, no one has that.
I have also found that a lot of architects irl are just career bsers, so I might be going about it the wrong way, and I don't have the title.
80% of the architects I know just say random stuff that makes no sense like "Everything will go through an API", "Use attributes everywhere", "everything will be a microservice" and tell you to implement their high level goals, but could never do it themselves. I have zero respect for them.
Since I am just ranting - some of the best advice I have heard (from the Python docs, though I don't use Python). Have one, and ideally only one, way of doing certain things. Clarity is king.
To me, being an architect (not by title, but while leading fairly large teams) always meant being an example (at least in terms of code quality) and always being able to pick up a story from another dev if I dictated something - e.g. not asking devs to do what I am not willing to. This, combined with the vision of the whole product, often means refactoring and helping resolve merge conflicts for others - whether it's in code, Entity Framework migrations, etc.