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.
