Seven Habits of Highly Successful Software Architects

Do you practice the habits of highly successful software architects? Can you deliver a solution while acting as a technical mentor, empowering others, improving the process, and developing a focused, high-performance team along the way? In Software Architect Bootcamp, Raphael Malveau and Thomas J. Mowbray, Ph.D. write about the habits of successful software architects.

The 7 Habits of Highly Successful Software Architects
Malveau and Mowbray write the following:

1. Keep it simple. When communicating various architetural 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 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.


2. Let others defend the architecture. It is always peferable 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.


3. 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.


4. 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.


5. 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.


6. 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.


7. 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.

Key Take Aways
Being in the software building business, I can easily relate to this. I think there's a couple of themes that underly the habits:

• Balance connection-focus with task-focus. Building software is a team sport. It often means building rapport and getting others to buy into ideas over time. While knowing your stuff is a good thing, you should use it to lift others up and produce a great results. Winning technical battles at the expense of the human relations war, will cause unecessary friction and reduce your results and drain your energy.
• Focus on value delivered over the shiny object. If you're passionate about the technology, it's easy to fall into the trap of focusing on the technology or the shiny objects. At the end of the day, your credibility and perception will be about the solution you deliver and the team impact.
• Be a mentor and a coach. It's true that knowledge is power. The trick is to grow yourself, by growing others. What you share comes back to you tenfold.