1. Many IT architects use simple tools for diagrams. The most common in my industry were PowerPoint and Google Slides. Even for very complex diagrams that can cover an entire wall.
2. Other architects will abuse diagramming standards and other standards. Ask them to describe their diagram instead of assuming what it means. For example, the vast majority of UML use case diagrams I have seen were used to describe flow, which is technically wrong.
3. Consider your role as one of advisor / mentor / coach. The best architecture will not always win due to other constraints, and you need to be able to compromise.
4. Another of your primary roles is that of educator and communicator. Many times people need to quickly understand the systems from a high level in order to make decisions. And they will come to you for that understanding.
5. Along with the above, you will likely be working a lot more with management because you are participating in high level decisions that often involve how money is spent. Learn how management prefers communication. Start with the bottom line: "the preferred solution costs X and we have two other solutions that cost less but come with some cons". And then drill down into details as needed. A junior communicating with management always gives the details and justification up front and that is the opposite of how management thinks.
For your #1 point our team has had great success using PlantUML for our diagrams. They can be easily output for slides or wiki pages, but it's all written in code so we can keep them in our git repo for tracking.
Two of the teams I worked on supported a couple thousand devs each. So going in I thought it would be everyone using specialized diagramming tools. But the majority did not. I don't do much architecture these days, but I've bookmarked PlantUML just in case and will check it out if the need arises.
1. Many IT architects use simple tools for diagrams. The most common in my industry were PowerPoint and Google Slides. Even for very complex diagrams that can cover an entire wall.
2. Other architects will abuse diagramming standards and other standards. Ask them to describe their diagram instead of assuming what it means. For example, the vast majority of UML use case diagrams I have seen were used to describe flow, which is technically wrong.
3. Consider your role as one of advisor / mentor / coach. The best architecture will not always win due to other constraints, and you need to be able to compromise.
4. Another of your primary roles is that of educator and communicator. Many times people need to quickly understand the systems from a high level in order to make decisions. And they will come to you for that understanding.
5. Along with the above, you will likely be working a lot more with management because you are participating in high level decisions that often involve how money is spent. Learn how management prefers communication. Start with the bottom line: "the preferred solution costs X and we have two other solutions that cost less but come with some cons". And then drill down into details as needed. A junior communicating with management always gives the details and justification up front and that is the opposite of how management thinks.
I hope that helps. Best of luck in your new role!