6.1 定义构建模块

定义构建模块是建立和使用产品分类的首要步骤。可以用这些概念对架构和语言进行建模以描述业务。可以根据实际情况，自由定义合适的构建模块。

本节提供了一些构建模块示例作为起点。这些示例并不能覆盖每个企业的所有场景。应该根据实际需要进行调整、扩充，甚至完全替换。例如，并非所有产品和能力都是数字化的。因此，展示非数字化概念对于设计决策时保持全局观点是有益的。在阅读本节时，请记住，后续章节会对这些概念进行更深入的讨论。

6.1.1 IVS

IVS是一个至关重要的构建模块，因为识别IVS是实现业务快速流动的核心。本书中的价值流指的是开发价值流，即开发团队从识别未满足的用户需求到交付验证解决方案的一系列活动流程（如图6.1所示），例如为产品添加新功能。通常，这会涉及多个环节，如产品发现会议、定义需求、计划制定、编程、审查、测试和部署等。

价值流的性质可以有所不同。例如，通过API提供的价格计算服务、带有API和UI小组件的搜索服务，以及移动应用程序（如果它足够小，可以由一个团队完全负责）。

如图6.2所示，构成一个独立且快速流动的价值流有四个关键特征：

· 与松散耦合的业务子领域或产品其他部分（如前端）对齐

· 由明确的业务目标所驱动

· 由自主的、与价值流相协调的团队负责

· 有与业务子领域对齐的解耦的软件架构，团队可自由变更和部署

当这些条件都得到满足，而且价值流相互之间高度独立时，团队会有动力去实现业务成果，并有权力去设计、实施和交付解决方案，同时几乎不需要依赖团队之外的其他人。本章和后续章节将对此进行更详细的讨论。

6.1.2 领域

价值流永远不会完全独立。组织的力量在于，多个团队的合作能产生出单个团队无法单独提供的高层次能力。因此，需要找出那些为同一高层次业务成果有贡献的价值流，并将它们放在一组，以便相关团队保持一致、共享知识，并尽可能有效地合作，以实现端到端的快速流动，而不仅限于单个价值流内部。

领域是代表一组相关子领域的构建模块，这些子领域涉及相似的领域概念，并共同促成同一高层次目标。因此，价值流根据它们的子领域与业务成果之间的关系被划分到不同的领域中。

图6.3展示了两个领域实例。其中一个是履约领域，由可用性、最后一公里、仓储和物流四个子域所组成。每个子领域都建立了专门的价值流。

在较大的组织中，领域可能会在不同范围内以层次化的方式定义，以便更好地与相关群体对齐并确立更高层次的责任划分。图6.4基于Ruth Malan和Dana Bredemeyer提出的“架构范围层次”（http://mng.bz/yZ1o）展示了这个思路：

· 架构第一范畴/第一范畴领域：单独的子领域、价值流或小集合，由单个团队负责

· 架构第二范畴/第二范畴领域：由多个第一范畴领域组成的集合，需要多个团队来处理复杂性

· 架构第三范畴/第三范畴领域：由多个第二范畴领域组成的集合，需要多个团队来处理多层次的复杂性

组织的规模和领域的复杂性决定范围的数量。有些组织有三个以上范围，如本章后面所展示的Salesforce案例，而有些组织则较少。

在特定的范围内，不同领域的大小和复杂性往往各不相同。图6.4是为了阐释一般概念而做的简化，并非一种理想的万能模型。

6.1.3 产品

识别最优价值流和领域取决于一个重要问题：你想要优化哪些业务成果？回答这个问题需要很多信息（包括倾听和沃德利地图会议）。一个重要的步骤是确定组织的产品，并了解产品提供的业务价值和客户价值。这对于理解如何划分领域边界，以及如何相互配合实现战略性业务成果至关重要。

成功的产品应该既为客户带来价值，也为企业创造收益。理想的产品应满足客户需求、对企业来说能够实现，并且符合战略发展目标。在评估每个产品的业务成果时，牢记这一原则至关重要。例如，提升生产效率和增加销售量是客户价值的例子，而收入增加和数据收集则是企业价值的体现。有些产品是内部使用的，这些内部产品创造的价值包括提高生产效率或降低运营成本。用北极星指标来识别和选择正确的业务结果，在第3章中有所介绍。

产品在大小和复杂性上可能差异极大。它们自然会从小开始，并随着新功能的增加而逐渐变得更加复杂。有些产品小到只需一个或几个团队就能管理，而其他产品则需要几十个甚至更多的团队来管理。因此，产品和范围之间并不存在着一对一的对应关系。单一产品可能完全由单一第二范畴领域内的价值流满足，或者可能横跨多个第三范畴领域，如图6.5所示。

“产品”这个词含义非常模糊。如果你在理解和尝试定义这个词的时候遇到困难，本章节的末尾提供了一个建议的定义供参考。

6.1.4 平台

拥有多个产品的企业经常需要考虑复用和规模经济。当多个产品都使用相同或相似的能力时，可以建立平台来集中管理这些共享的能力。

平台管理是一项需要精心平衡的挑战。一方面，平台具备只需一次构建便可被多次复用的能力，避免了在每个团队的重复劳动，为组织带来成本效益和规模经济。另一方面，当平台不能及时响应所有用户的需求或者不能以用户友好的方式提供所需能力时，那么很容易成为发展的瓶颈。

广而言之，如图6.6所示，存在两种类型的平台（它们在行业中有着各种各样的名称）：

· 领域平台/横向平台提供与业务领域相关的能力，例如共享预订系统。

· 内部开发者平台（Internal Developer Platform，IDP）/内部技术平台（Internal Technology Platform，ITP）提供构建和支持内部产品的能力。

这两种类型的平台对架构现代化都很重要。以下两个行业案例清晰地阐释了不同平台的含义以及在实际应用中的使用情况。

平台的应用范围很广。有些平台仅支持少数产品，而有些平台则可能是企业级的：支持一家企业的所有或多数产品，例如集中化身份认证平台。

行业案例：优步的行程履约平台

优步的行程履约平台（http://mng.bz/M9xD），也称为调度平台，是一个支持多个垂直领域（例如产品、服务和市场）的高价值横向平台的绝佳示例，如图6.7所示。优步将其称为基础性的优步能力，并描述其目的：“履约是‘向客户交付产品或服务的行为或过程’。优步的履约组织开发平台来协调和管理数百万活跃参与者进行中的订单和用户会话的生命周期。”

当优步从单一产品公司转型为多产品公司时，并没有为每个新业务领域单独建立新的履约能力。相反，它将履约能力整合到一个企业级平台上，使所有业务领域都可以直接利用这一平台来降低成本、缩短上市时间，并提高客户和司机的忠诚度。因此，优步的履行平台具有极高的复用率，这在其他平台中并不常见。我们也经常看到，由于每个使用平台的团队都有自己的独特需求，这样平台就变成了组织的瓶颈。复用是一把双刃剑，在构建平台之前应当综合考虑领域、技术和社会因素。

行业案例：NAV的内部技术平台

NAV（Norwegian Labour and Welfare Administration，挪威劳动和福利管理局）是挪威最大的公共机构，其主要任务是协助人们就业，并提供养老、疾病、失业等福利服务。NAV每年大约为250万公民提供服务。在内部，有超过100个团队负责数字化运营。为了帮助这些团队更有效地构建和运营产品，NAV开发了一套IDP（http://mng.bz/am79），如图6.8所示。该平台本身由多个子平台组成，而不是单体系统。示例包括一个基础设施平台（https://nais.io/）、一个数据平台（https://docs.knada.io/）和一个设计系统。

将大型平台分解为多个子平台，这在平台达到一定成熟度和规模的组织中很常见。这也是防止平台成为瓶颈的关键一步，因为这样允许单个团队分别负责平台的某个部分，而不是要求每个团队都了解整个平台。了解整个平台的做法不具备可扩展性，还可能导致员工疲惫不堪。

NAV平台故事的一个关键启示是，尽管平台规模庞大而且性质多样，但它是根据需求开发的。平台并不是一开始就完全规划好，然后作为一个大型的三年项目交付。那种大规模的一揽子平台项目通常风险很高而且成功率很低。NAV平台的另一个关键亮点是，它们把IDP视为产品，把内部员工当作客户，尽量减少团队的认知负担，从而能够更高效地工作。这是构建平台的一个关键方面，被称为“平台即产品”（http://mng.bz/g7N8），这一理念有助于实现快速流动。本书后续部分将更详细地探讨这一点。

6.1.5 产品组和产品组合

对于拥有数万名员工的大型和超大型组织来说，更高层次的复杂性更为显著。在他们的产品分类中，Ross Clanton等人（http://mng.bz/eEdG）提出用“产品组”和“产品组合”这些术语来描述这些更高层次的复杂性。产品组是指为相关业务成果做出贡献或具有交付依赖关系的一系列产品，而产品组合则是指共享某种关联关系的产品组的集合。平台组和平台组合是对应平台的宏观结构概念。尽管现代化可能并不总是导致产品组和产品组合层面的变化，但清晰理解这些概念以及低层次现代化决策如何适配宏观计划是有益的。

6.1.6 行业案例：Salesforce产品分类（2017）

Salesforce是大型组织拥有多个产品组合的典型案例。2017年，我在Salesforce的营销云担任首席工程师。当时，全球大约有三万名员工，然而Salesforce通过自然增长和不断收购一直在不断地扩大。因此，Salesforce拥有庞大、异构的IT资产和跨多个国际地区的各种组织文化。在最高层面，Salesforce分成十多个产品组合，被称为云。例如销售云、服务云、营销云和商务云等。

营销云是一个产品组合，仅在2017年就实现了9.33亿美元的收入（http://mng.bz/p1gR）。营销云拥有自己专职的CTO和CEO，分别向全球CTO和CEO汇报。营销云包括多个产品组，这些产品组通常（但不总是）被称为工作室，例如，社交工作室、移动工作室、电子邮件工作室和广告工作室（如图6.9所示） ^[1] 。

广告工作室产品组包括三款产品：广告活动负责在Facebook和LinkedIn等社交网络上发布广告；广告受众负责根据现有客户发现相似的受众；潜在客户捕获负责将社交网络上的潜在客户信息连接到客户在Salesforce上的账户。客户可以单独购买这些产品，每款产品都有自己的代码库和构建团队。然而，出于多种原因，这些产品被构建为一个产品组。从商业角度来看，它们针对的是相同的客户群体，公司试图将它们打包进B2B合同中。此外，这三款产品的领域知识非常相似，因此让参与其中的人紧密合作也是有意义的。

单独看，每个产品都是由多个团队拥有的多个软件组成的。例如，广告活动包含了多种组件，包括客户界面、创建活动的应用、运行和跟踪活动的应用，以及基于条件配置活动规则的应用。

6.1.7 构建模块备忘清单

本节介绍了几个概念，你可能需要一段时间才能熟悉这些概念以及它们如何组合在一起。图6.10是你可以快速查阅的备忘清单。你也可以在本书的Miro白板上找到一个交互式版本（http://mng.bz/OP2j）。

请记住，这些构建模块只是示例，你可以随意调整或将它们作为灵感的来源，或者可以采用完全不同的构建模块。这个模型并不相试图涵盖所有可能的场景。例如，你可能需要为非软件产品和能力添加构建模块。