Architecture decisions are influenced by 3 main parts - People, Business and Tech.
People:
team composition - cross-functional, siloed, etc.
competency levels - how competent people are in all levels and departments
ease of communication - timezone/cultural differences
personal ambitions and beliefs of stakeholders
Business:
stage of business or level of maturity - startup, established product, etc
riskiness - can business take risks and embrace changes
revenue
future plans
business domain - how coupled is the business domain
Tech:
tech stack
infrastructure
policies, patterns, standards
The easiest part is always Tech, the hardest - People. Most of aspects impact each other. Architect needs to understand all of them to properly navigate the politics and propose the best possible solution in the given context.
Sometimes, people lean towards “beautiful” and “industry standard” solutions because they’re the first thing that comes to mind. No matter how high-level your solution is, always be prepared to defend it with an example of a concrete problem it is solving and examples where it will or will not work.
People tend to discuss problems that they understand and know how to fix. There is a term for that - bikeshedding, be sure that you are solving the most root problem you can solve, this way you'll have the most significant impact (assuming that you want to have a big impact).
Retrospection is key to the self-development of both the organization and the individual. Sometimes solutions suck - admit it, fix it and move on. This is the way.
Some inexperienced Architects tend to believe what they've heard at conferences, like "microservices are the best architecture" or "Kafka is the best way for communication between services". Context is the key - do not compare approaches until you know the context.
Horizontal, vertical service scalability, development scalability - everything brings overhead in different forms. Do not rush to implement it in advance, but be conscious of what is happening on the high level to understand when overhead will be outweighed by the scalability advantage.
Third-party solutions create constraints on the business and tech, and when they are also paid, product requirements usually start bending around this solution to avoid admitting the thrown-away money (this usually happens when #2 is not working). Paid tools have much less chance of encountering a blocker or a constraint.
Teams that lack enough competencies tend to screw up the solution. An Architect can’t (and should not) always control the implementation of the solution. With such teams you need to tend to less innovative and riskier options.
Cross-cultural and multi-timezone teams can potentially work on easy projects, but they are generally much less efficient than single-culture and single-timezone teams.
Try to establish personal communications with those who have power to influence decisions, it is not always directly stakeholders, sometimes it can be someone whose opinion is respected by stakeholders. Rely on the processes for places where you don't need influence.
Being transparent and honest with everyone, especially with yourself, can help you remain true to yourself and gain the respect of colleagues.
Depending on the situation, you’ll have to use dictatorship or false democracy to make the decision. Be prepared to be unpopular.
Architects work with problems of very high complexity and cannot always share them with friends and loved ones. Having a team of architects and the time to share your concerns is super helpful. If you don’t have such a team, join the community.
Most of the advice here requires a very high level of soft skills. Invest in them, in your communications skills, and in your emotional intellect.
Architects usually do not create anything directly which can lead to a lack of dopamine. Get a hobby to fix that.
The most creative and important decisions come to mind when bored. Do not beat yourself up when you don’t have immediate work; use it to come up with some, at first glance, useless ideas.
People tend to bikeshed - discussing and solving the easiest-to-understand problems and fixing them, which are usually the least important. Always challenge the "rootness" of the problem you are solving.
AI is a good companion with which you can validate your ideas and also a tool for particular tasks when working with text (documentation, summarization, etc.). Use it more often to reduce the routine.