8.2

8.2 工具生态:自建与购买

概述与动机

每一个实施本书指导的组织,最终都会面临一项实际的基础设施决策:在内部自建指标工具,购买一个商业工程分析平台,或者,在实践中最常见的,把两者以某种方式结合起来。本主题以主题 5.5 应用于任何其他工程投资同等的严谨性来对待这项决策:一次专门针对你组织的规模、现有数据来源,以及你真正打算跟踪的本书具体指标的诚实成本效益分析,而不是一个不论情境如何都统一适用的默认答案。

商业工程分析工具市场已经相当成熟,许多平台现在为DORA指标(第2部分)、拉取请求和评审数据(主题 2.9),以及日益增多的开发者体验调查基础设施(主题 3.7),提供了扎实、大体自动化的埋点。这种成熟度,已经把许多组织的算盘,拨向了至少购买基础层,但它并没有消除自建选项对特定、定制化需求的真正优势,尤其是围绕主题 7.4 所论证的、如今是一套指标项目必要中心的结果遥测,这往往是本书所涵盖的测量类别中标准化程度最低、组织特异性最强的一类。

对大团队而言,这项决策带有真实、持续的预算和工程产能后果。企业组织常常需要在一片真正异构的遗留和现代系统景观中整合指标工具,这显著地塑造了自建与购买的算盘;政府组织常常面临采购限制,以及数据主权或安全要求,这些要求实质性地影响着哪些商业选项甚至是可行的,有时会把决策拨向自建,或拨向一小撮经过特别审核的供应商,无论纯粹的成本效益分析本身会建议什么。

核心原则

  • 这很少是一个全有或全无的决定。 大多数成熟的指标项目,把针对良好标准化指标购买的工具,与针对组织特有结果遥测自建的工具结合起来。
  • 为良好标准化、被广泛需要的指标购买;为真正组织特有的指标自建。 DORA指标和拉取请求分析是大宗商品领域;你具体的业务结果关联(主题 5.3)通常不是。
  • 数据所有权和可移植性,与功能对比同等重要。 一个把你的指标数据锁定起来的工具,是一项持久的风险,而不仅仅是一种不便。
  • 集成成本在自建与购买分析中常常被低估, 两种选项都是如此。
  • 采购、安全和数据主权限制,可能凌驾于一次纯粹的成本效益计算之上, 对政府组织而言尤其如此。

建议

为大宗商品层购买:DORA、评审和调查基础设施

对于拥有成熟、广泛可得商业工具的指标家族,DORA指标埋点(第2部分)、拉取请求和代码评审分析(主题 2.9),以及开发者体验调查平台(主题 3.7),对大多数低于某个规模的组织而言,购买通常是更好的经济选择,因为构建同等的基础设施,会重复许多供应商已经大量投入的工程努力,而自建版本能获得的真正差异化十分有限。

为真正组织特有的结果遥测自建

对主题 7.4 所论证的、应当成为你指标项目重心的结果指标而言,业务结果关联(主题 5.3)、与你具体产品挂钩的功能采用(主题 5.2)、与你具体成本结构挂钩的单位经济学(主题 5.4),商业工具的标准化程度远低得多,而且常常无法在不经过大量、昂贵的定制化的情况下捕捉到你组织具体的业务逻辑和数据模型,而这种定制化的最终成本,可能超过在内部自建等效能力、并对结果拥有完全控制权的成本。

在签约供应商之前评估数据所有权和可移植性

在签署一份商业合同之前,确认你能以一种可用的、标准的格式导出你完整的历史指标数据,并理解如果你更换供应商或终止服务,这份数据及其历史会发生什么。一段因数据锁定而变得难以退出的供应商关系,是一项持久的组织风险,而不仅仅是一种不便,这项评估理应获得与任何其他重大、跨越多年的基础设施承诺同等的严肃对待。

在决策的两侧都为集成成本做出现实的预算

无论是自建还是购买,集成成本,也就是把工具与你实际的版本控制、CI/CD、事件跟踪和业务系统连接起来,在任何一条路径的初步规划中都常常被低估。在你的自建与购买分析中,明确为这份集成工作预留一个独立、重要的预算项目,而不要假定一个商业工具会开箱即用、只需最少的设置,或假定一个自研解决方案的集成成本只是其开发成本的一个次要补充。

明确、及早地核算采购、安全和主权限制

对政府和受监管的企业组织而言,数据主权要求、安全认证需求,以及采购流程,可能实质性地缩小或消除某些商业选项,无论它们的功能质量如何,有时会把决策拨向自建,或拨向一小撮经过专门审核的供应商。在评估流程中明确、及早地识别这些限制,而不是等在一个选项上已经投入了大量评估努力之后,才发现它出于与实际能力无关的原因不可行。

权衡取舍:利与弊

方案优点缺点
购买商业工具部署快,功能集成熟,由供应商维护对组织特有的结果指标定制化程度较低;存在潜在的锁定风险
自建内部工具完全定制化,完全的数据所有权和控制权需要重大、持续的工程投入;对大宗商品指标而言重复了努力
混合:购买大宗商品层,自建结果层在最重要的地方,把成本效率与真正的定制化平衡起来需要集成工作,才能把购买和自建的组件连贯地连接起来
通过大量供应商定制,购买一切(包括结果遥测)单一供应商关系,采购可能更简单可能变得和自建一样昂贵,对结果的最终控制权却更少

核心张力是定制化需求与开发成本之间的张力。最能从定制化中受益的指标,也就是专门与你的业务挂钩的结果遥测,也是构建得好最昂贵的指标;购买起来最便宜的指标,DORA和评审分析,也正是真正的定制化最不重要的指标。解决这种张力的办法,是让决策直接匹配这种模式:在标准化能很好地服务于你的地方购买,在你具体的情境真正需要它的地方自建,并在这种划分的两侧都为集成成本做出现实的预算。

与团队讨论的问题

  1. 对本书所涵盖的每一个指标家族,我们真的会从定制化中受益,还是一个标准化的商业工具就能同样好地服务我们? 明确地走一遍第2部分到第6部分,根据这项具体检验,把每一个指标家族分入购买栏或自建栏。

  2. 我们是否评估过我们当前或潜在供应商的数据导出和可移植性选项,还是我们假定如果需要就能轻易离开? 直接检查这一点,而不要假定;数据锁定往往只有在一个组织真正尝试转换时才被发现。

  3. 我们最初的自建与购买分析,是否现实地核算了集成成本,还是它主要聚焦于许可费用与开发工时? 重新审视一次近期的工具决策,检查集成成本是否真正被估算过,还是被严重低估了。

  4. 我们是否面临采购、安全,或数据主权限制,无论功能质量如何,都会排除某些商业选项? 在对可能被证明不可行的选项投入大量评估努力之前,而不是之后,明确地识别出这些限制。

  5. 我们当前的工具景观,是一种刻意的混合,让自建和购买各得其所,还是它是随时间通过一系列临时、单独看都合理的决定积累而成的? 诚实地面对哪种模式真正描述了你当前的情况。

  6. 如果我们今天需要更换当前的指标工具供应商,在精力和风险上会花费我们什么代价? 这个具体的问题,检验了你对数据锁定风险的真实、当前的暴露程度,而不只是供应商合同条款名义上承诺的内容。

行业视角

初创公司。 在这个规模上,默认购买大宗商品工具;当成熟、廉价的商业选项专门为DORA和评审指标而存在时,构建定制化的指标基础设施很少是对稀缺早期工程产能的好利用。把任何自建的努力,保留给那项最直接反映你产品核心价值的单一结果指标(主题 5.3)。

小型企业。 大多数商业工具选项都能相当好地按小规模缩放,价格也对较小的组织较为亲民;购买大宗商品层几乎总是正确的选择,而构建任何定制化的东西,在你的组织已经显著成长、发展出真正具体的需求之前,很少有正当理由。

企业。 本主题所建议的混合方法,在这里发挥出它的复杂性价值:在规模上购买大宗商品层(常常拥有实质性的议价筹码以获得优惠条款),并刻意投资于构建组织特有的结果遥测层,因为在这个规模上,你的业务逻辑和数据模型复杂性,通常超出了通用商业工具在不经过大量、昂贵定制化的情况下所能容纳的范围。

政府。 采购流程、安全认证要求,以及数据主权限制,常常比纯粹的功能或成本比较所暗示的更能主导这项决策。在评估流程的早期就让采购和安全利益相关方参与进来,并做好准备,在这里,自建选项可能真正比在一个可比的私营部门情境中更有吸引力,具体原因是这些限制,而不是因为自建天生更好。

案例

企业。 一家软件公司最初尝试构建一个覆盖第2部分到第6部分每一个指标家族的完全定制化指标平台,这是一项跨越多年的努力,消耗了大量工程产能,却依然在标准化的DORA和评审指标上,专门落后于成熟的商业产品。一项修订后的战略,为这些大宗商品指标采用了一个商业平台,把内部平台团队释放出来,专门专注于构建真正特定于公司商业模式的业务结果关联和单位经济学遥测(主题 5.3、主题 5.4),而这是任何商业工具都无法开箱即用提供的。这种混合方法在一年内,交付了一套比全面自建战略在两年后所达成的更完整、更真正有用的指标项目。

政府。 一家联邦机构对商业工程分析平台的最初评估发现,没有任何可用的供应商能满足该机构的数据主权要求,那要求所有工程指标数据必须留在特定的、经过认证的政府数据中心内。该机构没有完全放弃购买选项,而是识别出了一小撮提供经过政府认证的主权云部署选项的供应商,代价是相对标准商业定价适度的溢价,并成功地部署了一套混合项目:在所需的主权边界内,为大宗商品指标层购买工具,并为该机构具体的公民结果遥测需求自建内部工具,无论主权方面的考量如何,都没有任何可用的商业供应商能满足这种需求。

商业理由:动机、投资回报与总拥有成本

一种刻意的、混合的自建与购买战略的回报,是避免了本主题案例所展示的两种失败模式:为一种市场上已经以低成本存在的大宗商品能力,浪费跨越多年的工程投资,以及把一项真正组织特有的需求硬塞进一个不合适的商业工具所带来的挫折和最终的定制化成本。上面的企业案例具体展示了这一点:混合方法在一年内交付了比全面自建战略在两年内交付的更真实的价值。

无论哪条路径,其总拥有成本都包括常被低估的集成成本,以及,尤其对购买的工具而言,除非事先确认并以合同形式保护数据可移植性,否则潜在供应商锁定所带来的持续风险成本。为这两者都做出现实的预算,而不是只狭隘地聚焦于许可费用或开发工时,能为任何一个选项产出一幅远更准确的总成本图景。

反模式与陷阱

  • 为良好标准化的大宗商品指标构建定制化工具: 重复了许多供应商已经大量投入的工程努力。
  • 在没有先检查契合度的情况下,为真正组织特有的结果遥测购买商业工具: 冒着昂贵、不合适的定制化,或一项未被满足的需求的风险。
  • 在签约供应商之前,没有评估数据导出和可移植性: 冒着只有在尝试离开时才被发现的、持久、昂贵的锁定风险。
  • 在决策的任何一侧低估集成成本: 产生不准确的总成本比较和不切实际的时间表。
  • 直到评估流程的后期才考虑采购、安全或主权限制: 把评估努力浪费在了出于与能力无关的原因结果不可行的选项上。
  • 把这当作一个单一的、全有或全无的决定来对待: 错过了最匹配大多数组织真实、混合需求的混合方法。

成熟度模型

  • 第一级,启动: 工具决策是临时做出的,没有刻意的自建与购买分析,也没有考虑数据可移植性。
  • 第二级,发展: 进行了一些分析,但集成成本经常被低估,混合方法也没有被刻意考虑。
  • 第三级,标准化: 一种刻意的、混合的自建与购买战略,一贯地把大宗商品指标匹配给购买的工具,把组织特有的结果遥测匹配给自建的工具。
  • 第四级,管理: 对所有购买的工具,数据可移植性都被确认并以合同形式加以保护,采购、安全和主权限制被明确、及早地核算。
  • 第五级,协奏: 组织的工具生态反映了一种成熟、刻意的混合战略,随着商业产品和组织需求的演变而定期被审阅,购买和自建的组件都展示出真实的价值。

讨论思路

  1. 我们当前哪些指标,最能从我们目前没有得到的定制化中受益?
  2. 我们是否确认过,如果需要更换供应商,我们能否导出我们完整的历史指标数据?
  3. 我们上一次的工具决策,是否现实地核算了集成成本?
  4. 我们可能低估了哪项采购、安全或主权限制?
  5. 一种刻意的混合战略,对我们具体的指标集而言会是什么样子?

要点回顾

  • 这很少是全有或全无的;大多数成熟的项目把针对大宗商品指标购买的工具,与针对组织特有结果遥测自建的工具结合起来。
  • 为标准化的指标购买(DORA、评审分析、调查基础设施);为真正组织特有的结果测量自建。
  • 在签约供应商之前评估数据所有权和可移植性;锁定是一项持久的风险,而不仅仅是一种不便。
  • 在决策的两侧都为集成成本做出现实的预算;它常常被低估。
  • 采购、安全和主权限制可能凌驾于一次纯粹的成本效益计算之上,对政府组织而言尤其如此。

参考文献与延伸阅读

  • Accelerate: The Science of Lean Software and DevOps,Nicole Forsgren、Jez Humble、Gene Kim著(本主题自建与购买分析所应用的指标家族)。
  • Cloud FinOps,J.R. Storment、Mike Fuller著(适用于工具投资决策的成本分析原则)。
  • FinOps基金会的FinOps框架,finops.org(评估和管理云与SaaS工具成本的从业者指导)。
  • 美国联邦风险与授权管理计划(FedRAMP)文档:关于政府云工具安全和主权要求的权威指导。