软件架构师速成指南

第 9 章 建筑就是销售选项

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在不确定的时代，有几种选择是好事

出售期权

经常有人问我建筑的价值，有时是出于好奇，有时则是一种（值得欢迎的）挑战。遗憾的是，我也经常发现，要简明扼要、令人信服地回答这个看似无伤大雅的问题，对非技术听众来说是多么困难。因此，我认为能够很好地回答这个问题是所有高级架构师的一项宝贵技能。

备注

一位同事曾建议，建筑师的关键绩效指标（KPI）应该是所做决策的数量。虽然决策是建筑设计的一个决定性要素，但我感觉尽可能多地做出决策并不是我的职业驱动力。

用决策的数量来衡量架构师的贡献，让我想起了用代码行数来衡量开发人员的工作效率。众所周知，这种衡量标准是个馊主意，因为差劲的开发人员往往会写出冗长的代码和大量重复的代码，而优秀的开发人员则能为复杂的问题找到简短而优雅的解决方案。经过一番思考，我想起了马丁-福勒（Martin Fowler）最受欢迎的一篇文章，这篇文章也涉及决策制定，但观点截然不同。

逆转不可逆转的决策

许多 传统的软件架构定义都包括做出难以（或昂贵）逆转的决定这一概念。在理想情况下，这些决策应在项目早期做出，以便为项目指明方向，避免 "分析瘫痪"（analysis paralysis），即 项目中的一种危险状态，即在没有编写任何代码的情况下进行需求收集。不过，尽早做出关键决策也有一个重大挑战：项目初期也是最无知的时候，因为人们对项目以及要使用的技术知之甚少。因此，建筑师通常需要利用他们从过去经验中抽象出来的能力来 "正确 "地做出这些决定。然而，持续的项目成本和时间超支表明，在项目早期决定系统结构充其量也就是个难题，即使是对无所不知的建筑师来说也是如此（第 2 章）。

马丁-福勒（Martin Fowler）不久前得出结论认为，事实恰恰相反："架构师最重要的任务之一就是消除软件设计中的不可逆因素"。¹因此，与其把所有关键决策都交给一个人，不如尽量减少早期不可逆决策的数量，这样对项目更有利。例如，选择灵活或模块化的设计可以将后期变更的范围局部化，从而将前期决策的程度降至最低。现在，我们可以认为，决定采用模块化设计是一种二级前期决策--这一点我们稍后再谈。

与技术需求相比，项目的周边结构和流程往往是推动提前做出决策的动力。例如，耗时的预算审批和采购流程可能会要求团队在开发开始前就做出产品选择。 同样，企业软件和硬件供应商也倾向于推动团队尽早做出工具决策，以确保达成交易。他们可能会向毫无戒心的 IT 管理人员承诺，只要从一开始就选择他们的工具，就能取得惊人的效果，包括减少或消除对昂贵的程序员的需求。

那么，如果组织最好不要让架构师做决策，我们该如何雄辩地向上层管理人员阐明这一点呢？

用期权推迟决策

如果您能利用企业的概念和词汇，那么向高层管理人员传达 就会变得更加容易。在此过程中，您甚至可能会发现一些业务概念，这些概念有助于您以全新的方式看待 IT。金融服务为我们提供了选择。

决策是金融服务中的一项常见活动，尤其是在股票交易中。购买一家公司的股票需要你现在投入现金，希望未来能得到回报--这有点类似于购买一辆新车（第 6 章），尽管未来的价格是未知的。现在，如果你能穿越到未来，看到一年后的股票价格，那么只要你还能以现在的价格买到股票，做出决定就会非常容易。时空旅行目前还无法实现，但这个例子清楚地表明，在固定参数的同时推迟做出决定是有价值的。这很直观，因为在必须做出决定时，你会知道更多，从而做出更好的决定。 ...