架构中的大象

使用价值流图来检查架构

评估架构中业务价值的一个好方法是进行价值流图，重点关注 IT 环境中的各种系统和组件。企业通常会对业务流程进行某种价值流图，检查客户旅程的每个部分如何影响收入和利润，但通常一旦他们到达 IT，映射就会停止，并且不会尝试通过各种系统映射价值流。

架构师应该在此基础上，通过将类似的业务指标分配给支持业务流程的系统，将映射扩展到这些系统。除了财务指标之外，还可以考虑重要的非财务指标——客户在线查看索赔状态的能力在多大程度上影响客户留存率？（此类指标通常更难衡量，但思考如何衡量它们通常会产生重要的见解。）

在最近的一个客户案例中，我们进行了这样的练习，从描述客户如何与客户公司互动的客户旅程开始。我们将这些步骤放在团队房间墙壁的顶部，然后将每个步骤与客户 IT 组合中的系统和组件联系起来。然后，我们可以评估每个系统如何为客户旅程中的步骤做出贡献，以及故障可能产生的影响。

考虑故障对业务价值的影响

正如我们的第一个例子所暗示的那样，在评估故障后果时，有一个特别重要的方面。如果我们想要采取措施来提高系统的弹性，最好用风险价值来表达，如果系统发生故障，风险价值就会出现。一家零售商一直在努力证明测试其库存数据库的备份恢复过程的合理性。由于圣诞节前需要大量的业务可见功能积压，很难优先考虑这样的技术任务。我们的建议是询问企业对黑色星期五的数据库崩溃有何感受：成本是多少，他们希望系统多快恢复？这些问题导致了围绕进行数据库恢复演练的业务主导决策，并减少了原本会被埋没在 IT 工作队列中的恢复时间。

在评估风险价值时，值得采用两种互补的方法。一种方法是从上到下，查看业务功能并确定哪些软件系统支持该功能。另一种方法是反过来，从软件系统开始，考虑这里发生故障会有什么后果。

分析风险价值的重要部分是认识到，由于不同的故障会导致不同的严重后果，因此并非所有软件组件都需要相同的弹性级别。想象一下节礼日（英国黑色星期五的等效日期）的库存管理系统出现故障。如果这意味着我们无法检查库存水平，我们要么确认无法完成的订单，要么不接受订单——这两种情况都会造成重大损失。但是，履行系统出现故障可能会导致订单排队等待处理，这可能会导致交货延迟。企业领导者可能会认为后者是一个较小的问题，因此他们愿意接受该系统较低的弹性。无论具体情况如何，关键在于弹性级别是一个业务决策。同样，数据一致性也是如此。在查看分布式数据库时，架构师经常对放松一致性以换取可用性感到犹豫。但是，双重预订几个酒店房间的业务成本可能比根本无法预订房间要少得多。CAP 定理中规定的关于一致性和可用性之间的权衡，是一个业务决策，而不是技术决策。

跨职能需求应由业务价值证明

这里的一个主题是，我们不应该只评估功能的价值，还应该评估通常被归类为跨职能需求（我们对非功能需求或“ilities”的首选名称）的系统特性的价值。如果我们希望我们的系统符合某些技术标准，那么我们需要了解未能做到这一点会造成什么价值损失——并将这种价值传达给非技术利益相关者。评估 CFR 的价值通常很困难，许多技术人员回避由此产生的争论。但是，未能做到这一点造成的危害不仅仅是过度投资于低价值技术的风险。它还会在技术人员及其用户之间的协作之间设置一个真正的障碍。

了解价值应该为有关组件灵活性的决策提供信息。一位客户有一个支付处理组件，该组件被编程为与特定的支付处理公司合作。他们希望它易于配置，以便他们能够在支付处理器发生变化时快速调整它。存在两种广泛的选择。一种是在支付处理组件中硬编码与支付提供商系统的交互，而另一种选择使所有此类交互都可配置。可配置选项将允许通过更改配置文件在几天内更改支付提供商。然而，通常情况下，这种可配置性会增加组件代码的复杂性，从而增加任何其他更改的成本。这是可配置性常见的一种权衡——您以在其他地方进行更难的更改为代价，简化了可配置部分的更改。这里至关重要的业务背景是，更改支付提供商的难点实际上是协商新的法律合同——这通常需要一年多的时间才能完成。因此，在这里配置提供商信息并不值得，因为修改不可配置组件仍然比法律谈判快得多。

业务价值意味着 CFR 随组件而异

最后两个例子都说明了，对弹性和灵活性等方面采用“一刀切”的方法可能弊大于利。几年前，我们与一家组织合作，该组织决定强制执行“五个九”的可用性要求，令人惊讶的是，他们甚至将其应用于员工用来预订他们最喜欢的午餐零食的三明治订购系统。我们发现与企业商定不同的服务级别非常有用，例如，服务的丢失是否会立即影响客户体验或收入，或者我们是否可以承受它在数据库恢复期间停机几个小时？

另一个可以通过了解系统如何支持业务价值来突出显示的问题是，单个组件必须支持多个不同的价值流和可靠性级别。这在单体组件中很常见，其中支持多个不同的业务流程，并且可能是将事物分解成多个部分的重要动机，例如，只在业务价值证明的情况下支付高可用性的溢价。

使用监控来评估业务价值

我们非常喜欢使用丰富的监控来更好地了解系统如何运行，这对于日益复杂的分布式系统尤其重要。这种监控通常侧重于系统健康状况，支持生产中的 QA。但是，我们也可以使用这种监控来评估系统对业务价值的贡献——例如，确定有多少销售收入通过特定组件。一位零售客户发现，监控其大型机上的队列长度和消息速率可以很好地代表其每家商店的收入，虽然不准确，但让业务利益相关者了解这一点，可以让他们发现纯粹从技术角度进行监控可能错过的问题。另一位客户能够为其网站上的每笔交易推导出准确的收入指标，并在其办公室周围的屏幕上每分钟显示一次。随着时间的推移，人们对这些屏幕的关注远远超过了显示 CPU、内存和其他技术指标的屏幕。

有人可能会争辩说，收集此类数据不属于了解系统行为的一部分，但我们断言，这对于了解软件组件对业务的贡献至关重要。随着越来越多的系统托管在云上，我们可以看到为单个 FaaS 函数生成的账单。如果我们可以将成本细化到这种程度，我们也应该努力收集有关收益的数据。

定期监控数据本身就可以为投资决策提供信息。我们遇到过一家政府机构，该机构使用网络为其公民提供服务。其为其网络应用程序添加新功能的成本因支持旧浏览器的成本而大幅增加——对于那些无法升级的公民来说，这被认为是强制性的。查看流量显示，使用这些旧浏览器的公民很少，因此与其支持旧浏览器，不如为他们提供一台新电脑和一束鲜花更便宜。

如果您要迁移到云，只需迁移有价值的部分

随着云系统的兴起，我们看到许多组织希望将他们的软件系统迁移到云托管。这与系统替换的悠久历史相呼应，公司希望用支持相同功能但在更现代（希望更有效率）的基础设施上运行的系统来替换现有系统。在我们职业生涯中，见证了数十年的此类努力，我们发现了一些容易犯的错误。也许最常见的是，人们认为最简单的系统替换方法是功能对等替换，即试图在新平台上完全模仿现有功能。这种一对一的做法忽略了这样一个事实，即许多现有功能价值很低，有些根本没有使用，有些甚至会积极地干扰最佳业务流程。功能对等替换比人们通常认为的要难，花时间避免复制很少使用的功能，其回报很容易就能弥补。

我们与一家组织合作，他们通过将 100% 的物流处理代码迁移到新系统中来启动迁移工作，这花费了几个月的时间，并涉及到他们许多开发人员。当我们与业务部门讨论他们的未来计划时，他们解释说他们计划由于成本过高而放弃对许多包装类型的支持。事实证明，处理包装周围的所有边缘情况是迁移过程中最耗时的部分，然而，即使没有这些功能，业务部门也会很满意。

因此，了解对业务价值的贡献可以极大地帮助确定如何更好地进行重新平台化工作。如果现有组件没有贡献太多价值，那么就不应该将它们复制到新平台中。这里的一个常见案例是服务公司，其大多数服务遵循一些常见案例，但也有一些不常见的服务，这些服务很少出现。这些不常见的案例通常涉及特殊的软件支持，但这些边缘案例在重新实现到新平台之前应始终进行审查。如果企业预计在未来六个月内停止提供此服务，那么这应该作为重新实现计划的一部分来理解。

业务价值至关重要，但并非一成不变

就像生活中或软件架构中的任何事情一样，对价值的这种评估并非一成不变。我们与一家保险公司合作，该公司通过其评级模型获得了竞争优势。该软件被视为该公司的“王冠上的明珠”。但随着时间的推移，保险报价在线化，并采用直通式处理，发生了巨大的转变。这颗“王冠上的明珠”需要大量的参数，这些参数在在线时代之前可以通过代理与客户会面来合理地获取，但复杂的表格在网络上过于不受欢迎。随着这种转变，他们“王冠上的明珠”的价值逐渐消失。因此，除了了解软件资产的当前价值外，还值得尝试粗略预测该价值如何受到技术和商业环境变化的影响。

另一个案例是一家零售商，其目录管理系统能够轻松应对每年更新两次，但无法应对快速在线变化的转变。失去收入的机会成本永远难以量化，但在决定将投资放在重组或重写组件的哪个位置时，需要考虑这一点。

业务知识应成为技术职业发展的一部分

当人们关注技术领导者的成长时，大多数注意力往往集中在“硬”技术主题上。各种软件平台的培训课程（经过认证，不言而喻）比比皆是。对于技术技能发展，我们提倡专注于核心原则而不是当今流行平台的培训。明智的技能发展认识到，随着人们在领导阶梯上不断攀升，“软”技能（注意我们的反讽引号）的难度要大得多，变得越来越重要，我们也赞同这一点。 [1]

尽管这些东西很有价值，但我们也认为，确保技术领导者对他们所经营的业务以及该领域中各个参与者如何创造价值有深刻的理解至关重要。这通常不是通过培训课程获得的，而是通过与业务领导者定期互动获得的。这种社会互动应该在技术人员职业生涯的早期就开始。将 IT 人员与业务人员分离会给软件开发等职业带来难以言喻的弊端，因为软件开发的价值根植于软件与支持其活动的企业的活动深度交织的程度。开发人员需要尽早了解与用户和客户保持持续联系是正常的，并学习如何做好。多年的这种联系，当他们成为领导者并熟悉他们成长起来的业务中的人员时，将带来巨大的回报。