备注说明：相关总结属于个人学习笔记，请勿商用，感兴趣的可在极客时间订阅该《乔新亮的CTO成长复盘》专栏学习，谢谢~
决策失误，是“技术债”的主要来源
选择：是继续沿用 ESB（企业服务总线）架构，还是转向分布式架构。
选择分布式的理由
- ESB 是一个集中点，风险非常大； 如果选择 ESB 架构并且让其承载大量的业务逻辑（系统间调用的处理逻辑），后续转型困难；
- 系统内虽然存在部分异构系统，但大部分是同构系统，分布式系统完全可以支撑；
- 在分布式架构中，不同服务可以直接访问，无需像 ESB 架构一样经过负载均衡系统和网络交换机，避免了资源的浪费；
一般顾问是无法影响甲方公司决策，但是对于重要的长远决策要有自己的判断力。
决策者选择“不作为”
两个架构成员技术争吵时，管理者的处理方式：
- 给大家分析哪一种方案更好，现场拍板；
- 指出当前双方考虑不周到的地方，再给大家时间去准备，并在 Deadline 前决策拍板；
- 泛泛地对大家说：“不够具体”、“没有重点”，“再回去想想”……
1和2都提现 决策者有见解，1表现 追求决断效率，2是团队培养
3是管理者不懂，并且拖。
一把手是团队的天花板，并为团队的所有问题负责。
做好架构决策的流程和模板
- 当事人发起架构决策申请；
- 由产品负责人判断：该申请是在产研中心部门内协调解决，还是上升至 CTO 办公室解决；
- 在产研中心部门内，或联合 CTO 办公室，完成架构评审；
- 将结果发还至当事人征询意见；
- 由当事人判断是否仍有疑虑，需要进行架构仲裁；
- 若需要则发起仲裁会，解决分歧；
- 若不需要则结案归档，执行决策。
如果是部门内协调解决，则 CTO 办公室不参与评审；如果评审后仍有分歧，则 CTO 办公室连同其他负责人一起介入架构仲裁，快速解决问题。
在上述决策流程里，最困难的不是架构评审和架构仲裁，而是向下推进的动作和速度。
流程表格：
架构決策
待决策内容 决策编号
决策人
通知人
决策日期
架构决策申请编号/
文件名称
业务需求/问题描述
假设条件
重要性
可选方案1
可选方案2
决策结果
决策理由
因决策而产生的需求
其他相关决策
表格内容必须填满
从「待决策内容」到「决策申请编号」，这部分内容是为了更好地将决策事件归档，以备以后参考、调研、借鉴；
「假设条件」是为了注明可选方案的依赖条件，以免出现建设“空中楼阁”的情况；
「重要性」的标注是为了提升决策效率；
「因决策而产生的需求」和「其他相关决策」，则是确保决策可以落地。
- 第一，这套流程和意见反馈模板，可以让当事人及各参与方，做好充分的思考和准备，避免浪费大家的时间；
- 第二，所有分歧会落实到纸面上，能防止沟通出现歧义，也预防推诿、扯皮的现象发生；
- 第三，可以培养所有人的大局观和架构决策能力，间接推动人才梯队建设；
- 最后，用体系化方案解决团队问题，追求的是“一劳永逸”地解决问题。无论是流程还是表格，都不仅是一样工具，更是一种思维模式。
技术管理者如何做好架构决策
第一项特质：要学会站在全局视角看待问题，学会看到技术架构的“外部价值”
第二项特质：具备相当的技术深度，以及非常好的学习能力和逻辑思维。
总结 ：
初级管理者来说，要尽早培养自己的架构决策能力，尤其重视思维模式的培养、个人技术栈的深度扩展以及逻辑思维能力的锻炼。 对于高级管理者来说，则要做好认知层面的储备。
拖延做决策的管理者，要么是不懂，要么是战略懒惰，
