摘录自《架构及未来》中的一小部分内容。
理想情况下，架构原则将基于高层次的目标决策，架构原则应该和公司的发展愿景和使命相符。
目标可能会随着时间的推移而改变，因为原则应该广泛支持未来和当前的目标。原则应该极可能体现 SMART 特性，不过原则一般不受时间限制，SMART 中的 T 缩写是 Test，原则应该可以用来测试设计，验证它是否符合要求。
- Specified: 具体的，原则不应该被混淆在它的措辞中。
- Measurable: 可度量的，原则不应包含“无限”这样的词汇。
- Attainable: 可达到的，原则应该是鼓舞人心的，但能够被设计和现实。
- Realizable: 现实的，团队应该有能力达成目标。
- Testable: 可测试的，原则应该可以用来测试设计。
另外架构原则需要得到团队的任何，应该考虑与团队一起来制定。原则的数量要控制好，确保容易记忆并增加利用率，建议不超过 15 个。
15 个架构原则
源自于 AKF 官方网站。
- N+1 设计。永远不少于两个，通常为 三个。
- 回滚设计。确保系统能回滚到之前发布的任何版本。
- 禁用设计。能够关闭任何发布的功能。
- 监控设计。在设计阶段必须考虑监控，而不是实施后补充。
- 多活数据中心。不要被一个数据中心限制住。
- 使用成熟技术。只用确实好用的技术。
- 异步设计。只有在绝对必要时进行同步调用。
- 无状态设计。只有业务确实需要时才使用状态。
- 水平扩展而非垂直升级。永远不要依赖更大更快的系统。
- 至少有两个步骤的前瞻性。在扩展性问题发生前考虑好下一步行动计划。
- 非核心则购买。如果不是你擅长的，也提供不了差异化竞争优势则直接购买。
- 使用商品化硬件。在大多数情况下，便宜的最好。
- 小构建，小发布，快试错。全部研发要小构建，不断迭代，快速成长。
- 隔离故障。通过断路避免故障传播和交叉影响。
- 自动化。如果机器可以做，就不要依赖于人。
更多细节可以查看这里。
责任矩阵
最后，团队在制定和修改原则过程中应该遵循 RASCI 责任矩阵。
- R - Responsible - 谁来执行这个任务？
- A - Accountable (also Approver) - 谁来审批或者说谁对最终结果负责？
- S - Support - 谁在这个任务中提供支持？
- C - Consulted - 谁可以提供有价值的建议或者帮助？
- I - Informed - 谁应该被通知到任务的进度和结果？
JAD & ARB
Joint Architecture Design 联合架构设计和 Architecture Review Board 架构审查委员会是积极推动架构设计的两个过程。JAD 是一个协同设计的过程，所有工程人员共同设计和开发一些符合架构原则的新功能。ARB 负责选择和决定每一个新功能或者业务领域的架构，在架构设计得到最终签署之前，要由该委员会确定其符合公司所有的架构原则和业界的最佳实践。
JAD 团队中应该包括一名未来负责开发的软件工程师，一位架构师，至少一位运维工程师，产品经理和质量保证工程师，每个人都会给团队带来独特的知识、观点、经验和目标，和团队里其他人可以互补。
ARB 的组成最重要的考虑因素是个人特质。首先，必须是组织里受到尊敬的人，他们的地位、任期或者在特定领域的技术业务知识受到人们的尊重。特定位置的人参与，可以确保 ARB 的决定受到广泛尊重。ARB 需要合适的人做出正确的决定，并赋予最终决定的权力。ARB 需要高管的参与，ARB 的参与者要展示自己的专长。
ARB 的活动应当被视为每个成员的额外工作。因为 ARB 的工作是自愿的，你可以修改永久或者临时会员的身份。
所有的 ARB 应该探讨 ARB 的目的，ARB 审查应只授予那些有充分准备的项目。