Book review: '12 Essentials Skills for Software Architects', Dave Hendricksen.
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:
- 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.
- A range of communication tips from being a better listener to dealing with conflict in a professional manner.
- 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.
- 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.
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.
Sound advice, even for somebody technical like me but not necessarily a software architect. I really appreciate the part regarding options people vs. procedure people. At times I find myself actually caught between the two wondering should I follow process or do something different and if so, am I just reinventing the wheel / is the cost - benefit making sense etc...
ReplyDelete