Seven Habits of Highly Successful Software Architects

Interesting quote:

The ideal architect should be a person of letters, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. —From Vitruvius, circa 25 BC

From Software Architect Bootcamp, Second Edition by Raphael Malveau, Thomas J. Mowbray, - Ph.D.:

Keep it simple. When communicating various architectural concepts or software mechanisms to team members, resist the temptation to provide a complete and detailed explanation of how things work or a detailed comparison against all the alternatives in front of a group. Instead, the software architect should say enough to communicate the idea at a level that is high enough to be generalizable but just low enough to be understood in principle, so that the individual team members can do their own homework or meet separately with the architect to address their specific concerns.

Let others defend the architecture. It is always preferable to have someone else respond to a technical concern rather than have the software architect appear to be the sole source of knowledge. It reinforces teamwork, provides the architect with insights from people who agree as well as disagree, and is a key aspect in mentoring others, among other benefits.

Act, don't argue. Arguing technical points in a meeting wastes time, hurts feelings, and seldom if ever fully resolves any technical issues. When such an argument starts, the software architect must act—by assigning people to get or verify the relevant information, setting up a meeting specifically for resolving the debated topic, or, if time requires an immediate course of action, laying down the law by explaining why the time constraints force an end to the matter.

Keep an eye on the prize. Software architects must always be aware of the end goal. It is easy to be distracted by tasks and smaller technical issues, and frequently other team members will succumb to one form of tunnel vision or the other. However, it is vital that the architect always be focused on the overall vision of the system and relate every task or technology to how it contributes to the end goal.

Be willing to change, but never too much at once. After the initial bootstrapping of a software development effort, the architect should be wary of implementing too many process improvements all at once because there is a risk of compromising the effective parts of the process.

Learn where to stop. Software architects must resist the temptation to go into too many details and to micromanage design decisions. For example, it would typically be enough to specify that caching is required in client applications and that the caching code should be reused throughout the application. However, detailing the specific caching algorithm used or writing the caching pseudocode is probably overkill. Learning to trust other team members to provide design and implementation details and letting them ask for help is essential.

Know how to follow. No matter who is in charge, software architects should avoid publicly confronting others on major design issues. This can be accomplished by knowing ahead of time what is going to be discussed and the reasons for the various decisions. This is a key aspect to developing a focused, high-performance team.