12 Essential Skills for Software Architects

The question regarding what an architect's skill set should be is usually met with answers such as: excellent knowledge of software methodologies, non-functional requirements and all around superb technical ability. In '12 Essential skills for software Architects', Dave Hendricksen challenges this view by considering what other skills are required besides technical excellence.

In summary these skills are with dealing with people and business acumen.

Some examples of the people skills:

1. If someone makes a mistake, look for the reasons why they made certain decisions, rather than dismissing them for the mistake. The idea here is that a lesson can be learnt and the same mistake should not be made again.
2. A range of communication tips from being a better listener to dealing with conflict in a professional manner.
3. Leadership tips including being prepared to eat your own "dog food", being transparent in all your work and to combine passion with a persistence so that when challenges manifest you are prepared to endure and show fortitude.
4. Understanding different psychological traits. For example, Hendricksen presents an interesting psychological spectrum where "options people" are on side and "procedures people" are on the other. Options people tend to spend too long thinking instead of doing and procedures people tend to only want to do something the way they know how to do it and by a way that they have used before.

Now, a lot of all this may come across as common sense. But, in the cut and thrust of a challenging technical environment it can easily be forgotten and usually is. This is a recurring theme of the book, a reminder of the things we can easily forget but really should not.

Regarding the business skills, Hendricksen advises that the architect should not just know the problem domain but should understand how business people think and the language they use. He suggests attending trade fairs, increasing your customer interaction and to even consider taking a reputable business course. The reasons for all of this is because it is much easier to make better decisions with people the more you understand other stakeholders' perspectives. Making better decisions means people have more trust in your abilities.

The architect's role is clearly a very multi-faceted one which requires very quick context switching between the various demands. However, I think the advise in this book is applicable to anyone working in a technical organization. Not only because the lines between senior engineers and architects are becoming more of a blur but because the book is a reminder of the challenges every technical organisation faces besides solving difficult technical problems.

It is a super book and one that I will reading (and consulting) again.