第十三章 -- 联合架构设计和架构审查委员会
联合架构设计 --- 我们在需求设计过程中， 会拉齐server所有人员一起参与， 大家整体取长补短， 需求owner实现做好的设计方案。
架构审查委员会 -- 通过预设计的方式， 前瞻性的对未来的需求进行架构底层的设计和架构原则的实现， 把控业务的底层架构发展。
联合架构设计确实非常好用， 以当前端外pb的通用化设计为例
当『端外pb与端内pb』打齐的联合架构设计的评审结束后， 对于后续贴吧服务端的架构演进和架构原则， 我们产生了很好的共鸣。能够基于这套3.0架构的架构原则， 产出 『能够帮助3.0架构推广和架构统一的一系列工具类』规划。并且能够基于未来可能遇到的一些问题， 做好前瞻性的技术储备。
当架构原则被确定后， 整个的架构视野会相应被打开， 整体的架构演进就会变的更顺畅。
但是整个的这些信息 其实是由JAD会议产出的， 我们对于ARB产出的架构原则， 更多还是隐藏在某一个或几个的设计中， 需要自行感悟。
第十四章 敏捷架构设计
敏捷组织大概通常由5-12人组成， 需要拥有设计、开发、交付、运维等等各项技能， 团队拥有更大的自主权和更少的情感型冲突， 具备更大的权利。
敏捷组织无法保证能够跟进团队的架构标准、开发标准， 这就需要小组的的组长参与TC， 把控并落地团队的架构标准与开发标准， 敏捷团队需要更积极的与外部团队交互， 尽快的将新的『奏效的知识』传播出去。
敏捷团队似乎不需要统一的架构设计， 可以实行自制, 以效率为先。
ARB（TC组织）需要和敏捷团队有每日例会或者定期的沟通， 来确保架构设计不走样。
第十五章 聚焦核心竞争力
自建与外购使用中台还是自行开发？
综合考虑成本与策略以群聊项目为例， 我们最终考虑了中台的外购方案， 而没有使用能力的自建， 就是从各方成本以及最终目标来决策的。