这一篇我们继续探讨一下架构师的能力要求，思考来自彩食鲜的乔新亮老师。这里角色外延扩大到技术管理者，架构决策与架构设计是生存根基，也决定着职业天花板。
架构决策
架构决策能力是技术管理者最重要的能力之一。这个结论包含的认知是：一把手是团队天花板，并为团队的所有问题负责。
首先可以肯定的是，软件没有银弹，架构决策也是一直在做 trade-off，公司向前发展，当时选择的"最优方案"也会慢慢不适用，就需要决策精进。
为了保证架构持续迭代，建立架构决策流程很重要。小团队架构师的精力足以覆盖所有重要决策，但团队规模扩大后，决策质量与效率需要有流程保证。越高层级技术管理者日程会越紧张，决策推进效率很难像小团队一样迅速。
一般的，架构决策流程包含申请决策，架构评审，征询意见，架构仲裁，结案归档，执行反馈等几个关键环节。流程中依赖模板，进一步阐述业务需求、依赖条件、可选方案与优劣势、决策理由、决策结果与产生的需求等。这又体现了技术管理者的专业能力，保证决策结果落在纸面上，也能培养团队的全局视角与架构能力，体系化的解决问题。
团队扩大后，技术管理者也很难做到对所有架构决策面面俱到了，技术能力要求与精力不足以全部覆盖的时候，就需要快速学习能力，在架构决策流程上，做到只要能讲清楚就可以掌握的程度。
最后，有勇气做决策，并为结果负责。这是技术管理者的生存环境，成长空间取决于不确定性，风险越大成长空间也就越大。
架构设计
架构决策的具体内容就是架构设计，康威定律说明了优秀的架构设计与优秀的组织设计运转机制是一样的——各司其职并协作有序。
然而现实情况往往充斥着大量的反模式：许多程序员开发的系统基于业务需求，而不是基于架构设计写代码。这就导致了投入巨大却要经常对架构上大动筋骨，甚至推翻重写。
这对用户或者企业来说都是巨大的资源浪费，技术管理者是不能让这样的事情经常发生的。所谓善战者无赫赫之功，业务增长有序运行稳定的系统应该像是一潭死水，架构能够快速响应业务需求。
而这，才是架构设计的核心目标——在同等业务复杂度下，经历系统不同的建设阶段，可以花费相近的工作量完成类似的需求。
架构设计进一步的能力要求，乔老师做了精彩总结：
对复杂业务的拆分能力；
对可复用部分的抽象能力；
对拆分过程的颗粒度把握；
以及对未来变化的考量和设计。
对应到架构设计流程，就可以抽象成这样的模板：
- 1、软件可以解决的问题分为确定性问题与不确定性问题，对应到架构视角就是元素（element）与关系（relation）
- 2、业务流程（business flow）分解为功能（function），功能合并成组件（component），组件是元素的业务逻辑集合，有明确的职责
- 3、组件对外暴露的能力称之为服务（service），稳定的关系用 SOA 表达，不稳定的关系用 EDA 表达
- 4、技术管理者在需求到来之际介入产品经理与工程师的沟通中，判断需求是否大幅增加了组件复杂度，并决定是否调整组件的职责或进行拆分
这里的组件不一定是部署实例，而是逻辑实例，如果在业务复杂度不高的情况下有很多组件那就是过度设计（over designed），如果组件复杂度很高而不进行拆分那就是缺乏设计（lack of design）。技术管理者把握其中的尺度，评估团队与组件的复杂度接受能力，做好组件与服务的治理。
由此可以逻辑自洽的验证康威定律再次有效，企业业务流转机制就是分工与协作，组织内是否自洽，组织间是否顺滑。高层级技术管理者判断整体业务发展走势合理切分组织，保证组织间协作高效运转，处理关系，组织内技术管理者高度自治，深化元素。组织设计尽可能降低个人原因产生问题的影响，强化组织效能，架构设计同构于组织设计，最终帮助业务成长。
软件研发活动终究是一项人类活动，须要尊重与顺应人性，也就要求技术管理者能够洞察人性。
