February 2009
Beginner
222 pages
5h 23m
English
Content preview from 97 Things Every Software Architect Should Know
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.
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
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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access
More than 5,000 organizations count on O’Reilly
O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.Julian F.
I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.Addison B.
I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.Amir M.
I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.