下载掌阅APP，畅读海量书库
立即打开
独立价值流（Independent Value Stream，IVS）是构建现代架构的基础。要充分挖掘架构潜力并提高架构现代化改造的投资回报，关键在于构建一个符合BVSSH框架的架构。这一过程从理解“价值流”开始。
在软件开发领域，“价值流”涉及一系列活动，这些活动共同创造新价值，从挖掘用户需求，开发软件新功能，到最终将软件交付给用户，这一过程涵盖了软件开发的全周期。图1.4展示了软件开发价值流的高阶概览（更详细的描述还包括诸如项目启动、代码审查、多环境部署等具体活动）。
图1.4 软件开发价值流的高阶概览
提示
图1.4仅提供了现代产品开发方法概览，并未涵盖所有细节。Melissa Perri、Marty Cagan、Teresa Torres和Jon Cutler等产品开发领域的专家提倡采用持续发现与交付、双轨敏捷等先进方法。这些方法强调在整个开发周期内不断地探索用户需求和交付产品功能，是实现架构现代化的理想途径。我将在第8章中结合自己的亲身经验讨论这些观点和方法。如果你希望进一步了解，强烈建议参考上文提到的产品专家的书籍和相关内容。
独立价值流（Independent Value Stream，IVS）是具有以下关键特性的价值流（如图1.5所示）：
· 领域对齐：IVS致力于为特定的业务子领域创造价值，这个子领域足够简单，以至于一个团队就能够管理，例如定价、订购或搜索等业务子领域。
· 结果导向：IVS的成功评估基于其对业务成果和产品北极星指标（关键性指标）——例如收入和用户参与度——的贡献，而不仅仅是完成一系列预定的需求。这避免了仅以产出为导向的“功能工厂”反模式。
· 团队赋权：每个IVS团队都拥有决策自主权，负责从产品和技术决策到变更部署和开发流程的定义等所有方面。
· 软件解耦：每个IVS软件的开发和部署均可独立进行，不受其他系统或流程的约束。
图1.5 独立价值流的四个关键特性
提示
价值流概念已经存在了几十年，并被应用于多种不同的场景。本书特别聚焦于软件开发过程中的价值流。涉及该过程的团队被称为“流对齐团队”，这个术语源自 Team Topologies 一书，详细讨论将在第11章展开。
IVS的特性之所以重要，是因为它们使BVSSH成为可能。通过清晰定义的领域边界将变化一致的相关领域概念分组，从而减少业务之间的耦合，这对开发新产品功能尤其重要。这样做不仅减少了软件与团队间的依赖，而且还加速了新产品增强特性的交付，减少了阻碍并降低了对协调的需求。
采取结果导向的方法通过形成更好的产品和功能想法提供了更大的价值。这种方法赋予团队一定的目标和自由，让他们在子领域内探索解决方案，而不是简单地把他们视为执行预定义解决方案的“功能工厂”。这样能够激发团队的创造力。正如产品管理专家Marty Cagan所指出的：“只让工程师编码意味着没有充分发挥他们的潜力……工程师是创新的最佳来源。”（www.svpg.com/the-most-important-thing/）
由于团队与特定领域对齐并负责软件，因此有助于实现更高的质量。团队明白他们将对自己的选择负责，自然会希望保持代码健康、可演进和易于支持。安全性也因此得到加强，因为团队会考虑到安全性，而不是仅专注于在特定日期之前完成任务。这两方面都有助于打造更可靠的系统，降低了可能对品牌造成灾难性损害的风险。
上述特点和优势的共同作用使团队成员感到更加快乐，工作起来更有动力。对特定子领域内的业务成果负责，给团队带来了强烈的目标感和自治权。较弱的依赖性进一步提升了团队的自主性，同时减少了因依赖而产生的挫败感，例如遇到阻碍的情况。拥有对技术成果和开发流程的决策权，使团队能够不断改进工作方法，实现技能的精进。在能够每天创造价值的团队中工作是一种非常棒的体验。
提示
这是一个概览章节，旨在简要介绍架构现代化的基本主题及其相互之间的关联。在后续章节中，我们将结合诸如事件风暴、沃德利地图等实用技术和真实的行业案例对每个概念进行更深入的讨论。
需要强调的是，即便团队拥有软件并被授权每天多次部署到生产环境，其价值流仍可能不具备完全的独立性。可能存在高度的变更耦合问题，即一个价值流中的变更可能要求其他价值流进行相应的调整。举个例子，开发一个新的产品功能可能要求三个不同团队的协作，让他们各自负责实现功能的一部分，如图1.6所示。
变更耦合描述了不同价值流之间因逻辑依赖关系而产生的相互影响，这种情况会带来问题，因为它需要各个团队之间进行协调，而协调工作往往是低效的。这种低效主要是由共享程序所引起的，例如制定计划、团队间的优先级冲突，以及集成与测试不同组件等，这些都可能导致项目延期几天甚至几周。因此，在架构现代化过程中，能够可视化显示变更耦合的工具（如CodeScene）变得格外重要。
图1.6 由逻辑依赖所引起的价值流间的变更耦合
明确划分领域边界是降低变更耦合的关键战略之一。这些边界的定义应当是经过深思熟虑的，而不应是随意制定的。事件风暴是一个极好的工具，用于识别和定义松耦合的领域边界。这是一种共创技术，它通过团队之间的合作，沿着时间线清楚地描述业务流程和用户旅程。如图1.7所示，可以基于时间线的不同部分明确划分不同的领域和子领域。
图1.7 利用事件风暴来协同识别领域和子领域
事件风暴是一种包含多个参与者（包括领域专家、软件开发者、产品经理、UX专家，以及其他感兴趣的人员）的协作技术。事件风暴能够提供深刻的洞见，帮助定义高质量的领域边界，并能带来其他多项好处。这种技术特别强调跨学科合作，通过详细勾画业务流程和用户旅程的时间线，可以清楚地将时间线上的不同阶段划分为独立的领域和子领域。
此外，事件风暴揭示了架构现代化的另外一个关键环节：采纳现代实践。为了充分发挥现代架构的潜力，必须采纳共创的方法，汇聚不同领域的专家共同设计和演进架构，这与以往由中央团队的架构师单独制定设计方案，然后由各团队执行的传统做法形成鲜明对比。
提示
本书将通过多个案例研究展示不同行业的组织如何定义其领域和子领域。
尽管领域边界对于实现真正的IVS非常重要，但它们只是整个解决方案的一部分。本书还提供了一种全方位的方法，用于确保在进行架构现代化之前从业务、组织和技术的角度验证领域边界的最优性。图1.8提供了本书所涉及方法的概览。
图1.8 从业务、组织和技术角度验证领域边界
提示
内部开发者平台（Internal Developer Platform，IDP）是实现IVS的另一个重要组成部分。通过提供卓越的开发者体验（Developer eXperience，DX）和“基础设施建设”或“最佳实践路径”等理念显著降低了构建、部署和维护代码的复杂性。这使得专注于业务成果的流对齐团队能够避免被基础设施相关的额外任务或开发难题所困扰。关于内部开发者平台的详细介绍和讨论将第13章中展开。
尽管独立价值流（IVS）构成了基本的构建模块，但“独立”并不意味着完全孤立。经过精心设计的IVS旨在尽可能减少不必要的耦合，然而，价值流之间总是存在着一定程度的相互依赖。对于许多规模较大的产品来说，单一团队难以独立开发完整解决方案，需要多个团队的合作，每个团队负责解决方案的一部分。
仅聚焦于单个价值流可能会导致局部优化，而忽视整体的效能提升，这与追求BVSSH的目标相悖。因此，更合理的方法是将组织视作一个互联的价值流网络。负责各自子领域且共同致力于推进业务成果的众多团队需要进行协作。理解不同领域间的相互关系至关重要，这样就可以根据子领域之间的内在联系把各个团队划分为领域对齐的组织单元，如图1.9所示。
图1.9 根据子领域之间的内在联系把相关价值流分配到不同的领域
随着架构变得越来越复杂，涉及的层级也随之增加。在拥有数千名员工的大型组织中，甚至可能还会出现更高层级的领域划分。特别是在系统复杂性不断上升的背景下，深入理解架构的范围对于进行架构现代化至关重要。
架构现代化的每个决策都应当在适当的层级进行考虑。举例来说，技术决策应在哪个层级做出？是让每个团队自由选择编程语言，还是要求同一领域内的多个团队统一编程语言？抑或这是否应成为整个企业范围内的统一决策？
复用是一个常见且经常引发讨论的话题。例如，团队是应该自行决定是否使用公司内部开发的共享服务（如通知服务），还是这种决策应该由上级做出并由多个团队遵循？
本书介绍一系列原则和实用方法，旨在帮助读者在不同层级设计架构并做出明智的决策。但最关键的是要明确我们的优化目标——这本质上是一项业务决策。通过采用沃德利地图和核心领域图等工具，我们可以获得战略清晰度和一致性，从而做出最有利于业务收益的架构决策。