97 Things Every Software Architect Should Know

Chapter 6. Seek the Value in Requested Capabilities

Einar Landre is a practicing software professional with 25 years' experience as a developer, architect, manager, consultant, and author/presenter.

Currently for StatoilHydro's Business Application Services, he engages in business-critical application development, architecture reviews, and software process improvement activities, specializing in SOA, domain-driven design, use of multi-agents and design of large-scale, networked, software-intensive systems.

—Einar Landre

OFTEN CUSTOMERS AND END USERS state what they think is a viable solution to a problem as a requirement. The classic story on this was told by Harry Hillaker, the lead designer of the F-16 Falcon. His team was asked to design a Mach 2–2.5 aircraft, which was then, and probably still is, a nontrivial task—especially when the objective is to create a "cheap" lightweight aircraft. Consider that the force required to overcome drag quadruples when doubling the speed, and what impact that has on aircraft weight.

When the design team asked the Air Force why it 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: an agile aircraft with a high thrust-to-weight ratio, providing acceleration and maneuverability, not maximum speed.

This lesson should ...