打造高效对话，与商业利益相关者探讨软件架构

"软件开发中几乎所有的问题都能被归咎于是沟通问题。"

—— Thomas Betts

开发团队在为技术决策寻求商业支持时，常需面对的一个问题是：业务人员不怎么在乎技术。如果你能简短快速地把技术决策内容讲清楚，或许他们会考虑下这些能给自己或客户带来什么。随着科技渗透到人们生活中几乎方方面面，也许你能指望他们有基础的用户层面技术认知，但这也会为讨论带来更多挑战：用户往往接触到的都是能正常运作的系统，而不是摇摇欲坠且乱七八糟的底层系统运作。

多数时候这并不算是问题，但也有例外情况：如果你的决策需要资金、产品方向、业务政策或流程方面的业务支持，那么随着技术而来、能为产品带来巨大改善的决策，是需要商业利益相关者能够明白并接受其对业务运行或客户交互方式改变的。利益往往会随巨大成本而来，如果你无法用商业利益相关者能够明白的方式解释清楚，那你将无法获得这些变更所需支持。

信任和透明度促进有效沟通

在“‘业务’是技术的‘客户’”这一观点所带来的众多问题中，最关键的是它让技术忽略了真正的客户；让技术从属于业务，并在二者之间构建了不信任的关系桥。让人有种这业务与技术是被强行分离的错觉，其中双方各有输赢。但实际情况下，如果没有双赢，那就是双输。

后者带来的功能性障碍往往来自于对项目成本和耗时的讨论，情况往往如下：业务说他们需要一个能处理他们不太懂的问题的解决方案，并给出了一系列或多或少真正有用的部分功能清单。技术上钩了，并根据自己对问题的假设以及这部分不一定都有关的功能清单，给出了一套对时间和成本的预估，虽然完全不切实际，但出发点是好的。

为了防止假设出错，技术会用警告说明层层包裹他们对时间和成本的预估以规避任何责任。但就像是迫不及待拆礼物的小孩一样，业务会扯掉所有的说明，只记得成本和预算的估计，并将其写入项目管理系统。

这套预算和预估方法或其他类似手段，都给双方搭建了不信任的基础，在技术和业务双方能够就成本问题进行可行的讨论之前，信任和透明化根本不可能实现。而双方最应该首先明说的是，成本和时间的估计都是假的，最初版本的需求缺乏有用信息且无法从中得出可行估计，但如果技术认为自己从属于业务，那么前者通常不认为自己可以挑战需求，而这种回应更是认可并加强了这种方式。

问题在于，多数的“需求”都是没有价值的，但你也不知道哪些是有价值的。将所有潜在范围全部纳入考量只会导致对时间和成本的预估过于离谱，并因此引发争端。一个更好的出发点，也是建立信任并鼓励透明度的更好方式，是首先需要明确合作之中没有“站队”，业务和技术需要相协作才能尽自己所能地开发出最好的解决方案。只有双方在商业案例上鼎力合作，才能更好地理解商业机会和潜在利益，从而了解自己想要或需要实现的目标，以及成功后自己所能收获的利益。

这么做的好处如下：

• 引导了对预期结果和成功效果的健康讨论；

• 通过财务模型，明确了预期盈利目标下最高开销上限；

• 提供了协作实践，从而引导更为良好的信任与透明度。

至少对大型工程而言，成本和时间的估算的难点在于，如果不构建并测试部分方案，则无法确定解决方案。但是，这也会带来对问题更好的理解以及更好的解决方案，同时也让随预算和工时的估算更加准确。在先前发布的文章中，可找到对”实验在做出好决策中所扮演的角色”这一话题更为全面的讨论。

在能够开诚布公地探讨成本之前，信任和透明是不可能实现的。你需要让商业利益相关者参与到对成本的决策中来，并以结果为导向地对利益和成本进行透明化探讨。对多数大型项目而言，组织在尝试新鲜事物时总会避无可避地涉及到关于得失权衡、方案备选这些困难话题，而从立项开始便进行公开对话，从而协助信任度、透明度以及同理心的建立，是这类困难话题中不可或缺的要素。

以商业成果确定讨论范畴

阻碍技术决策寻求商业投入对话有效性的一大问题在于，开发团队和商业利益相关者的语言不通。准确来说，业务人员会直接忽略技术人谈及的任何科技相关内容。技术需要用技术决策所带来的商业成果来划定讨论的内容，这些才是商业利益相关者关心的部分。

在之前一篇关于技术债务的文章中，为讨论技术债务如何帮助业务人员理解技术决策，我们引用了一个比喻，虽然比喻或多或少有些帮助，但更好的方式是说明技术问题可以协助组织实现其他方式无法达成的商业成果，或者是说明不解决某个技术问题会如何损害组织所能收获的商业成果。

这是一种双向对话。当组织决定退出某个特定市场，或是对监管条目做出回应等业务优先级发生重大转变的情况发生时，用商业结果描述这类转变会让所有人更好地理解其所带来的影响。将架构决策和设计的重点放在其所带来的结果为非构成其设计的功能上，也可以让所有人更好地传达沟通架构为满足不断变化的优先级所需要的调整。

在另一篇文章中，我们借助质量属性需求（QAR）捕捉系统必须具备的重要能力。QAR 所表现的是系统必须实现的商业成果，我们更倾向于使用“刺激、响应、测量”的形式，以贸易金融为例，一个绩效相关的 QAR 可被表示为：

• 当信用专员在接收到出口商文件后处理付款请求信时

• 系统做出响应，将付款发送至出口商的银行，并从进口商的账户中扣除

• 测量以下情况：端到端的付款交易时间不超过 5 秒

用商业结果构建 QAR 有助于建立开发团队和业务人员在讨论系统所必须能实现的重要能力时的共同语言。

示例：讨论安全问题

安全问题颇具挑战性。类似准备应对飓风的讨论，安全问题只有在危机发生时才会得到关注，危机过去后安全相关举措便失去了优先级，也更难得到资助。

探讨具体漏洞往往需要非常专业的知识储备，这甚至是许多开发者和架构师都不具备的（不然漏洞也不会出现），因此与商业利益相关者讨论这些漏洞时就更具挑战性。不过，大多数商业利益相关者即使无法掌握漏洞中的细微技术差异，但却能理解一个漏洞可能导致的潜在后果。与其说明修复某个开源框架中内存泄漏的必要性，不如讨论防止敏感客户账户信息丢失的必要性更具备说服力，比如后者一旦发生可能会被媒体大量报道，对公司造成巨大损失，等等。

在这类对话中，商业利益相关者很可能一开始会说“任何客户信息丢失都是不可接受的”，但接着又会说时间或投资不足以最终支持清除所有潜在漏洞。如果能找到对话构建的方式，他们显然会更愿意承担一定程度的风险。

若想进行更有意义的对话，应在对商业结果的讨论中包含概率和影响信息。只有百万分之一的概率发生，一旦发生对财务的影响也是微乎其微的场景或许不需要应对，而另一个有百分之一概率发生且其后果将影响监管文件或年度报告的场景，就不得不尽快解决了。

软件架构是应用冰山隐藏在水下的部分

与商业利益相关者对话时一个好用的比喻是将应用程序比作是冰山，商业利益相关者只看得到水面之上的部分，大部分应用程序对其而言都是不可见的。要想讨论隐藏在水下的架构就必须把关注点与水面之上可见的部分联系起来。

在另一系列的文章之中，我们引入了最小可行架构（MVA）的概念，是用于支持最小可行产品（MVP）的架构基础。图一借助冰山的比喻形容了这两个概念之间的关系。MVP 对商业利益相关者而言是可见的，而 MVA 则通常是隐藏的。商业利益相关者或许不在乎 MVA，但他们确实关心 MVA 所带来大的 QAR 和商业结果。因此，你可以试着用他们认为系统应当交付的 QAR 和商业成果为导向进行技术对话。

图一：MVP 是利益相关者在乎的，但 MVP 是搭建在隐藏的架构基础之上的

做好准备，与商业利益相关者进行的任何对话最后都会回到金钱上

与商业利益相关者对话会揭露一个令人不快的现实：对金钱的讨论令技术人员感到不适，但商业利益相关者只想谈钱。把项目经理等角色带入对话只会让场面更混乱。以业务成果作为讨论根据的重要性在于，我们能够用商业利益相关者真正关心的话题（金钱）进行对话的同时，仍可以将对话与应用程序的 MVP 和 MVA 相关联。

传统预算都是烟雾弹

在前文中我们已经探讨过，传统预算方法因为其所创建的预估无法与组织想要或需要实现的业务成果对齐而失败。保持与业务成果之间的联系是所有人能继续针对应用程序应该或不应该做什么而进行有意义对话的重要形式。

基于理想功能的 MVP 几乎都是陷阱。这些功能可能并没有什么用，也可能无法带来期望结果。多数功能毫无关联，但你也没办法知道那些是有用的。最好的方法是抛开这些功能，将重点放在结果上，通过小型增量，交付并用其测量成果。

传统预算所依仗的功能清单可信度存疑，其中包含的功能或许有用，但大多数都是没什么关联的，还会让所有人的注意力从真正的问题上转移开，即确定能实现预期结果的最低支出金额。通常来说，只有的一定程度的探索性工作后才能确定这些，但通过一些实验，组织能更好地了解某个主意是否在财务上可行或可取。

大多商业人士都或多或少地明白预算流程的糟糕，某位财务总监曾对项目效益表达过质疑：“如果把我们今年投资的项目所宣称的效益全部都加起来，这个数字将超过公司的年收入”。这是他用来表示效益估算不可信的方式，类似的说法有很多，这种双方均缺乏可信度的情况创造了一个以不同形式工作的方式。

利益相关者真正关心的是成本效益

成本效益是个常常被忽略但是能帮助团队做出更好架构决策的重要质量属性。多数公司，尤其是金融公司，对技术功能的成本非常关心，如零售银行、个人保险公司等等恰巧在零售行业的运作的更是如此，但却很少有团队专为成本效益而设计。这就导致他们所创建的应用程序在运行或维护成本上过于昂贵，如果不考虑成本效益，他们在程序生命周期的后段可能会需要改变架构，从而应对糟糕的成本效益。

在建筑、桥梁和船舶的物理世界中，建筑师常常会根据 QAR 或可实现成果（也可能二者兼顾）对客户提供成本效益和权衡选择。这点是对飞机乃至微芯片的设计师而言都是如此。任何客户都会对成本敏感，无论其所处的领域。

在面对全新的挑战时，组织并不清楚哪些是为达成特定客户成果所必须的，因此详细的成本预估并不现实。为向前推进，技术人员和商业利益相关者需要相互协助，逐步做出决定和权衡，从而带来一个具备成本效益的解决方案。

成本阈值可以更好地帮助团队做出决策

有一种特别针对早期阶段关于机遇、成果和成本讨论的解决方案。假设公司识别了一个机遇，并认为如果能满足特定客户的需求将带来一亿美元的额外收入。如果公司期望其中能有 20%的利润率，那么在成本交付过程中的所有支出总额不能超出 8000 万美元（演示说明中忽略了资金的时间价值）。再假设，至少在项目初期，公司不知道成果是否能交付或交付需要花费多少钱，只知道客户可能愿意为其支付的金钱以及组织愿意为实现这一目标所支付的最大金额数目。我们将后者这个数额称作是成本阈值。

成本总会被纳入考量，尤其是对业务侧来说，但这点在开发解决方案时偶尔会被忽视。在开发者探寻不同的解决方案时，对成本阈值的了解能帮助他们做出更好的权衡决策。如果某个特定的决策会导致超过成本阈值，那么他们会知道自己应该换种方式。假设他们无法在成本阈值之下找到任何可交付的解决方案，那么他们有责任尽早分享这种担忧，让组织得以选择不同的机遇。了解成本阈值也有助于开发者做出决定，从而在不影响解决方案交付的前提下提高利润率。

共同决策有助于改善工作关系

成本阈值能够让成本效益方面的对话变得更轻松，这是传统预算所不能达到的。就如我们在上文中所讲，预算往往是基于多半不准确的预估，局限在这个预算之中却没有获得预期的结果往往不做好，超出了预算但交付了预期结果或许会更好，但只看预算的话也不好说。

从商业角度来说，成本阈值意味着追寻成本超出阈值的商业结果并不可取。这是一种技术侧和业务侧的人都能理解的语言，他们可以进行有意义的对话，探讨是否应当最寻某些特定的商业成果，以及是否能在其他机会中更好地工作。由此能带来以成本和收益为基础，可以对哪些机会下手的健康讨论。

就这些问题进行公开的对话可以帮助业务与技术更有效地协同工作，并共同决定一起工作的内容。

在早期针对成本阈值的对话中所培养出的透明度与信任值，对日后团队需要做出影响成本与解决方案满足 QAR 能力的架构权衡中大有好处。一个例子可以说明这一点：

某开发团队正在评估一个潜在解决方案的底层基础是应购入还是开发。目前团队已经找到了具有众多诱人功能的软件包，但该软件包至少在没有大幅变更之前，是无法满足商业利益相关者认为对解决方案能否达成期望商业成果而言所有必须的 QAR，而这些变更将导致成本超过阈值。

开发团队和商业利益相关者就 QAR 进行了讨论，并共同得出结论：部分 QAR 过于严格，可以进行放宽。他们记录了 QAR 的变更，开发团队也同时在 ADR 中记录：一旦 QAR 变更回原始状态，极可能超过成本阈值。

随着在系统上的工作继续，商业利益相关者和开发团队需要根据对进展中系统的开发与测试时获得的信息，不断审视对 QAR 的假设。一旦假设发生变化，则需要对当前前进方向的可行性进行重新评估，并在可能的情况下纠正方向。

QAR 和成本阈值可用于多个层面，既可用于上文示例中对解决方案的底层决定进行基本决策时，也能用于日常权衡不同的方案中。在任何决策中，人们都要自问两个问题：第一，这个选择是否会妨碍实现预期商业成果及相关 QAR；第二，这个选择是否会导致超出成本阈值。

许多 MVP 乍一看很有前途，但未考虑到的成本将会让项目不堪重负，最终在其生命周期的成本累积下崩溃。对架构的挑战在于，如何构建一个能在全部生命周期中维持在成本阈值之内的解决方案。一旦解决方案露出无法继续维持在其成本阈值之内运行的苗头，就是产品需要退役的标志。

架构在于管理权衡：有意义地探讨权衡可能颇具挑战

组织有时会在未能完全理解权衡背后意义的时候做出决策。示例如下：

• 为抢先进入市场，组织所采用构建 MVP 的技术无法满足基本 QAR，如使用无法扩展至目标工作负载级别或无法满足关键安全性 QAR 的低代码开发工具。

• 忽视早期工作设计中的可扩展性隐患，认为应用上云能解决任何未解决的扩展性问题。

• 只关注在线用户体验问题而忽视大规模的运营问题，而后者本质也是用户体验问题。这类情况可能包括：过多地关注产品的订购，而非订单确认到客户收到产品之间的所有事。

解决这类生命周期相关的问题意味着人们能就技术性极强的问题，与不具备对应技术深度的人进行高效的讨论。对 QAR 和期望商业与客户成果的关注为技术与业务之间的相互理解打下了基础。上文中的最后一点强调了理解技术和解决方案架构的重要性，不仅在与对许多人的影响上，也在于需要支持涉及业务不同部分的复杂流程上。

类似的情况在医患讨论替代疗法时也会发生：患者通常不具备理解手术细节的医疗背景，但如果医师以结果为重点，那么他们将能以不同方案对患者的短期及长期影响的期望结果进行有意义的探讨。

在架构类型的决策讨论中，共同语言往往是由技术决策可能如何影响解决方案是否满足重要结果或 QAR（或二者兼顾） 所决定的。因此，任何会影响成本阈值的都应被纳入讨论范畴，其中就包含万一决策反转所导致的可能成本出现。这样才能让所有人都理解决策的潜在影响。

解决方案提议的细节并不重要，重要的是它给商业利益相关者所看重的成果和 QAR 所带来的影响。这些讨论的结果以及其中对架构的探讨都应被记录与 ADR 中，后者需要包含对结果或 QAR 讨论的总结，用于留存做出决策的上下文情况。

让商业利益相关者参与到关键架构决策（或至少是结果与 QAR 方面）的重要好处在于，所有人都是原始决策的一部分，所有人都对决策“负责”，这让涉及变更或反转决策的讨论更为容易，也大大减少了互相甩锅的决策讨论现场的出现。

当然，也会有一些无关紧要的架构决策，无需牵扯商业利益相关者。如果决策不会对成本阈值或解决方案能否时限期望结果或满足 QAR 造成重大影响，那么这些决策就与商业利益相关者没什么关系，开发团队可以自行做出决策。

示例：探讨可扩展性相关决策

就如在“实践中的连续架构”所述，“可扩展性可被定义为，通过增减系统成本来处理变化的工作负载的系统属性。”可扩展性相关的架构决策可能对部署和运营成本带来极大影响，且可能需要在可扩展性和其他属性（如性能）之间进行权衡。

图二中展示了可扩展性是如何影响成本及其他 QAR 的：

图二：可扩展性-性能-可用性-易用性的成本关系

可扩展性在技术上很复杂，但这种复杂性却很难传达给商业利益相关者。商业利益相关者或许会认为扩展性或性能问题是可以通过砸钱解决的，比如购入更多容量，“让系统上云”、“亚马逊化”；可以对扩展性问题高枕无忧，因为有云供应商在兜底。可实际上，无法在专用环境中正常扩展的设计失败的系统，在没有进行大规模设计改造的前提下，很大概率在商用云环境中也没办法正常扩展。

如图二所示，满足可扩展性 QAR 意味着一系列的复杂的权衡问题，这些权衡决定会影响系统在成本阈值内满足业务成果和 QAR 的能力。

与商业利益相关者对话时的首要挑战是确定他们对可扩展性的要求，这一点他们或许没有考虑太多，也许了解也不够，如果不需要做出任何代价高昂的决策，这在一段时间内是可以忍受的。模拟大型工作负载对 MVA 的影响可以带来对其可扩展性和性能的更多了解，同时也会带来对扩展需求相关的对话更为有用的信息。

结论

总之，商业利益相关者看似只关心钱，但这种说法并不完全正确。他们关心的是利润，如果开发团队在讨论赚钱时只说成本，则是限制了自己进行健康的权衡对话、从而开发出更好解决方案的能力。

开发团队可以改变与商业利益相关者对话方式，从而提升对话的效率和质量。首先要做是，避免因为对解决方案残缺且不正确的假设从而导致的毫无作用的预算相关对话，将对话的重点转移至解决方案需要达成的商业成果和 QAR 上。随后，双方均需要探讨这些达成的结果对自己的价值，以及组织为实现这些结果所能承担的最大花销（即实现结果的成本阈值）。

一旦踏上了更为高效的路线，开发团队应继续专注于维持成本阈值，甚至要在可能接近或超过这一阈值时，尽早提出问题并降低阈值。因此所产生的与商业利益相关者关于权衡的对话会帮助所有人做出更好的权衡决策。

原文链接：

How to Have More Effective Conversations with Business Stakeholders About Software Architecture

相关阅读：

ThoughtWorks CTO：2025 年之前，我们会看到架构的演进，但不会看到革命

避免成为“象牙塔”架构师：架构师和组织之间的关系