Very nice.<p>I'm a big fan of #1 being "State the problem." rather than "Is this a 'Good Idea'?" they are inter-related of course, but any good software architect has their eyes fixed on the problem so they don't get distracted by the opportunities to 'decorate'.<p>I like asking people what they think the 'architect' does, that is to weed out people who think architect implies a leadership role, it can be but it isn't necessarily. In the 'real' world the architect is the person who notices you've got a banquet room for 100 people but the nearest restroom is two floors down, or a single hallway connecting both the people and the kitchen to the room. They see the 'whole' goal (feed large groups of people) and then work out what has to be true for it to be not a problem.<p>I look for similar skills in software architects, they don't care if the implementation is rails/django/node but they do care that individuals can be identified as users or guests, given capabilities or not, can be disabled or not, and the largest possible number are welcome.<p>Sometimes architecture is combined with the person who does design, sometimes with the person who does coding, and sometimes its just a person asking really good questions at the launch planning meeting.
I'd rather call this a checklist than a cheat sheet. A cheat sheet is a quick lookup for someone who doesn't know what they're doing, whereas a checklist is a quick lookup for someone who does know what they're doing and is humble enough to recognize that even the most capable expert performs better when working off a list.<p>Related: <a href="http://gawande.com/the-checklist-manifesto" rel="nofollow">http://gawande.com/the-checklist-manifesto</a>
As a database guy working in a Rails shop, I have huge qualms with "DRY". It encourages people to encode relationships in their models, and trust that's somehow magically going to keep their data sane. It's not. Believe me, it's not.<p>If you're using an RDBMS, <i>use it</i>. The model is just a representation of the data's canonical, authoritative state, which is what it looks like when it's been committed to the DB. The only way to keep your data sane is with Foreign Keys enforcing referential integrity between tables, and the only way to do that is to specify the relationship in both your models, <i>and</i> in your migrations.<p>Blind, slavish adherence to a pithy acronym is just going to get you into trouble.
One quibble: "DRY?" isn't meaningful to anyone not exposed to that non-ubiquitous acronym. If I stick this sheet outside my cube I'll be explaining it over and over, or (worse) the curious and otherwise open-minded will walk off dissuaded by opacity.
Beginning with such a simplified list proves useful. I would say the first point has to be "Are there 'existing' solutions to this (Architecture) Problem? If yes, what are they & what are their pros & cons?"
It always surprises me (& I learnt from a wise man & my mentor) that you aren't the first one (& almost never alone) when you encounter any problem.
Here's a good taxonomy of software quality attributes, which are strongly related to architecture: <a href="http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm" rel="nofollow">http://www.sei.cmu.edu/library/abstracts/reports/95tr021.cfm</a>
Curious abuse of fonts. The "g" displayed is "!" in other fonts, hindering copying (I'd print it as-is, but the "DRY" acronym is unnecessary & confusing).