Being a software architect, among many other things, means being able to properly handle communicational challenges. Software architect mainly deals with business people and software development team, which I will cover later in this topic. Before that, I wanted to talk in short about communication-related points that are not part of the daily responsibilities of an architect.
Software architect, first of all, is a person. If you hire an architect, you will need to deal with him or her on personal basis. Therefore, it's very important that an architect is a nice, communicative person. I'm not saying that an architect should be soft and friendly to everybody. Architect must be willing to talk a lot about things that he/she is promoting and advocating. Not everybody likes to talk, so not everybody will fit into architect's picture described here.
On daily basis, architect's main responsibility becomes to understand expectations set by the business side; in parallel, architect must be creating a technological translation of the business requirements. In this extent, architect is a vocabulary of business' expectations, explaining them in technical words. Consumers of this vocabulary are software developers, who are kept responsible for implementing the product as expected.
Another challenge of this responsibility is an ability to switch back and forth between business and development sides. If something pops up on development side, business must be informed and corresponding high-level discussions must take place. Similarly, if requirements change (and they do), the development team must be kept in sync.
There are many ways to keep the two sides in sync, but one of the most effective ways I've seen is to have diagrams and sketches for both sides, that translate between each-other. Modern modeling tools for diagramming support defining object types, relationships between them, flows, and use cases. It is a good idea to create diagrams for both sides of the communication from the same base of object types, thus keeping them in sync should be simpler. However, I know that business people prefer looking at presentations, in which case there is no shared metadata between the two kinds of diagrams and presentations (unless you decide to auto-generate presentations and diagrams from the same metadata). Just don't overdo it. Remember that sketches are good enough to cover high-level topics; and keeping several diagrams and presentations up to the same version is not a big deal.
While we swam into the ways of dealing with business people, one more thing that works well besides presentations is a speech. Sometimes it's worth gathering several business-side representatives to explain them your way of seeing things, and to collect their feedback afterwards. Business people are not technical - sometimes they can consider different approaches than what they had envisioned initially. Architect's competency plays crucial role in the corrective and preventive changes that business stakeholders need to go through.
And the final part of this game is the communication with the development team. Here things seem to be simpler, but that's not entirely so. Many developers will nod heads to express agreement and 100% understanding of the architect's vision, but things go wrong in a matter of development days, if not hours.
Having said that, architect's goal should be to set processes, roadmaps, standards, and rules for the coming development endeavor. We need to stay adaptive and thus we can't plan everything in advance, but this does not mean that we should not try to keep things in the best shape from the very beginning.
Define development processes: decide how software architecting fits into software development for the given organization, given product, and given development team. Decide how to adapt to the requirement changes in timely manner so that newly created architectural diagrams and artifacts get promoted and delivered to the team members. Schedule knowledge share sessions to discuss and promote selected architectural approaches. Make decisions about organizing the code quality-related sessions, such as code reviews, architectural reviews, analysis of technical debt, and refactoring needs.
Define product roadmap: declare what is the product increment that needs to be delivered, and what it takes to get from here to there. Choose technologies and platforms. Brainstorm possible deviations and how to deal with them in architecturally proper way.
Define coding and architectural standards: decide what is considered wrong and what's right. If there is no standard, there is no clear border between the two.
Define rules: this might include defining human roles in the team - who is who; who is responsible for what. What is considered wrong from the team's point of view. Is this a team environment at all? - then decide to have team-oriented disciplines such as cross-code reviews, knowledge share sessions for the team, training and competency improvements upon need.
Be on top of tools and skills: I would recommend looking into UML, design patterns, training (did you know that I provide group-based training courses in software architecture?), staying on top of upcoming and trending technologies, and so on.
The author of the above content is Tengiz Tutisani.
If you agree with the provided thoughts and want to learn more, here are a couple of suggestions: