架构设计和评审

在业务、系统和组织不断扩展下，很多企业会选择对架构进行治理，也很容易想到需要成立技术委员会或者架构委员会，但实际上这类委员会如何去运作，一直以来并没有考虑的特别清楚，比如横向跨团队或部门，纵向跨组织的的情况下，如果统筹技术方向和权衡需求或成本的利弊，《架构即未来》书中提到的联合设计和架构审查，提供了一个可参考的思路，这里做一些过程要点的罗列。

JAD: Joint Architecture Desgin, 联合架构设计；
ARB： Architecture Review Board, 架构审查委员会；

JAD是一个协同设计过程，集中所需资源完成需求的设计的工作，并且这些工作需要符合架构原则和最佳实践的要求。目的是通过跨部门的认知型冲突增加创新。
所谓认知型冲突，直白来讲就是对事不对人，所对应的概念是情感性冲突，对人不对事。

JAD清单:
1.指定参与者，包括研发人员、架构师、运维、DBA等，可选PM、QA等；
2.安排一个或者多个会议，分环节进行讨论和设计，包括DB、Cache、Storage、Net等。
3.从讨论产品需求、业务需求开始
4.回顾架构设计原则
5.头脑风暴，确定概要，没有必要彻底确定所有细节。
6.列出不同方法的优点、缺点。
7.多层会议，记录想法和要点，同步与会者信息。
8.对设计结果达成共识，通过投票、评价、排名等对方案进行评价。
9.为ARB讨论制定文档。

JAD准入标准:
·功能的重要性，项目规模、潜在影响、复杂程度
·成立团队，必要岗位的参与设计，才能进行JAD
·产品要求，明确需求和产品目的
·赋予权力，联合设计方案的决策权
JAD退出标准:
·原则，符合架构原则
·共识，团队意见一致
·权衡取舍，需求、成本或者原则上的重大权衡
·文档记录，可供审查和参考的文档
·评估是否提交给ARB(不符合原则、不能共识、重要权衡、高风险)

ARB会议过程要点:
·参会人员介绍
·阐述评审目的
·展示架构，通过JAD环节的架构设计
·问答环节，说明设计环节的问题
·审议
·投票
·结论(批准、拒绝、有条件批准(可推进)、部分拒绝(再提交))

整个架构方案设计和评审的过程，还是涉及的比较全面，在实践过程还是需要根据公司业务和团队情况进行灵活考虑，例如小团队架构小组的方式会更合适，多业务线或产品线会更加适合ARB的形式。另外在书中也提到敏捷模式下的ARB，不一定是强制审查会议，也可以是抽查和建议的方式，更好的方案是设计原则会作为团队文化下沉到具体工作的准则中，这样既不影响敏捷的团队独立性，又能保持整体架构的一致性。
成立JAD和ARB团队的时候，也需要选择在团队内有技术影响力和领导力的同事参与关键岗位的工作，确保工作推进过程顺利。