MDM实际上是现代企业进行日常经营的很重要的基础信息，企业的差点儿全部生产经营活动，都离不开主数据的支持，因此。主数据是最重要的企业信息之中的一个。
可是，针对MDM的管理，尤其是MDM系统的建设，眼下尚未有一套相似SOA參考架构之类的參考模型出来，往往会对准备建设MDM或进行MDM管理的企业或者CIO们，带来一定的困惑，近日查看相关资料发现。Jill Dyche, Evan Levy的主数据层次模型，对此有很重要的借鉴意义。
依据主数据管理实施的复杂程度，參照Jill Dyche, Evan Levy的观点大体能够把主数据管理能够分为六个层次。从低到高反映了主数据管理(MDM)的不同成熟度。以下我们简介一下这六个层次：
Level 0 ：没有实施不论什么主数据管理(MDM)
在Level 0的情况下，意味着企业的各个应用之间没有不论什么的数据共享。整个企业没有数据定义元素存在。比方，一个公司销售很多产品。对这些产品的生产和销售由多个独立的系统来处理，各个系统独立处理产品数据并拥有自己独立的产品列表，各个系统之间不共享产品数据。在Level 0, 每一个独立的应用负责管理和维护自己的重要数据(比方产品列表、客户信息等)。各个系统间不共享这些信息。这些数据是不连通的。
Level 1 ：提供列表
无论公司大还是小，列表管理是我们经常使用的一种方式。在公司内部。会通过手工的方式维护一个逻辑或物理的列表。当各个异构的系统和用户须要某些数据的时候，就能够索取该列表了。对于这个列表的维护。包含数据加入、删除、更新以及冲突处理，都是由各个部门的工作人员通过一系列的讨论和会议进行处理的。业务规则(Business Rules)是用来反映价值的一致性，当业务规则发生改变或者出现相似的情况时，这样高度手工管理的流程easy错误发生。
因为列表管理是通过手工管理的。其列表维护的质量取决于谁參加了变更管理流程。一旦某人缺席，将会影响列表的维护。
Level 2 ：同等訪问(通过接口的方式，各个系统与主数据主机之间直接互联)
MDM Level 2与MDM Level 1相比，引入了对主数据的(自己主动)管理。通过建立数据标准。定义对存储在中央知识库(Central Repository)中具体数据的訪问和共享。为各个系统间共享使用数据提供了严密的支持。
中央知识库(Central Repository)一般会被称为“主数据主机(Master Data Host)”。这个知识库能够是一个数据库或者一个应用系统，通过在线的方式支持数据的訪问和共享。
创建、读取、更新和删除 (CRUD)是处理基本功能的典型编程术语。即便在MDM中。CRUD处理也是基本功能。你的数据库假设只支持CRUD处理并不意味着你实现了MDM。
MDM Level 2引入了“同等訪问”(peer-based access)，也就是说一个应用能够调用还有一个应用来更新或刷新须要的数据。
当CRUD处理规则定义完毕后，MDM Level 2 须要客户或“同等”应用格式化请求(和数据)，以便和MDM知识库保持一致。
MDM知识库提供集中的数据存储和供应(provisioning)。
在这个阶段，规则管理、数据质量和变更管理必须在企业范围内作为附加功能定制构建。
Level 3 ：集中总线处理
与MDM Level 2相比。MDM Level 3打破了各个独立应用的组织边界。使用各个系统都能接受的数据标准统一建立和维护主数据(MDM Level 2的主数据主机上存储的数据还是依照各个系统分开存储的。没有真正的整合在一起)。
集中处理意味着为MDM构建了一个通用的、基于目标构建的平台。大多数公司发现MDM正在挑战他们现有的IT架构：他们拥有太多的独立平台处理主数据。 MDM Level 3 集中数据訪问、控制跨不同应用和系统使用数据。这极大的减少了应用数据訪问的复杂性，大大简化了面向数据规则的管理。使MDM比一个分散环境具有很多其它的功能和特点。
企业主数据面临一致性的挑战。数据在不同的地方存在，数据所代表的含义也是不同的，数据的规则各个系统之间也是不一样的。
集中MDM处理-通过一个公共的平台作为一个总线(HUB)-说明一个共识，从多个系统整合主题域数据。意味着使用集中、标准化的方法转换异构操作数据。无论其在源系统中是什么样子，都会被整合起来。在MDM Level 3。公司对主题域内容採用集中管理方式。这意味着应用系统，作为消费者或使用主数据，拥有一个共识就是数据是主题数据内容的映像，打破了各个独立应用的组织边界。MDM Level 3支持分布主參考数据的存在。
Level 4 ：业务规则和政策支持
一旦数据从多个数据源整合在一起。主题域视图超越单独的应用并表现为一个企业视图，你将获得事实的单一版本号。当事实的单一版本号已经能够提供出来时，来自业务主管和运行人员的必定反应经常是：“证明它”。MDM Level 4能够保证主数据反映一个公司业务规则和流程，并证实其正确性。MDM Level 4通过引入主数据来支持规则，并对MDM总线以及其它外部系统进行完整性检查。因为多数公司相对照较复杂，影响业务数据訪问和操作的规则以及策略 (rules and policies)相对也比較复杂。
假定不论什么一个单一系统能够包含并管理与主參考数据相关的各种类型的规则是不切实际的。
因此，假设一个MDM总线真正打算提供企业范围内数据的精确性。工作流和流程整合的支持是不可缺少的。
Level 5 ：企业数据集中
在MDM Level 5 。总线和相关的主数据被集成到独立的应用中。主数据和应用数据之间没有明显的分隔。
他们是一体的。当主数据记录具体资料被改动后。全部应用的相关数据元素都将被更新。这意味着全部的消费应用和源系统訪问的是同样的数据实例。
这本质上是一个闭环的MDM：全部的应用系统通过统一管理的主数据集成在一起。在这个级别，全部在系统看起来都是事实的同一个版本号。操作应用系统和MDM内容是同步的。所以当变更发生时。操作应用系统都将更新。在那些熟悉的MDM架构风格中。持久总线架构，当一个总线更新全部的操作应用系统将体现这样的变更，形成改变的直接操作视图。在注冊环境中，当数据数据更新时，总线将通过Web服务连接相关系统应用事务更新。因此，MDM Level 5提供一个集成的。同步的架构，当一个有权限的系统更新一个数据值时，公司内全部的系统将反映这个变更。系统更新完数据值后不要单选其它系统中对应值的更新：MDM将使这样的更新变的透明。
从MDM Level 4到MDM Level 5意味着MDM功能性不是在一个应用内被特殊设计或编码的。这还意味着主数据传播和供应不须要源系统专门的开发或支持。
全部的应用清楚的知道他们并不拥有或控制主数据。他们只使用数据来支持他们自己的功能和流程。因为MDM总线和支持的IT基础架构。全部的应用能够訪问主參考数据。一个公司在完毕MDM Level 5后将使他们全部的应用连在一起—既包含操作的也包含分析的—全部訪问主数据是透明的。举例说明，当一个客户更新她的状态—不要管注冊该变更的系统—数据变更将被广播到全部的应用平台(因此一致起来)。MDM Level 5是把数据概念作为一种service来实现。MDM Level 5保证了一个一致的主数据主题域企业映像。定义“客户”和其它应用接受客户主数据业务规则变化实际上是一回事。MDM Level 5移走了主数据的最后一个障碍：统一採用数据定义、授权使用和变更传播。