作者 | Kelsey Beyer
自2019年 Thoughtworks 员工 Zhamak Dehghani 首次提出 Data Mesh 概念以来，Thoughtworks 便开始尝试在全球范围内与客户共同实施 Data Mesh。
以下是根据我们的经验总结的十项建议。对于每项建议，我们都指出了在实施过程中观察到的反模式、我们推荐的替代方法及其原因。这些建议将按照组织中的层级顺序从高到低列出。
1.仅靠自下而上是行不通的，应当尽早获得自上而下的支持
一项新技术要获得管理层的支持往往都存在一些挑战。也正因为如此，一些 Data Mesh 的倡导者试图通过“在特定领域实施 Data Mesh、进而构建数据产品”的方式来自下而上地实施 Data Mesh。
然而，我们已经看到，当这些领域和数据产品试图将 Data Mesh 扩展到其他部门时，会遇到一个无法逾越的障碍——其他部门不明就里，对这个整体方法持怀疑态度。
想要以自下而上的方式跨越部门界限，试图改变他们的优先级、资金、角色和责任会非常困难。当有人询问“你是谁，为什么你要告诉我该怎么做？”时，倡导者也会略显尴尬。
平台团队有时也会遇到同样的问题。他们应该是最佳实践的推动者和教练：没有自上而下的支持，他们无法改变数据产品团队的工作方式、团队设置，甚至无法实施统一的数据治理策略。当数据产品团队试图说服非 Data Mesh 团队向他们提供数据访问权限或协助解释数据时，也会遇到类似的障碍。扩展 Data Mesh 需要自上而下的授权，以便在拥有不同优先级和利益相关者之间创造共识和达成一致。
需要自上而下和自下而上的双重支持：愿意从自下而上改变工作方式的团队，以及支持这一变化的高层领导。
2.从运营模式开始
实施 Data Mesh 需要同时在运营模式和技术方面作出改变，但前者常常被搁置，因为它太难撼动了。因此，组织经常尝试采用技术优先的方法来实施 Data Mesh。这种策略虽然能改善技术实践，但通常在第一年内就会失败。这是因为支持 Data Mesh 扩展所需的结构没有得到充分的改变，以适应新的工作方式。
诚然，改变运营模式很难，但这却是不可或缺的。甚至它应该在 Data Mesh 计划的第一天就同步实施。
Data Mesh 不是一个项目，它是一个企业级计划。影响着各团队之间的协作方式，需要彼此配合和支持。因此，高层需要给予高度支持和帮助，以确保组织范围内的一致性。与此同时，它还需要一定程度的变革管理，例如创建各种治理机构，重新定义角色和责任，以及提高组织的技术水平。转型部门可以在此处提供帮助，通过将具有运营模式和技术知识的人聚集在一起，确保组织一致性。
总的来说，运营模式的改变可能令人望而生畏，但它是成功在组织内实施 Data Mesh 的基本要素，需要尽早做。
3.以“代表组织领域对象和优化效率及沟通”的方式定义领域
领域所有权是 Data Mesh 中的核心原则。这一点至关重要，因为它确保了 Data Mesh 中的每个数据产品都由组织内该特定领域的专家所拥有。其好处在于，它使得数据产品对于那些可能想要使用它的人来说更加有用——它消除了某些术语在特定数据字段中含义的潜在混淆，并有助于减少不一致性。
换句话说，如果某些内容不够明确，领域所有者最适合进行修正或提供必要的上下文。
当然，这并非没有挑战。定义组织领域的界限以及谁拥有什么，是困难的。这通常是由预先设定的预算和报告线，或潜在的政治暗流所引起的。因此，在一开始，比较容易的方式是沿着现有功能的边界定义领域。随后，随着项目的推进和新信息的浮现，可以进一步对过于复杂的领域界限进行分割，或重新分配领域界限。
更好的做法是，从定义一个领域开始，随着时间的推移作为一个迭代过程向外探索。已经在其运营模式中采用领域驱动设计的组织，在进行这种操作性转变时会更加轻松。
最终，定义领域有多种方式。重要的是这些领域在组织的背景下讲得通，有文档记录，并使沟通和流程更快、更高效。下面是一些可能的例子：
- 沿现有的业务单位或功能划分
- 根据业务成果（如增加利润、提高客户满意度等目标）划分
- 沿价值流（为客户交付价值或成果的举措）划分
- 使用逆康威操作（即根据所需的架构来构建团队，而不是让现有的通信路径和结构来塑造它）
- 采用领域驱动设计
总结而言，领域定义使组织能够识别数据的所有者和专家，并对沟通和协作渠道进行高效地优化。对于每个组织而言都是独特的，尽管第一个领域的定义可能很困难，可以从组织最容易采用的方法开始，在熟悉工作方式和责任后进行持续演变。
4.同步构建运营模式、数据治理和平台
平台将运营模式定义的角色、责任和工作方式以及数据治理定义的策略变为现实。
我们经常看到的一个反模式是，运营模式和数据治理是分开的、孤立的项目，每个项目都定义了一堆文档，这些文档被扔过墙给IT部门去实施。在这里，将“Data Mesh”视为一个产品可能会有所帮助，在其中运营模式、数据治理和平台具有相同的基本目标、假设、计划和待办事项列表。采用这种一体化方法，运营模式和数据治理理念可以通过数据产品进行反复测试和优化，而这些数据产品正是基于平台能力得以实现的。
我们建议首先选择的场景应该将运营模式和数据治理策略定义为需求的一部分。
一个示例需求：
“当数据产品团队创建一个数据产品时，它会自动注册到数据目录中，并附上对其输入端口、输出端口、模式、服务级别协议（SLOs）、领域和领域所有者的描述，以增加组织内数据产品的透明度。”
然后，平台可以实现这样的需求，之后相关的运营模式和数据治理办公室可以监控这种策略在 Data Mesh 生态系统中的影响和性能（以及其性能是否达到了定义的成功度量标准）。
5.尽早建立一个良好的平台
自助式数据平台是 Data Mesh 的四个原则之一，它是关于数据产品能力、领域定义和治理策略决策的技术实现基础。平台以自助服务的方式为数据产品团队提供能力，使他们无需等待平台团队临时创建资源和进行数据集成。
采用 Data Mesh 方法，平台团队不再负责维护和转换数据以供分析师使用，而是负责提供构建数据产品（自包含的可部署包）的能力，数据产品团队可以请求并使用这些能力来维护他们的数据。
这些构建数据产品的能力被称为“架构量子”（如《演进式架构》中所定义）。它们包含了数据产品团队构建其数据产品所需的一切，例如围绕数据接入、存储、分布式计算的数据转换的基础能力，与数据目录工具的集成，数据质量工具中的监控和治理策略。有时，对于不同类型的数据产品会提供多种选择。这些实践和模板使团队能够尽可能轻松地交付数据产品。
由于自助式数据平台是 Data Mesh 的主要推动者，它们需要尽早建立。一个常见的错误是组织在没有基本平台的情况下启动数据产品团队。这些最初的数据产品团队会因为等待平台开发基线能力而陷入僵局数月，这给正在进行中的计划带来了压力。在另一个极端，一些组织花费数年时间试图构建了完美的平台，这需要耗费太长时间，而且维护和运营起来太困难。
正确的做法是介于两者之间：一个“良好的平台”是基于研究数据产品团队实际需要什么而构建的。一个经过充分研究的自助式服务平台在减少创建数据产品时可能发生的摩擦中起着重要作用。
为了避免花太多时间构建完美的平台，我们建议从定义一组核心MVP（最小可行产品）能力开始，这些能力“足够好”，以便让数据产品团队快速移动，为组织提供价值，并继续根据新的数据产品团队和领域的经验进行迭代构建和扩展。
6.在新的 Data Mesh 平台中复用现有技术
在 Data Mesh 的早期阶段，许多客户都会对所需的大量技术和工具感到压力重重。实际上，尽管有些工具可能更适合 Data Mesh 的需求，但最理想的做法是在合理的情况下，利用起已有的技术栈、许可证和专业知识。随后，可以添加自定义层以改善开发人员体验，并使用新工具来填补任何剩余的能力差距。
请注意，“复用现有技术”并不意味着“复用现有的或旧的平台”。现有的或旧的平台可能与 Data Mes h方法不兼容，因为 Data Mesh 需要在构建平台的方式上进行关键的范式转变。此外，复用不符合 Data Mesh 方法的旧平台可能会增加额外的复杂性，提高成本并减慢您的速度。
我们建议首先对现有的技术进行梳理，然后根据 Data Mesh 自助数据平台的需求以及你的数据产品要求，对这些技术进行评估。对于那些符合要求且已足够成熟，可以通过自助服务方式使用的工具（例如，提供了API接口，或者能够为了实现基础设施即代码而声明性地定义资源），应予以保留和再利用。
7.场景先行，小步慢行
如果使用 Data Mesh 的项目失败，其首要原因很可能是它们试图过快地扩展规模。正确的操作是给予组织时间去学习和适应变化。这种初步的耐心最终会带来长期的回报。
我们建议从包含两到三个数据产品的场景开始，这些产品在六个月的时间内涵盖运营模式、产品和技术三个维度。
可以理解的是，一些组织认为这种方法“太保守”了。他们可能想要采取更激进的方法，在开始时同时启动几个场景。我们发现，涉及上述三个维度下的第一个数据产品通常需要六个月的时间来引导。一旦度过这一时期，就需要对数据产品所有者进行培训，并组建一个平台团队，以便开始为平台构建新的能力。还需要新的模板和工作方式，以将组织从集中式转变为分散式模式。还需要建立一个 Data Mesh 治理委员会，并制定一个路线图，以增加额外的领域。
简而言之：不要在学会走路之前开始跑。在旅途中会有很多学习的机会。不要错过它们。
8.审慎选择您的首个场景
确定最初的场景可能会让人感到挑战重重，但重要的是要记住，并没有唯一正确的答案。每个组织都有其独特之处，您所做的决策将取决于您想要优化的内容以及您所在组织的风险承受能力。
例如，一些客户选择了非常紧急且复杂的场景。他们通常渴望解决组织中因效率低下和内部政治斗争而造成的阻碍。其他客户则选择了更为保守的路线，通过选择一个简单、孤立的场景来测试组织对 Data Mesh 的接受度。
与此同时，其他客户选择优化构建多样化的平台能力。一个成熟的 Data Mesh 数据平台提供了批量数据处理、近乎实时数据处理、数据分析、人工智能/机器学习（AI/ML）和数据治理的能力。选择需要这些能力的场景，为并行构建所有平台能力的基础工作设定了优先级。
这种方法的另一个好处是，需要多种能力（例如机器学习和批量处理能力，这是常见的依赖关系）的场景成为首批场景的候选。然而，这种方法需要一个庞大且强大的平台团队，能够处理产品思维和以兼容且可互操作的方式集成能力的复杂性。
在众多方法和优化途径中，我们的建议是，从以下情况中选择最初场景：
- 在组织现有能力范围内可管理
- 与业务目标紧密相关，并有明确的成功度量标准
- 可实现
由于内部政治和过度优化，选择场景很容易让人陷入困境，但通常没有一个完美的场景。需要避免的一个常见错误是“分析瘫痪”：即过度分析导致无法行动。因此，应该为这项工作设定一个时间限制，并从那些“足够好”的用例开始。
9.将数据产品纳入平台和运营模式的治理结构
我们观察到在IT驱动的组织中存在一个反模式，即数据产品团队的加入仅限于在平台上的加入。实际上，将他们纳入运营模式设立的组织流程同样至关重要。
适当地加入运营模式流程中，可以让数据产品团队在各种讨论中拥有代表权，从而影响诸如特性优先级等重要活动。加入过程还包括将他们添加到正确的交流渠道，以确保他们不会错过关于新特性、发布和学习机会的重要信息。
从长远来看，没有加入运营模式的团队可能与更广泛的 Data Mesh 生态系统的原则不一致。这可能导致各方的不满和挫败感。
10.要坚定
在组织内部实施 Data Mesh 时，往往需要随着时间的推移进行重大变革，这些变革会影响到许多人、现有部门以及决策流程。当组织的一部分抵制变化时，这可能会变得困难。
可能会有人认为，快速变化的组织——比如重视实验、对数据访问策略持更宽松态度的初创公司——与更加成熟、集中化、遗留问题更顽固的大型企业组织所面临的问题不同，因此应该区别对待。尽管这种说法有一定道理，但实际情况是，无论组织类型如何，如果想要成功，就必须在实施和资源投入上做出变革的承诺。
我们最成功的 Data Mesh 采纳者已经做到了以下几点：
- 及早获得了相关高层的支持
- 将 Data Mesh 作为组织的一部分，每个人都愿意通过全公司范围的、以数据为先的理念参与 Data Mesh 的实践和思维方式
- 人们愿意投入时间学习新方法并改变他们的流程
- 合适的人迅速被安排到合适的位置，一旦发现缺口就迅速投入资源
- 组织愿意接受并实施一个去中心化的模式
- 组织准备好与领域保持一致（如果他们还没有）
已经下定决心全力以赴的组织，能够更快（且成本更低）地通过 Data Mesh 实现价值。这就是为什么为了变革的效率和成功，需要对 Data Mesh 做出全面承诺的原因。
总结
Data Mesh 可能为您的组织带来创新和积极影响，但前提是组织对正确实施它有坚定的决心和承诺。变革固然充满挑战，但只要采取了恰当的方法和流程，就有可能克服成长的阵痛，最终实现 Data Mesh 的成功。
