1. 架构师既是技术专家，同时也是业务领域的专家，能够预见业务领域风险，并提供解决的办法。技术上经验丰富的人会有很多，只要在技术的道路上，总是会沉淀各种各样的技术。而对于业务的把握，则是一个缘分。需要有额外的兴趣，额外的时间投入，才能够有机会在相关的业务领域深入下去。
2. 架构师在选择技术的时候，要为客户着想，而不是为自己的简历着想，添上光辉一笔。
3. 选取框架技术的时候，量体裁衣，不要引入复杂性。衡量框架复杂性的指标： 代码中解决业务问题的代码所占的比例。
4. 项目中人才是关键，对于拖后腿的成员，要引入对话。首先，看到这个人的优点，设定一个共同的目标（最好是帮助别人）顺带能够弥补他的缺点，控制好情绪去沟通。（愤怒，沮丧，烦恼，慌张等都不可取）
5. 架构师能够言简意赅地表达自己的命令和技术决策非常重要，这能提高沟通效率，没有人愿意阅读冗长的架构决策文档。简便的白板，图表，加相
6. 架构师是团队的领导，必须要以身作则，获得同伴的尊敬，建立团结的工作环境
7. 架构决定性能，遵循分布式计算，物理学的基本原理来提高性能。架构性能是一个复杂的主题，从需求，到应用实现层，最后到数据库层，都可以做很多工作。不能轻信厂商，简单的更换硬件，或者底层软件架构WLS,JBOSS。
8. 分析客户需求背后的意义，极其更深层次的原因。比如，战斗机的速度需求是2.5马赫(2倍音速)， 但这个需求背后的意义是“迅速撤离战场”，设计团队其实能够提出更好的建议，而不仅仅是2倍音速。所以架构师需要理解用户需求背后的意义，站在同一个层面去思考问题，提出更有效的解决方案,，并且把最有价值的需求摆在第一位。 了解背后的需求通常都不那么容易，因为客户经常认为那是不言而喻的，而技术团队则很难理解。
9. 增加自己的影响力，表现力，让开发人员，或者管理层接受自己的意见。任何时候都要以积极有效的状态去销售观点。比如，起立发言，眼神交流，语速等
10. 承认任何系统都有缺陷，所以要事先设计好防范故障的模型，应对威胁系统安全的意外情况
11. 架构师应该谨慎地站在业务团队的一边，把投资回报率当作项目的目标。
12. 架构师在面对需求时，要有足够的敏锐，让需求得以量化。而不是模棱两可的“要快”，“要可伸缩”，“要灵活”。 面对无法量化，至少要给一个范围
13. 项目开始时候就关注性能的设计，进行相关的性能测试。
14. 架构师要兼顾平衡，不仅创造优质软件，同时兼顾不同Stakeholder的目标。CEO要控制成本，运营要易于管理，开发要代码方便维护。有时紧急任务会打破平衡，让一些不易于维护的代码实现紧急需求，但是长期看，还是要维持一个稳定的平衡。
15. 想尽一切办法，让团队杜绝草率提交代码的行为。避免把有缺陷的代码丢给同事。所以自动化构建，自动化测试框架尤为重要。
16. 很多架构师都非常看重通用性和复用性，并以此作为炫耀的资本，最后造成过度的设计。追求所谓的灵活性，往往会错失一些简单的设计，以及更有价值的特性。 所以原则上，先确保解决方案的简单可用，再考虑通用性和复用性。
17. 架构师是技术团队和业务团队的接口人，能胜任所有的技术，才能代表技术团队发言。同时又要懂得业务，督促技术满足业务的需求。 要展示自己的实践能力，建立威信并赢得大家的尊重，成为大家的榜样。
18. 谨记MF的名言“尽早构建，持续构建”
19. 架构师要有谈判的技巧来应付突如其来的时间缩短，功能增多等要求来改变计划。迅速表明立场，质量为上，如果加快进度，那么就去掉部分不那么重要的功能，但是要确保核心功能的质量。 (取舍的艺术，通过讲故事来谈判，“瓦纳号”: 波兰国王提需求，既运兵又作战，结果起航礼炮结束后就立刻沉没了)
20. 架构师要非常非常重视数据的建模，严格遵守完整性，尽可能使用约束，恰当的Key，同时名称的定义也要不言而喻。
原文链接：
https://zzhonghe.iteye.com/blog/2032491