Category: Software Architect

97 Things Every Software Architect Should Know – 7/97

As architects, many of us have grown from highly technical positions where our success was derived mainly from our ability to talk to machines. However, in the role of architect much of our communication is now done with our fellow human beings. Whether it’s talking to developers about the benefits of employing a specific pattern, or explaining to management the cost-benefit tradeoffs of buying middleware, communication is core to our success.

Although it’s difficult to measure an architect’s impact on a project, if developers consistently ignore their guidance and management doesn’t buy-in to their recommendations, the “rightness” of their guidance will do little to advance their career. Experienced architects understand that they need to “sell” their ideas and need to communicate effectively in order to do that.

Many books have been written on the topic of inter-personal communication, but I wanted to call out one simple, practical, easy-to-employ tip that will drastically increase the effectiveness of your communication, and, consequently, your success as an architect. If you‘re in any situation where you‘re talking to more than one person about your guidance, stand up. Whether it‘s a formal design review, or an informal discussion over some diagrams, it doesn‘t matter. Stand up, especially if everyone else is sitting down.

Standing up automatically communicates authority and self-confidence. You command the room. People will interrupt you less. All that is going to make a big difference to whether or not your recommendations will be adopted.

You‘ll also notice that once you stand, you‘ll start making more use of your hands and other body language. When speaking to groups of 10 or more people, standing up will also help you can make eye contact with everybody. Eye contact, body language, and other visual elements account for a large portion of communication. Standing up also tends to change your tone of voice, volume, pitch, and speed: projecting your voice to larger rooms; slowing down to make more important points. These vocal elements contribute substantially to the effectiveness of communication.

The easiest way to more than double your effectiveness when communicating ideas is quite simply to stand up.

97 Things Every Software Architect Should Know – 6/97

Often customers and end-users state what they think is a viable solution to a problem as a requirement. The classical story on this was told by Harry Hillaker, the lead designer of the F-16 Falcon. His team was requested to design a Mach 2 – 2.5 aircraft, which was then, and probably still is, a non-trivial task – especially when the objective is to create “cheap” lightweight aircraft. Remember that the force required to overcome drag quadruples when doubling the speed, and what impact that have on aircraft weight.

When the design team asked the air force why they needed Mach 2 – 2.5, the answer was to be able to escape from combat. With the real need on the table the design team was able to address the root problem and provide a working solution. Their solution was an agile aircraft with a high thrust-to-weight ratio, providing acceleration and maneuverability, not maximum speed.

This lesson should be brought into software development as well. By asking for the value to be provided by a requested feature or requirement architects are able address the real problem, and hopefully provide a better and cheaper solution compared to addressing the solution suggested by the client. The focus on value also simplifies prioritization. The most valuable requirements become the driving requirements.

So, how to proceed then? In many ways the required approach is found in the agile manifesto: “Collaboration over contract”. Practically speaking this implies arranging workshops and meetings where the architects focus are on customer needs, helping the customers to answer the “why” question. Be aware that answering the “why” question can be difficult because we very often talk about tacit knowledge. Discussions on how to provide a technical solution should be avoided in these workshops, because they move the discussions away from the customer‘s domain and into the domain of software development.