Enable javascript in your browser for better experience. Need to know to enable it? Go here.
Data Mesh实践指南:二、组织的运营模式

Data Mesh实践指南:二、组织的运营模式

本文是探索Data Mesh成功落地的关键实践和原则系列文章的第二篇。点击此处可阅读第一篇文章。本文探索的实践经验均源自我们近期为Roche实施Data Mesh的实际项目,但文中所使用各种项目用例和模型均已进行简化,不代表向Roche交付的最终项目成果。

 

在本系列文章的上一篇中,我们介绍了一个包含三个工作流的探索过程。在组织或领域的Data Mesh旅程之初,我们会启动这个探索过程,以便对齐业务、产品和客户成果。本文将探究这三个流中的第一个,介绍为了支持Data Mesh而需要执行的运营模式变革,以及有助于识别和定义这些变革的探索过程。

 

Three-stream discovery process across multiple domains at a major healthcare company. Here the focus is on the operating model stream.
Three-stream discovery process across multiple domains at a major healthcare company. Here the focus is on the operating model stream.

寻求运营模式的变革来支持Data Mesh

 

运营模式探索流的第一步是明确企业和领域的Data Mesh愿景。从战略目标和优先任务开始,领域可以向后推演,确定实现Data Mesh愿景的必要措施、变革和能力,而不是一开始就琢磨整个过程需要什么。

 

在运营模式流中,利益相关者应确定在其加入Data Mesh项目后该付出哪些努力,以及为实现Data Mesh需要如何演讲相关流程和实践。他们将通过这个过程回答以下关键问题:

  • 我们当前的团队结构是否符合Data Mesh原则,是否需要调整?如果需要调整,应如何调整?
  • 如果我们的领域中没有内部数据主管,那么谁可以成为这个主管,负责我们的数据产品?他们是否需要一个固定的团队支持他们吗?
  • 如何确定领域希望探索的优先级较高的Data Mesh用例?目前,哪些用例对我们最有价值?
  • 如何确定与多个领域相关和对多个领域都有价值的优先用例?如何鼓励数据产品共享,确保各产品实现最大的行业价值?
  • 如何进行内部治理?需要设置哪些护栏?如何确保这些护栏不会降低Data Mesh带来的自主性和灵活性?

 

运营模式的基础

 

对于不同Data Mesh的项目,在回答这些问题时,我们都会引导客户基于EDGE运营模式来建立自己的运营模式,具体如下图所示:

Operating model foundation
Operating model foundation
 
  1. 目标/愿景:从公司级别愿景和目标开始,将这些愿景和目标细分为领域级别目标和价值假设。价值假设用于说明可以如何通过分析来支持企业实现业务目标。然后基于上述内容制定具体计划,说明如何验证这些假设。各项计划有一个或多个成功衡量标准。
  2. 领域数据战略:由各个领域决定如何利用平台能力在其领域内构建和维护可互操作的数据产品,以符合全公司的总体数据策略。
  3. 投资组合管理:价值假设根据价值确定优先级。构建或更改数据产品的相应分析活动形成投资组合,并进入产品团队的待办事项。限制“在制品”的数量,杜绝虎头蛇尾,坚持善始善终!
  4. 产品架构:价值转化为可执行“切片”并准备交付。大型工作项目分解为小型“学习驱动式”小件。
  5. 敏捷交付:一种适应性增量交付方法,包含及时频繁的快速反馈回路。
  6. 价值度量:按工作实现的价值而非产出的结果,对工作进行衡量。

 

EDGE模式的构建遵循多种与Data Mesh相同的原则。EDGE和Data Mesh都存在以下特点:

 

  • 强调各个领域团队的自主性:
  • 赋能团队以自己的方式实现目标,不施加固定的交付要求。
  • 提倡同时开发多个用例的“投注”(亦称“价值假设”),以便团队可以在其中一个用例不可行时轻松切换到其他用例。
  • 挑战传统的中心化结构,提出新的治理与战略制定和执行方法。

 

这些相似性使得EDGE模式适用于许多首次采用Data Mesh的组织和领域。如果您使用EDGE运营模式作为出发点,那么您在旅程之初便有了一个严格符合Data Mesh各项原则的模式。这个模式还可确保不同的决策者建立一致的Data Mesh的价值结构,并对跨领域的价值假设确定一致的优先级。

 

关键成果:精益价值树

 

EDGE模式还可以帮助我们在运营模式探索过程实现其中一种最有价值的输出,即在优先级上达成一致。代表和传达这种一致性的成果即精益价值树(LVT)。值得注意的是,在其他方法中这一系列的成果有着不同的称谓;但是,只要符合本文讨论的原则,那些称谓都是可接受的。 

 

LVT分为三层:

 

  • 企业愿景:愿景是指组织或领域希望实现的总体目标,是探索过程的出发点,因为愿景确定了所有Data Mesh工作需要推动领域和组织实现的总体目标。
  • 促进性目标:第二层促进性目标包含若干具体目标,这些目标可以共同推进实现企业的愿景。
  • 假设或投注:第三层对Data Mesh和/或数据产品如何支持实现各项促进性目标提出多个假设。所述假设的提出需要运用设计思维,确保当其中一个假设未实现假设价值时,团队可轻松切换到下一个假设并按预期进度实现各项目标。重要的是应认识到,为了实现总体目标,可能需要进行数据或Data Mesh工作以外的其他努力。关注这些努力有助于提高透明度和改善团队之间的沟通,即使具体的Data Mesh项目并未要求进行这些努力时也应如此。
  • 成功衡量标准:尽管成功衡量标准(MoS)并非LVT中的一层,但我们依然在此将其列了出来。成功衡量标准用于确定那些假设是否实现了预期价值,我们是否在朝着目标实现。衡量成功程度这一步骤很重要,因为它有助于确定阶段性成功指标,而阶段性成功指标可以帮助我们确定应重点关注哪些假设,以及应在何时从一个假设切换到下一个假设。

 

Key artifact: The Lean Value Tree
Key artifact: The Lean Value Tree

在本系列文章中,我们将反复以近期为Roche开展的Data Mesh项目为例,进行全方位剖析。后文的LVT范例是在与Roche的一个商务团队合作探索的过程中制定的,该团队负责加速实现医疗保健成果并推动向患者提供医疗保健产品。为此,他们采取的模式是:PJP(患者旅程合作伙伴)与其相应的HCP(医护人员)合作,由HCP向患者群体提供药物。

 

我们将他们的愿景、目标、价值假设和成功衡量标准绘制成如下所示的LVT:

 

在本系列文章中,我们将反复以近期为Roche开展的Data Mesh项目为例,进行全方位剖析。后文的LVT范例是在与Roche的一个商务团队合作探索的过程中制定的,该团队负责加速实现医疗保健成果并推动向患者提供医疗保健产品。为此,他们采取的模式是:PJP(患者旅程合作伙伴)与其相应的HCP(医护人员)合作,由HCP向患者群体提供药物。

 

我们将他们的愿景、目标、价值假设和成功衡量标准绘制成如下所示的LVT:

 

Lean Value Tree example from a recent data mesh implementation engagement at a major healthcare company
Lean Value Tree example from a recent data mesh implementation engagement at a major healthcare company

关键实践1:确保您的组织准备好去中心化的数据组织方式

 

Data Mesh是去中心化的架构范式。因此,对于围绕中心化结构和组织设计构建的数以百万计的企业而言,这代表了一项重要的演进,需要他们进行精心规划和做出改变。 

 

如果您简单地将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的概念,并希望尽快开始构建他们自己的用例和数据产品。在这种情况下,领导者需要承担什么新角色?Data Mesh中的治理可以是联合的,但各领域中谁将对数据产品和相关决策最终负责?

 

回答这些问题并确定和分配新角色(如有)是到目前为止我们进行的探索工作的一个重要部分。此外,另一项重要工作是提供相应的激励和支持,以确保被指定承担新角色和职责的人员在新角色和职责中获得充分的支持和鼓励。

 

在这个过程中,领域负责人(负责领域业务成果的人员)应将确定的目标和优先事项与其经理和其他领域的同事对齐,确保成果的连贯性。

 

数据产品团队共同对其创建的产品负责,如同软件团队共同对其软件代码负责一样。各数据产品需要指定一个负责人担任团队代表和主要联络人,与利益相关者和其他数据产品团队沟通。他们将负责管理产品路线图和生命周期,并传达期望,促进协作。

 

最后,由数据平台团队利用平台向数据产品团队提供服务。根据平台的范围和规模,一个平台可以有多个提供这些服务的团队。在这种情况下,如同数据产品团队一样,这些团队还将根据完成的成果来评估自身工作。 

 

平台负责人将承担平台的产品管理任务,与团队共同规划平台的演进,从用户处收集反馈信息,并传达计划进行的任何变更。使用多个平台的企业须确保各平台负责人就如何保证互操作性达成一致。对此,我们后续将进行更加详尽的探究。

 

关键实践3:清晰确定治理结构

 

运营模式流的另一个重要输出是清晰的治理结构,如以下示例所示。

 

治理部门和数据产品团队之间的互动

Interaction between governing bodies and data product teams
Interaction between governing bodies and data product teams

这个结构说明了治理部门和数据产品团队应采用的互动方式和他们不同的职责。关键在于,本结构还说明了Data Mesh内的治理如何从自上而下的方法(由单一团队担任“守门人”)转向自下而上的方法(多个领域和跨领域团队就数据产品的管理和连接方式提供意见)。

 

在整个Data Mesh中,我们需要研究三种不同类型的治理:

 

1.项目组合治理:项目组合治理在跨领域层面进行,旨在确保达成公司层面的目标和明确适当的价值假设。在项目组合治理中,特别注重实现达成公司层面目标所需实现的跨领域成果。持续对LVT中的成功衡量标准进行探讨,以了解哪些猜想已经实现,哪些猜想需要调整或替换。领域负责人和管理层代表在这个对话中发挥着积极作用。

 

2.领域治理:在领域层面,产品负责人和领域负责人决定团队将追求实现哪些数据用例,并确保他们打造的是正确的数据产品,以支持和帮助实现总体目标。这些团队对用例进行细分,确定实现总体目标所需的数据产品。大型客户通常会在领域内进行另一轮项目组合治理,以解决工作量问题并进行联合决策。

 

3.技术治理:领域架构师和技术主管就如何构建数据产品和设定领域和产品团队标准达成一致。这些护栏旨在确保数据产品之间的互操作性,同时不限制领域驱动的创新。

 

我们将在本系列的最后一篇文章中更加详细地探究技术治理,详细分析整个Data Mesh的计算和联合治理。

 

成功运营演进的3个原则

 

  • 首先明确您想要实现的愿景,再按照精益价值树确定有助于实现愿景的具体假设。
  • 授权团队承担并执行新的职责,确保团队能够根据EDGE运营模式的反馈周期,在证明假设错误后迅速切换到下一个假设。
  • 在采用和实施过程中尽早考虑治理,并将治理纳入接下来的产品和技术决策,而不是围绕您后续创建的内容来构建结构。

 

确定优先级并制定领域的第一个Data Mesh决策

 

完成探索过程的运营模式流后,领域团队就已确定多个高价值Data Mesh用例,并确定了他们希望在Data Mesh旅程之初首先使用的用例优先级。这不仅会实现一个快速、清晰和高价值的旅程开端,还会为未来Data Mesh项目和投注建立可重复的决策过程和优先级确定过程。

 

在决定用例和用例成功衡量标准时,团队还定义了第一款消费者数据产品,即适用于跟踪和公布在通过数据获得更多业务价值方面的进度的价值度量。

 

更重要的是,还完成了另一项工作。确定一个领域希望专注的用例时,也为探索活动的产品流提供了有价值的输入,确定了实现用例需要使用哪类数据产品。

 

在下一篇文章中,我们将探究产品流,分析我们制定的流程以确定创建数据产品的优先级顺序,并且确保数据产品严格符合领域和组织战略的流程。