7 Habits of Highly Successful Software Architects

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

7 Habits of Highly Successful Software Architects
According to Malveau and Mowbray, the seven successful habits are:

• Keep it simple.
• Let others defend the architecture.
• Act don’t argue.
• Keep an eye on the prize.
• Be willing to change, but never too much at once.
• Learn where to stop.
• Know how to follow.

Keep It Simple
Avoid complicated explanation.  Keep it high level and grounded in principle.  Malveau and Mowbray write:

When communicating various architectural concepts or softwaremechanisms to team members, resist the temptation to provide a completeand detailed explanation of how things work or a detailed comparisonagainst all the alternatives in front of a group.  Instead, the softwarearchitect should say enough to communicate the idea at a level that ishigh enough to be generalizable but just low enough to be understood inprinciples, so that the individual team members can do their ownhomework or meet separately with the architect to address their specificconcerns.

Let Others Defend the Architecture.
If you’re the only one defending the architecture, there’s a problem.  Malveau and Mowbray write:

It is always preferrable to have someone respond to atechnical concern rather than have the software architect appear to bethe sole source of knowledge.  it reinforces teamwork, provides thearchitect with insights from people who agree as well as disagree, andis a key aspect in mentoring others, among other benefits.

Act Don’t Argue
Rather than argue, focus onresults.  Keep it objective and keep things moving forward.  Lead byexample.  Malveau and Mowbray write:

Arguing technical points in a meeting wastes, time, hurts feelings,and seldom if ever fully resolved any technical issues.  When such anargument starts, the software architect must act - by assigning peopleto get or verify the relevant information, setting up a meetingspecifically for resolving the debated topic, or, if time requires animmediate course of action, laying down the law by explaining why thetime constraints force an end to the matter.

Keep an Eye on the Prize
Have the overall vision in mind.  Malveau and Mowbray write:

Software architects must always be aware of the end goal.  It is easyto be distracted by tasks and smaller technical issues, and frequentlyother team members will succumb to oneform of tunnel vision or theother.  However, it is vital that the architect always be focused on theoverall vision of the system and relate every task or technology to howit contributes to the end goal.

Be Willing to Change, But Never Too Much at Once
Be flexible in your approach, but make incremental changes.  Malveau and Mowbray write: 

After the initial bootstrapping of a software development effort, thearchitect should be wary of implementing too many process improvementsall at once because there is a risk of compromising the effective partsof the process.

Learn Where to Stop
Don’t micromanage the design.  Malveau and Mowbray write the following:

Software architects must resist the temptation to go into too manydetails and to micromanaging design decisions.  For example, it wouldtypically be enough to specify that caching is required in clientapplications and that the caching code should be resused throughout theapplication.  However, detailing the specific caching algoritm used orwriting the caching pseudocode is probably overkill.  Learning to trustother team members to provide design and implementation details andletting them ask for help is essential.

Know How to Follow
Avoid public confrontation.  Malveau and Mowbray write:

No matter who is in charge, software architects shouldavoid publicly confronting others on major design issues.  This can beaccomplished by knowing ahead of time what is going to be discussed andthe reasons for the various decisions.  This is a key aspect todeveloping a focused, high-performance team.

Key Take Aways
Being in the software buildingbusiness, I can easily relate to this. I think there’s a couple ofthemes 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.