What Makes A Good Software Architect

A good architect must have a global view of the product. Knowing everything inside out by facts certainly helps but it's far from enough. It's more important to make following developers successful and that's not by dumping work on them the way a slave-master dumping work on slaves.

The most desirable quality of a good architect is to solve a puzzle with least pieces. As the product evolves, more and more features are added and the product's complexity grows, sometimes exponentially when the architect makes a bad decision. It's all the responsibility of an architect to reduce complexity rather than introduce more. When a project is late on some new feature and everybody is playing Whac-a-bug, likely the feature has introduced some uncontrollable complexity and the architect is at fault.

A good architect must aim before shoot, taking the time to scout for the right target. Squandering all the ammo on a wrong target is the worst an architect can do.  More often then not, the architect will claim afterwards that it is the right target. Thus another desirable quality of a good architect is to admit mistake and fix the mess. When a team is dragged by the ego of its architect on a death march and coming out "victoriously" by delivering crappy code with wrecked morale, it can often mysteriously strengthen the I-am-right belief of the architect. Without noticing the debt accumulated during the "victory", the architect boldly embarks the ship for another adventure and only finds out the crew is not rowing for him anymore.

A good architect, especially one promoted from a good programmer, must not assume that programmers implementing the architecture also bear the same qualities. Surely a few of them do and they eventually grow into architects themselves but most are just average Joe. Giving average Joe some work grossly greater than what he can take is to set him up for failure. Miracles can happen sometimes but a project relying on miracles goes down fast. Instead, a good architect must be able to slice and dice a hard problem into smaller easy ones so that average Joe can take on the easy problems. Blaming on average Joe's inability to deliver always hides the architect's inability to reduce complexity.