O'Reilly logo

97 Things Every Software Architect Should Know by Richard Monson-Haefel

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 52. Record Your Rationale

Timothy High is a software architect with more than 15 years' experience with web, multitiered client-server, and application-integration technologies. He is currently working as a software architect for Sakonnet Technologies, a leader in Energy Trading and Risk Management (ETRM) software.

Timothy High
image with no caption

THERE IS MUCH DEBATE in the software development community about the value of documentation, especially with regard to the design of the software itself. The disagreements generally cluster around the perceived value of doing a "big upfront design," and the difficulties of maintaining design documentation synchronized with an ever-changing code base.

One type of documentation that ages well, doesn't require much effort, and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture. As explained in Mark Richards's axiom "Architectural Tradeoffs," the definition of a software architecture is all about choosing the right tradeoffs between various quality attributes, cost, time, and other factors. It should be made clear to you, your managers, developers, and other software stakeholders why one solution was chosen over another and what tradeoffs this entailed. (Did you sacrifice horizontal scalability in the name of reducing hardware and licensing costs? Was security such a concern that it was acceptable ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required