This article discusses six aspects of the professionalism required for a good architect.
As a leader
Good software architects must understand that their role as leaders is not necessarily to tell developers what to do. Instead, good architects act as mentors themselves, managing a development team toward the same technical vision, using leadership skills such as storytelling, influence, conflict steering, and building personal trust to turn their architectural vision into reality.
A good leader, who is also a good architect, will listen carefully to each participant and fine-tune their vision through feedback interaction with the team. Good lead to the next point.
As a developer
Good architectural choices are made by balancing the desired target architecture with the current state of the software system. For example, if a relational database is better suited to the problem domain, it doesn’t make sense to add a document database to the system, even if it’s boring. Architects will be tempted by a variety of technologies to make architectural choices without first considering their suitability for the business problem domain.
The best way for architects to mitigate this is to spend time with developers in the code. Understanding how the system is set up, as well as its constraints, will give the architect more information about the right choices for today’s environment.
Have system focus
Experienced developers know that code is only one aspect of working software. In order for code to work, experienced developers need to understand other important quality attributes for the code to work well in its production environment. They need to consider quality attributes such as deployment process, automated testing, performance, security, and supportability. Developers can code implementation based on these quality attributes, and architects are not only focused on understanding the code, but also need to understand and meet the needs of different stakeholders (such as support, security, and operations personnel).
A good architect needs to focus on finding solutions that meet the needs of these different stakeholders, rather than choosing tools or approaches that are optimized according to the preferences or styles of one participant.
Think like an entrepreneur
All technology options have costs and benefits, and a good architect will consider new technology options from two perspectives. Successful entrepreneurs are willing to take risks, but look for ways to learn fast and fail fast. Architects can approach technology choices in a similar way, seeking real-world information about short – and long-term costs and being aware of their possible benefits.
A good example is when the architect avoids promising to immediately use a new tool that he has read about in a new article or heard about in a conference. Instead, they should try to understand the relevance of the tool and sample the architecture running in their environment to gather more information. They don’t choose a tool based on how well it sells, but on what value it provides and whether it provides what their system needs. They also look for hidden costs of the tools, such as whether the supported tools are good enough (for example, document level, community adoption), and how much additional risk the tools bring about from lock-in or long-term introduction.
Balance your strategy with tactical thinking
Many teams and individual developers tend to build their systems with the tools and techniques they are most comfortable with or most experienced with.
A good architect needs to be aware of what newer technologies are and what tools or approaches might be useful, but not necessarily adopt them immediately. Technology adoption requires an approach that considers the long-term outlook. The architect will seek a good balance between agility (allowing teams to move quickly) and adaptation (keeping enough consistency) at the team and organizational level.
Building your own technical radar is a useful tool in exploring.
Good communication
The architect needs to understand that effective communication is based on trust and needs to influence people outside the team, which are key skills for the architect. They know that different groups of people use different words, and it can be difficult to communicate with business or management people using technical terms. Instead of talking to them using patterns, tools, and programming concepts, architects talk to them using words that are familiar to the audience. Using terms such as risk-reward, cost, and benefit to communicate technology options to business people will be more appropriate than using technical terms with development teams.
Architects also recognize that communication within the team is as important as external communication, using diagrams and group discussions to establish and refine the technical vision, and using journaling, such as wikis, to provide a historical trajectory for the future.
conclusion
Being a comprehensive architect is not easy. There are so many elements to focus on, each leveraging skills that many developers often don’t have. What matters most is not necessarily what the architect has, but that they have enough expertise in these different areas to be effective. Only architects who are proficient in one of these six areas will become architects with a good level of expertise.