为 OTN 撰稿 为 Oracle 技术网撰写技术文章，获得报酬的同时可提升技术技能。 了解更多信息

密切关注 OTN 架构师社区

MDM 和 SOA：注意！

作者：Jürgen Kress、Berthold Maier、Hajo Normann、Danilo Schmeidel、Guido Schmutz、Bernd Trops、Clemens Utschig-Utschig、Torsten Winterberg

行业 SOA 文章系列的一部分

2013 年 12 月

简介

“如果您没有 SOA 可以利用的企业信息，那么投资 SOA 等于浪费”。 — Gartner

Gartner, Inc. 的这段话非常生动地描述了面向服务的架构 (SOA) 与主数据管理 (MDM) 之间的关系。SOA 的基本原理是组件重用和灵活地使用这些组件来支持新功能或新流程。MDM 提供通用组件（或服务）以确保数据维护和分发的一致性。在这一点上，SOA 的架构理念和原理与 MDM 不谋而合。

本文首先简要描述使用 MDM 的动机，并提出构想。随后将介绍可能的 MDM 架构概念的典型变体，并阐明 MDM 和 SOA 在架构模式上的相互作用。

动机

越来越大的竞争压力意味着业务模式和基本业务流程必须在更短的周期内做出适应性改变。与此同时，公司全球化和数字网络化使得与外部业务合作伙伴的交互变得更加复杂。安全地交换高质量数据对于提高流程效率至关重要。这就是信息的质量及其交易、评估和报告安全等核心问题的所在。如果公司不再能够一如既往地集中了解其业务对象，那么在公司范围内实施主数据管理策略将是明智之举。

遗憾的是，在今天的许多公司中，IT 系统普遍无法跟上组织、业务，甚至技术的快速变化。因此，对公司而言，一个巨大的、不断增长的具有已知集成问题的 IT 系统网络正在“应运而生”。如果所使用的主数据在以下方面存在差异，那么这种异质性将带来很多挑战：

• 主数据的数据格式和结构
• 参与组织单元中主数据值的规格和理解
• 验证和可靠性（数据质量）
• 有关数据主权的流程和责任（数据治理）
• 与应用程序系统的功能部分冲突的业务流程
• 有不同系统需要进行主数据维护的组织单元。

这些问题的结果是基本业务对象（主数据）信息的不一致性。我们说过，数据是所有流程的基本输入。如果这一信息来源枯竭或基于数据的交互成本过高，那么信息的价值可能要打个问号，公司也将面临严重的问题。业务层面的 MDM 和 IT 层面的 SOA 方法可以共同解决这一问题。

BARC 的分析师断言：“超过半数的 IT 专家认为数据质量 … 是最大挑战”。BARC 接着说“75% 的参与者认为主数据管理是其公司最重要的趋势”[REF-1]。

概念化

在 IT 语言的常规使用中，对于主数据及其对公司和相关 IT 系统的重要性有一个基本的共识。主数据是公司及其业务流程中所有业务活动的基础。主数据描述了公司的基本业务对象，因此应被视为公司的“虚拟资本”[REF-2]。在第七届斯图加特软件工程论坛上，Dieter Spath 教授在其演讲中表示，应将信息、主数据视作像公司设备一样的资产，并对其实施资产管理 [REF-3]。

MDM 的作用是组织如何处理公司实施其业务流程所需的主数据。

关于主数据和主数据管理，文献中有广泛的定义 [REF-4] [REF-5] [REF 6]。本文使用以下定义：

• 主数据管理 — 主数据管理 (MDM) 是旨在确保主数据质量的管理活动。其目的是保证主数据对象适用于公司所有增值流程。MDM 包括所有必要的操作和控制流程，这些流程包含质量保证定义，并保证对主数据对象实施维护和管理。此外，MDM 还提供 IT 组件来映射这个过程。因此，MDM 起着支撑作用，并以隐含的方式从两个方向帮助提高附加值。首先是数据质量管理不断提高主数据的数据质量，从而提升信息的价值；其次是主数据对象对所有核心流程的适用性，从而通过优化的核心流程提高附加值。
• 主数据对象 — 主数据对象是正式的基本业务对象，在公司内的增值流程中使用。主数据对象描述结构（蓝图）和质量要求（如结构中的验证、允许值）。它们与用户交互，通常将参考数据（值列表）理解为公司的实际主数据。一个典型的例子是标准化的值列表，如 ISO 国家/地区代码和 ISO 货币代码。主数据使用这些列表作为分组、分层和分类的基础。在本文中，主数据不是唯一的参考列表，但都是正式的基本业务对象。

过程

MDM 根据定义在公司范围内实施。为此，公司就主数据的使用变更，重新评估业务流程和 IT 系统。此外，通过管理系统监视 MDM 本身的计划和项目。最后，MDM 的战略嵌入常规的公司战略中，有助于间接提高附加值。MDM 及其可持续运作的采用是一次业务转型 [REF-7]。

因此，MDM 不是 IT 项目，而是企业的发展规划。IT 为此业务转型提供了基础架构，并在 MDM 发展规划中起着一定的作用，但应通过业务进行控制和启动。

一般情况下，参考框架用于构建和传达复杂的相互关系。这里提供的参考框架对 MDM 发展规划的基本要素加以组织，随后作为过程的框架。以下解释基于业务工程，即圣加伦大学信息管理学院开发的一种用于根据 IT 系统的战略性使用来设计业务转型的方法 [REF-8]。

在其参考框架内，业务工程考虑了三个层面：战略、组织和系统架构（数据和应用程序）。必须设计这些领域才能总体上成功执行业务转型，同时还需要将这些领域纳入 MDM 发展规划的计划和性能框架（图 1）[REF-9]。

图 1：MDM 发展规划的参考框架。

MDM 战略

大多数情况下，可利用制定愿景和战略的方法来传达和控制存在组织变化的中期或长期发展规划。MDM 团队为 MDM 的组织和管理创建总体概念或愿景。该概念传达 MDM 的目的，解释变更的原因，概括目标，并描述其使用准则。必须确保 MDM 概念不与既定的公司目标相矛盾。

抽象层的操作化通过根据该愿景制定包含 MDM 计划的战略来实现。策略指定活动的领域，反映了具体决策者的愿望和理想。战略与愿景息息相关，描述了对未来的期望。最后，作为 MDM 战略的一部分，制定发展路线图和里程碑，并为随之而来的变更管理定义计划。

MDM 组织

MDM 发展规划是一个涉及整个公司的主题。MDM 活动、流程、功能和结构必须跨公司的不同业务领域进行协调。为此，MDM 需要一个管理系统、流程和结构组织来可持续地保证它的成功。功能架构中定义的 MDM 要求是设计流程、结构组织和必要 IT 支持的基础。MDM 管理系统将 MDM 战略的发展规划操作化。它确定建立 MDM 的出发点，定义流程和组织，并将关键数据的分配与流程进行匹配。

核心是对现有流程组织做适应性改变，以符合用作 MDM 一部分的要求。与主数据关联的标准和参数必须整合到公司例行的运营工作周期。一方面，这会影响核心运营流程及其活动，这些活动是用户直线职能或角色的一部分。另一方面，必须实施 MDM 特定的管理流程和数据治理来保障运营能力，同时确保主数据使用方式的不断改善。

适当的结构组织是流程的基础。在结构组织中，员工根据在流程中的角色按层次结构分布。可能按原始的直线职能，也可能按业务汇报关系，如矩阵组织。职能架构对 MDM 的业务要求加以组织，是架构决策和对必要 MDM 流程和 IT 组件进行规划的基础。

MDM 系统架构

作为业务转型，MDM 追求的目标是在公司范围内实施主数据管理。要在合理的运营成本下实现这个目标，IT 必须支持这个过程。一方面，这适用于 MDM 本身的手动支持流程，另一方面适用于数据处理和分发的自动化流程。

为此，有必要建立一个清晰的、包括系统相互依赖关系的系统架构。MDM 的系统架构描述目前的形势和计划的目标架构。如果遵循企业架构方法 [REF-10]，以下结果对 MDM 发展规划非常有意义：

• 针对 MDM 发展规划的 IT 总体规划，以基础架构为重点
• 包含数据模型和数据存储的主数据规划
• 跨公司信息流（价值和商品的流动）概述
• 运营流程（影响 MDM 发展规划和支持 MDM 所需的 IT 应用程序系统）的流程规划

设计领域包括包含必要的 MDM 特定系统的应用程序架构、对 IT 组件的支持、主数据物流的集成架构和基础系统架构。检查应用程序系统和候选 MDM 以确保它们提供相应的功能，同时用相应的标准对其进行评估。应用程序和集成组件基于与基础设施架构相互独立的基础架构平台。信息架构对 MDM 有着特殊意义。除了跨公司信息流（价值和商品的流动）以外，信息架构还描述了主数据对象、关联及其属性。

MDM 数据和元数据的重要性意味着必须将数据视为框架内一个固定的设计领域 [REF-11]。信息架构模型还支持其他设计领域：

• 在战略层面定义主数据对象的主题和要考虑的域。
• 信息模型在组织层面描述组织关系。运营流程使用主数据对象及其属性来定义这些依赖关系。此外，信息模型还记录用于验证主数据及其质量标准的规则。在组织方面，主数据段的组织能力或责任对于 DQM 是必要的。
• 在系统架构层面，信息模型描述作为主数据对象的基础的物理数据模型。它们连同集成架构包括数据转换和分发流程的说明。

同时，MDM 发展规划以计划的形式组织和执行代表了最佳实践方法：

“因此，取得成功的最大挑战不是技术，而是组织。主要是因为应将 MDM 视为一个计划，而不是一个项目或应用程序”[REF-12]。

因此，本文只讨论系统架构和使用 SOA 与 MDM 的技术问题。

SOA 和 MDM

SOA 的一个重要优点是 IT 组件的松散耦合。这有利于组件重用，并且组件可以更轻松、更灵活地支持新功能或新流程 [REF-13]。

MDM 应基于面向服务的概念，并提供通用组件（或服务）以实现数据维护和主数据检索的一致性。在这里，SOA 架构理念再次与 MDM 不谋而合。这一论断支持了两个不同的观点：

• MDM 业务服务 — 用于维护和验证主数据的可重用业务逻辑

   

• MDM 信息服务 — 业务流程中使用的可重用信息

   

MDM 业务服务

公司各个领域都需要访问主数据对象（如产品、客户或业务合作伙伴），因此这种访问是跨职能和管理领域的。“它们可重用性高，易用性强，有利于实现标准化，这意味着对主数据对象的访问创建了理想的候选服务。”[REF-7 14]。

SOA 共济会团队也持这个观点，其将对主数据对象的访问视为“业务实体服务”，并强调在以 SOA 开发的服务中，主数据服务占据相当大一部分 [REF 11 15]。

这里还可以发现一个趋势：

“将发现的主数据服务绑定到独立的应用程序域中是应用程序架构的发展方向。今后，为访问全局主数据对象提供服务的中央主数据系统将在应用程序架构中发挥更重要的作用”[REF-16]。

图 2 演示了主数据管理从不受控到受控的转变：

图 2：向受控主数据管理的转变。

这使得 MDM 成为 SOA 的一个基本组成部分。公司建立 SOA 可增加中央主数据服务的使用频率，从而间接提高其重用性。因此，下一步无疑是建立用于访问和处理数据的中央托管服务。

将服务分解后会发现，还需要负责执行中央任务的服务（可重用服务的一部分）来跨服务域进行主数据的生命周期管理。

在这种情况下，在访问级别也会遇到管理和维护主数据的典型困难，甚至与 MDM 发展规划全然无关。其中包括：

• 数据保护和数据安全方面的挑战，具体取决于数据在生命周期内所处的阶段
• 主数据质量的标准化检查问题
• 将数据传播到子系统的性能问题。

总之，面向服务的概念通过以下方式助力 MDM：

• 形成 MDM 业务服务以支持 MDM 时，使用 SOA 设计原则（框架和模式）
• 重用现有服务来管理主数据的生命周期
• 在主数据物流的框架内整合和分发主数据时，利用企业服务总线 (ESB) 概念和基础架构实现“推送”方法。

MDM 信息服务

服务分解需要中央主数据服务。它们支持使用更具战略性的辅助方法实现信息即服务 (IaaS) [REF-17]。

图 3 演示它们对 IaaS 的支持：

图 3：MDM 支持 IaaS 方法。

基本思想非常简单。其中使用了将访问委托给 IaaS 的 facade，以便单个应用程序或服务不需要单独实现对数据的访问。这可以视为数据访问的虚拟化，因为在要访问的层上，数据源现在是透明的。这样可以集中控制所需主数据上的典型 CRUD 操作。现在不仅保证了对验证的控制，而且还解决了维护不同应用程序和服务时可能出现的所有一致性问题。

如果将这种方法用作 MDM 的一部分，那么可以通过技术和组织措施管理与“信息即为服务 (IaaS)”方法有关的基本挑战。

对于客户，这意味着：

• 定义 — 主数据及其属性的含义（语义）必须统一实现。这还包括定义的可用性及其唯一性。
• 质量 — 现在可以在“虚拟化”平台上执行数据质量检查，并且对客户完全透明，客户可以更改主数据。IaaS 信息库保存了通用语义和用于验证的规则系统。同时还可以杜绝一致性问题。
• 治理 — 最后一点是 IaaS 服务生命周期管理。通过用于在 SOA 环境中管理服务的既定治理方法，直接可以实现。

在表 1 中，MDM 的中央服务与确定主数据值的八个因素形成鲜明对比：

表 1 — MDM 中央服务与八个因素的对比。

这消除了在管理功能各异、质量下降的不同应用程序中的异构主数据时通常遇到的两个问题：

• 避免了检索不同服务或应用程序的“相同”主数据时可能出现的一致性问题。
• 避免了验证和检查数据时可能出现的一致性问题。

数据存储架构模式

选择用于数据存储的架构类型对 MDM 具有深远影响。存储和管理主数据主要有两种方法 [REF-18]：

• 参考系统 — 具有分散数据存储的中央目录
• 记录系统 — 具有 SPoT 的中央数据存储

SPoT 表示真理的单点性 (Single Point of Truth)，有时也称为“黄金记录”[REF-19]。它归根结底意味着主数据对象的唯一性和有效性。

但在实践中，这两种方法都很少以“单独”的形式出现。而更可能与其他技术相结合使用。在这一点上，如图 4 中所示的系统化采用了三种不同的数据存储方法：

• 集中化 — MDM 具有中央数据库或中央业务应用程序
• 注册表 — MDM 具有分布式数据和中央目录
• 共存 — MDM 采用混合方法，不同数据源共存

图 4：MDM 的基础架构模式。

集中化

在这种架构模式中，通过一个或多个领先的主数据业务应用程序维护主数据。在这里，作为独立中央应用程序一部分实施的 MDM 解决方案也应理解为管理业务应用程序。全局主数据、主数据质量保证和维护流程通过管理业务应用程序来确定。主数据物流系统将主数据传播到不同的应用程序（大多是本地应用程序）。这样可确保主数据的一致性。

这种方法在实践中普遍采用，允许进行集中控制，从而在公司范围内对主数据进行标准化。数据始终通过一个或多个业务应用程序进行更改，并且数据是相同主数据质量管理或质量保证方法的基础。

文献中经常描述的在一个平台上整合主数据的方法与此方法相对应，而在这种情况下，管理应用程序对应于数据管理流程。主数据模型被统一，因为它是中央主数据模型。这种方法非常适合可以一同约定全局主数据的公司单位。SPoT 通过管理系统或中央数据库来定义。

注册表

这种方法需要不同系统类别和分散实施具有很强的自主性。与基于“倒排列表”原则的数据库系统一样，需要一个包含引用的中央列表（“注册表”）对主数据对象规范进行唯一标识。信息的实际部分（主数据值）分布在不同的系统间。因此，读取主数据意味着每个检索实例具有高网络负载，所以更建议采用提供集中化程度较低的主数据视图的 MDM 方法。

这种方法容易在数据质量管理方面出现中央问题。由于信息在分散系统中管理和存储，因此需要进行分布式治理。这必然增强分布式单位的自主性，减少集中控制。这样一来，只需确保标识属性的一致性，即可在所有封闭系统中实现标准化。

共存

基于注册表的方法有一个弱点，那就是高网络负载。而集中方法的弱点是，通过管理业务应用程序实现功能的集中化。遵循联合原则并允许与现有系统共存的分散方法可以弥补这些弱点。它类似于数据库中复制作业的主/主、主/从关系。

在这种情况下，分布式 MDM 系统中的本地副本也使用主数据分发物流加以提供和协调。副本从而可以“精细地”调整到所需程度。与注册表方法一样，DQM 发生在本地，但具有全局起始点，因为所有相关数据都保存在“中央”主数据库中（类似于整合方法）。

从复制环境已经知晓这一概念的弱点。通过成功握手进行控制以及中断期间的重启点都存在问题。此外，网络集群中的数据安全也无法得到充分保障。在我们看来，这种方法需要对现有基础架构进行大量干预。

使用场景

现在将根据不同的架构模式对 SOA 方法的使用进行考虑，不同使用场景单独讨论。

集中化

对于这一架构方法，SOA 的作用最小。数据通过通常被封装的业务应用程序来管理。此应用程序指示维护主数据的必要流程，并包含用于确保数据质量的例程。数据主要作为 ETL 流程或作为传统和既定的 EAI 方法来分发（表 2）。

表 2 — 集中化架构模式规范。

注册表

对于这一架构方法（表 3），使用 SOA 至关重要。主数据传播在分布式环境中进行，并且通常使用面向事务或数据集的过程来传播更改。要显示信息，需要通过网络激活不同的服务。这些服务从特定业务系统的注册表中读取属于标识数据的信息。随后此数据通过网络回到起始点，其中读取的数据被编译为主数据集。

这就是基于松散耦合的集成过程的优势所在。结构或本地系统主数据版本的每个更改都必须以类似的方式向中央注册表报告。

表 3 — 注册表架构模式规范。

共存

对于这一架构方法，SOA 的使用也非常重要（表 4）。数据存储在分布式系统中，同时也存储在分布式数据存储中。因此，主数据在分布式环境中维护与管理，并且每个系统都要启动主数据物流的传播。复制本身既可以异步进行，也可以同步进行，甚至在实现复制（包括冲突解决）的同时于 SOA 中启用不同的方法（类似于“注册表方法”）。

表 4 — 共存架构模式规范。

总结

总之，关于在没有 MDM 的情况下是否可以追求统一的 SOA 方法，问题依然存在。Andrew White 和 Jon Radcliffe（Gartner，2010 年）认为这是不可能的。他们认为，SOA 项目成功与否取决于 MDM 的使用：

“到 2011 年，在复杂的异构环境中，70% 的 SOA 项目将无法取得预期的业务成果，除非使用 MDM。”

我们就以该论断作为结尾吧。

要点

• 业务部门和 IT 部门共同执行 MDM 举措，由业务部门负责。MDM 工作应视为一个计划，而不是项目。
• 清楚的数据主权定义、数据结构和数据质量所需的维护流程是成功的基础。
• 使用参考架构，使得 MDM 系统的采用和维护更加容易。
• SOA 只有与 MDM 联合，才能得到理想的结果。
• 参考架构应不受所选技术的约束。

参考资料

• [REF-1] BARC：“《Data Warehousing 211 – Status Quo, Herausforderungen und Nutzen》白皮书”，BARC 研究所，第 28 页，Würzburg，2011 年 7 月。第 28 页和第 35 页
• [REF-2] M. Kaufman：“主数据管理”
• [REF-3] D. Spath：“Unternehmensgut：Stammdaten”来自 2011 年斯图加特软件工程论坛会议发言全文，Stuttgart，Frauenhofer 出版社，2011，第 29 页
• [REF-4] A. Berson、L. Dubov：“全球企业的主数据管理和客户数据集成”，McGraw Hill，2007
• [REF-5] A. Dreibelbis、E. Hechler、I. Milman、M. Oberhofer、P. Van Run、D. Wolfson：“企业主数据管理：管理核心信息的 SOA 方法”，2008，IBM Press，第 23 页
• [REF-6] B. Otto：“Funktionsarchitektur für Unternehmensweites Stammdatenmanagement, Bericht Nr.:BE HSG/CC CDQ / 14”，圣加伦大学信息管理研究所，2009
• [REF-7] J. W. Schemm：“Zwischenbetriebliches Stammdatenmanagement”，Springer，2009，第 79 页起
• [REF-8] H. Österle、R. Winter、F. Höning、S. Kurpjuweit、P. Osl：“业务工程：核心-业务-元模型”，来自：“WISU – Das Wirtschaftsstudium”，2007
• REF-9] B. Otto：“Funktionsarchitektur für Unternehmensweites Stammdatenmanagement, Bericht Nr.:BE HSG/CC CDQ / 14”，圣加伦大学信息管理研究所，2009，第 14 页
• [REF-10] Staehler 等：“Enterprise Architecture, BPM und SOA für Business-Analysten”，Hanser，2009
• [REF-11] J. W. Schemm：“Zwischenbetriebliches Stammdatenmanagement”，Springer，2009，第 79 页起
• [REF-12] M. Kaufman：“主数据管理”，第 16 页
• [REF-13] T. Erl：“SOA 设计模式”，Prentice Hall 面向服务计算系列。第 756-757 页
• [REF-14] J. W. Schemm：“Zwischenbetriebliches Stammdatenmanagement”，Springer，2009，第 223 页
• [REF-15] B. Maier、H. Naumann、B. Trops、C. Utschig-Utschig、T. Winterberg：“SOA Spezial Ready for Change”，Software und Support 出版社，2009，第 35 起
• [REF-16] J. W. Schemm：“Zwischenbetriebliches Stammdatenmanagement”，Springer，2009，第 223 页
• [REF-17] Allen Dreibelbis、Eberhard Hechler、Ivan Milman、Martin Oberhofer、Paul Van Run、Dan Wolfson：“企业主数据管理：管理核心信息的 SOA 方法”，2008，IBM Press，第 86 页起
• [REF-18] A. Dreibelbis、E. Hechler、I. Milman、M. Oberhofer、P. Van Run、D. Wolfson：“企业主数据管理：管理核心信息的 SOA 方法”，2008，IBM Press，第 23 页
• [REF-19] M. Kaufman：“主数据管理”