1.3　决策是平衡与取舍的艺术

鱼与熊掌不可兼得，技术部门内部的工作决策，尤其是技术主张、架构设计类，经常出现没有正确答案、各个团队各执一词的场面，就其本身而言确实是客观的，例如，引用新技术的风险与机遇、微服务拆分的颗粒度、几种开发框架的选择、系统间关系设计及通信协议的选择、对业务数据迁移的风险估计等，或者是开发周期短与测试把关要求严之间、质量与交付速度之间、快速解析数据与使用高强度加密算法确保安全之间……无处不在的矛盾体。技术决策的选择，不会出现简单的答案，各类设计、各种主张都有各自的道理，需要技术负责人承担决策责任。

1.3.1　没有完美答案

使用更多设备作备份，可以降低故障率，降低管理复杂性，但更多的设备需要更多维护，增加了管理复杂性。看似简单的技术工作决策，背后矛盾无处不在。架构师应该明白，世界上不存在十全十美的设计，很难既高性能又高可用，既高度安全又高度抽象。定义软件架构，就是要在质量属性、成本、时间以及其他因素之间做出正确的权衡。对于软件平台而言，什么都想要，最终结果意味着失衡。

决策并不是给出完美的答案，决策的核心，是在有限的时间内尽量充分地沟通，合理进行“取舍”，决策工作不是技术工种，究其根本是门“折中”的艺术，以达到一个平衡的目标，多数情况下你并非是以某一个选择作为结果，而是多个观点之间的平衡点。这是对决策者的才华和工作价值的考验。软件行业应多向成熟的建筑行业学习，向建筑师学习，对美学的学习、对哲学的理解，以及涉猎各类杂书的好习惯，都会直接提升对“决策之所以谓为艺术”的理解。

独断专行的决策方式是极左，过于民主协商的决策方式为极右，两者都有缺陷。最佳决策应该是在创意择优中，按照观点的可信度高低来得出，圈定参与决策的人员，每人提出自己的观点，对于能力强、责任大的人员，还应该在过程中努力解决彼此分歧，不同能力者观点的权重不同，进行可信度加权产生决策参考结果（大家都清楚即可，一般不需要搞投票或打印单子签字，尤其是技术部门内部的决策，不应该太为形式所伤神），这样的方式是一种客观公正的规则。

当然了，决策者必须保持独立思考，“一个人一条龙，十个人一条虫”的现象在IT工作中屡见不鲜，作为决策者，你有权推翻参考结果，但是有一套这样的公允机制总比没有要好很多，这种机制给团队的赋能，应该由平台技术负责人来牵头推动。

需要注意的是，决策者没有必要凡事都做出判断，但是必须能够适时终止辩论，知道如何超越分歧，推动就下一步措施形成共识。有时延时决策（如放到下次会议上决定）是很好的缓释方式，有句谚语叫作“退一步，海阔天空”，这和个人风格有关，急于行使权力，为决策负责的心态，可能会让决策者掉入决策陷阱，问题背后往往隐藏着超出你想象的信息盲点和信息不对称，决策者可能还没有了解足够的素材，更没有充分论证，匆忙、轻浮的决策，可能经不起三天后的再推敲。决策者要明白的是，大多数情况下，决策的正确性比决策的时效性重要得多。时效性体现的是表面执行力和工作态度，但仅此而已，“正确性”才是决策工作的核心。

1.3.2　记录决策理由

作为良好的工作习惯，决策者应该在当时用最简单的方式自行记录决策原因。2021年的一次关于“某个共享系统是否要拆掉，将其承载的功能剥离到各个业务线系统来自行实现”的会议，结论是“有利有弊、不好判定、先不拆”，有点延时决策的味道。因为有这个方案的会议讨论材料，我认为无其他遗留了，但是今年的另外一个事情，比较复杂难以权衡，可以用这个做个参考，但已经无法翔实回忆当时的决策依据，只能用“无奈”二字描述此时心情。这类内部技术会议一般不会费力安排会议纪要，即使有记录员也难以写清楚技术观点分析，决策原因作为深层次思路的体现，又有“艺术”感觉的加持，只有自行记录，效果才最佳。虽然属于过程资产，但可能十分精彩，绝不应该被错过，可以使用文本形式的速记备忘录，或者使用更为正式的模板也可，当然了，这时有个“烂笔头”再好不过。

记录“我们做了什么决策”“为什么这么决策”的核心内容，“还考虑过哪些方案，为何没有采用”也在备忘范围之中，随手速记、无须为之付出维护精力，但具有很高的回报价值，可以作为和开发人员沟通的工具，说明基础理由和策略路径，针对开发人员的质疑能够“就事论事”，避免“兵变”，也可以用于任务移交，或者能在相关条件变化后对决策进行重新评估。

对于架构设计工作，用心记录的决策理由，其本身就是一套架构演变文档，无论如何这类材料都物超所值。

1.3.3　掌握行业方法

决策一词非贬义，但也绝非褒义，过多决策意味着工作根基出现了问题。参与平台级架构设计工作，多是一个团队而非一个架构师，绝不可仅凭个人头脑，作为最佳实践建议。掌握和使用行业的成例方式作为参考，在很大程度上，可以帮助我们尽快选定合适的“方法论、表达模式和工具支持”，能够在这个方面避免陷入过多的技术讨论和被迫决策。参与决策工作的精力有限，应该用在真正属于平台自身的领域问题。

架构设计虽然不是成熟的学科，但是有大量可称为事实标准(3)的设计方式可供循迹，典型如4+1架构视图(4)，对于“4”有两个分支，一种为逻辑视图＋过程视图＋物理视图＋开发视图，另一种为逻辑视图＋进程视图＋部署视图＋实现视图，应该说核心未变，但两种方式的侧重还是有所不同。这样的设计标准，确实给了我们基础指导，需要完全领会，否则不可简单套用于实际工作。

“架构视图”一词，确系经典，但更给人以“从剖面、窗口看到的内容”之感，侧重结果的表达，含义略显匮乏。经过深入考虑后，本书推荐的词汇是“架构主题”，我认为“主题”二字所携含义更深厚，更具有对特征的识别、分析，以及主旨探索之意。形象化看，一个视图是整个平台的横切面。而前端技术架构、大数据架构、统一身份认证架构等是平台纵向的组成部分，是一个个领域，并非某个视角的全平台横切面。严格说，架构设计的对象（学科范儿一点，可称为标的物，本书下文有几处使用标的物一词），并非几个经典视图，而是包含了一系列的领域对象。既有横切视图，也有纵分领域的情况下，主题是我能想到的最佳词汇。对此，可以多给自己一些积极的暗示：超越，无处不在。

良好的架构工作要成为闭环、有头有尾，除了专业技术、素质能力、工作经验等范畴之外，还可以借助一些有助于架构决策的方法论工具，例如，架构权衡分析法(5)、成本收益分析法(6)等，可以学习（具体可以访问软件工程协会SEI的网页），甚至是套用。国内而言，ADMEMS(7)方法更为行业所熟知，各自定位有所不同，ADMEMS侧重于“软件架构设计工作的过程、方法和步骤”，而不是“对软件架构进行评估，进而推导决策观点”。

本节所述的这些行业方法，相互间并不在一个量纲上，在架构内容表达、架构属性（如适应性）评估、架构设计工作过程和方法等方面各显神通。理性理解，实际工作中适当选择使用，会提升架构设计的工作效率，注入更多信心，不要推脱这些更像是项目管理（PM）岗位应该做的事情，技术负责人应该首先知晓。