1.5. Be willing to rethink the architecture when it turns out problematic. I have seen systems that probably looked good as a diagram before a line of code was written, but had to work around their own architecture with gross hacks.
Architecture is important, but organizations employing "software architects" tend to be bad at software.
The second part may read as a non-sequitur. The connection is that in organizations that have separate architect roles, architects are shielded from their mistakes because they don't work on implementation, and their work usually isn't questioned.
The worst thing I remember is a web API where some call could fail but didn't tell you, it just gave you some kind of plausible looking inert data. The call to query system status was separate, so there was always a time of check / time of use problem. Also there was a transition period when the original call did return an error but the system status API didn't yet. Nobody (I hope) comes up with such a disaster while implementing and testing it.
Architecture is important, but organizations employing "software architects" tend to be bad at software.