现在，一些公司已经开始研究这些中心基准系统进化的下一个阶段。这篇文章将探索移植到更高深的系统中的原因。
在已经存在的中心基准系统中的用户通常分为三个不同的组：
·消费者：使用建立在这些系统的终端用户或者系统来支持他们的工作。
·贡献者：在中心系统中能更新数据的用户或者系统作为他们日常活动的一部分。
·数据管理者：维护数据的完整性以及防止数据遗漏的用户和系统使用的元数据。
这三个组结合的非常协调，它们都和系统有关。
但是，这些系统中的每一个都非常容易和其他的系统断开。那么当这些数据在其他的系统中改变，这些改变不能在所有的系统中复制；或者是延迟复制。这种断开能潜在的导致系统的有效性被破化并可能导致更糟糕的局面——让终端用户根据错误的数据来作出决定。
一个解决方案就是为所有的主系统构造一个单独的主基准系统，这些主系统发布自己的数据，我们可以从这些主数据来收集想要的信息。
一个例子
我们使用一个普通公司来做例子来演示这个方法的好处。就叫这个公司为X，它们已经确定为主数据系统服务的不同类型的数据：
1 ProMan：一个产品管理的工具这个工具可以存储公司销售的信息，并是系统的关键信息比如产品姓名，商标，产品信息文档等等。
2 FormMan：一个明确表达管理工具它存储的信息关于怎么样管理销售并存储关键的信息比如产品的成分和处方，包括每个组件的任何安全文档或者最终产品如何正确安全的使用和存储。
3 GraphMan：一个图形和标志的存储库的存储文件存储了X公司的商标，产品和公司的logos，同时详细的说明在什么时候什么地方使用这些信息，这些图片通常由个人设计师来设计。
4 HRMan：人事管理工具，它列出了所有的雇员以及他们的详细信息等等。
5 LabelMan：产品标签管理工具，它管理标签的创建。
6 PackMan：一个封装管理工具，它管理被X公司产品使用的封装。
现在你了解了吧，它们每一个都是特别的数据。表面上来看，这个公司有良好的管理数据的能力，但是，我们不能确定在FormMan中的每个处方都没有作为X公司当前销售的产品来使用，并可以被ProdMan来管理。同时，如果我们给每个产品贴上标签那也不容易说明我们正在销售。我们怎么添加一个新的产品？最近，这个在每个系统正被双倍的执行尽管是不同的方法。
每个系统都是被分开管理和维护的，因为有按键的错误，我们会有不同的数据；大小写键盘的不同使用方法，间隔等等，或者还有语言上的不同，比如美式英语和英式英语。
我们可以在这些程序中使用一个顺从练习，但是这可能要花费一段很长的时间。在大多数时候，我们已经有了一个公认的主系统因此，我们可以在适当的时候纠正其他的系统，要不是有数据元素，我们就不能这么做，并且我们不能通过其他的方式计算出哪个值是正确的。
和任何公司的大小一样，X公司使用各种电子方法，比如EAI，ETL和EDI在内部移动数据。最近，每个系统的接口可以被构造并且以合适的价格维持个别。同样，系统的任何改变都将给它的接口带来影响。
一道曙光
看这个画面，X公司希望用一个方法来保证所有方面的一致性并可以纠正数据的错误。显然，X公司没有购买一个单独的系统，这个系统可以维持和管理数据所有的需求。创建一个单独的系统对用户的开发时间和再训练有重大意义。
X公司能够做的是窗一个主数据的中心储存库，这个中心储存库能够让没有系统自己的主数据按照正常的间隔返回到自身。这样做可以不移动X公司内的详细目录中系统的任何东西。
在X公司内这个给终端用户提供了一个单独的系统，这个系统可以展示关于产品信息的完全集。这个单独的表述层和公司的corporate-dashboard模版类型数据显示的观念相似，现在它们都非常流行。
下一步就是允许它们使用这个系统来管理数据，并且将它们的变化返回到相关的系统中中。当然，在这种情况下仅仅只有一部分人有权利来更新数据。
X公司现在有了一个单独的系统，这个系统对所有产品的信息提供了一个复合的视图，并且允许按照统一的方法改变系统下面的所有东西。
另外，没有系统现在和其他的会话都经过中心系统；比如，LabelMan将更新的产品X的标签送到中心系统中，在中心系统中ProdMan收集它们并更新关于X产品自己的信息。在技术方面来说，这意味着如果系统下的任何被改变了，需要被检查的仅仅只是它们连接到中心系统。对于X公司来说，这个更简单并且是更值得借鉴的管理方案。
中心系统和系统下的连接可以通过两种方式完成，一种是使用用户代码接口，你可以用任何你喜欢的语言来使用它，一种是技术平台，比如EAI或者ETL，这个就取决于你的应用程序平台了。
没有灵魂的木偶
在这点来说，在X公司里，中心系统仅在一个引用点引用所有主数据的时候才起作用。系统本身不能创建任何数据；它只简单的合成了数据的看法，这些数据存储在系统和可以更新数据的方法中。
但是，在添加一个新产品的时候，当它出现在中心系统时X公司依然需要手动添加这个产品到没有系统中，并且每个系统都有自身的一套用户接口和命名约定。
如果X公司决定更新它的中心系统以便允许它可以创建新的产品，在一个完整的形式中，在用户被返回到中心系统之前，这些模版骨架可以被适当的系统下的用户进程。为了促进它并确保每个人都知道哪个记录是哪个，X公司需要为它的产品引进一种新的命名约定，ID可以通过中心系统产生，ID可以直接指向这个数据。
新的改进
当X公司正在进行的IT计划，所有的系统都要更新。既然现在中心系统在适当的位置，每个系统不再需要存储它自己的主数据集作为自己的元数据，但是，它可以从中心系统中生动的负载它。另外，这些系统的一些功能性可以从系统的根本移动到中心系统。在某些例子中，在一段时间后甚至可以将整个程序移动。
利用密匙管理X公司的产品现在可以经过中心系统完成，先前由ProdMan完成的关键功能现在在那个系统中不再被使用，也许扩展ProdMan现在变得很多余了。
X公司如何获利？
X公司的IT计划受益匪浅，因为它可以加速执行和结合新系统。每个新工具仅仅和自身的功能性和特殊数据相关，这些数据可以从中心系统装载支持物。
X公司商业获益因为它有所有数据的正确的数据用来帮助决定和计划。X公司同样可以可以给它的用户和提供者提供超值服务。
更新各种信息，比如用户地址或者产品名字，现在只用在中心系统中更新一次，这比在没有程序中更新一次好的多，因为后者有很大的风险。
令人头痛的事情
直到系统从中心系统拿走主数据，没有系统都会发出数据和管理的结构。比如，如果ProdMan仅仅允许一个产品被分类相反的层次，那个层次的任何改变都必须在中心系统里并且在任何数据包含新层之前ProdMan已经被传递。
当我们试图同时保持所有的系统时，那意味着没有任何使用层的产品可以被传递到系统下直到它们准备就绪后。这极有可能导致改变的执行。
当没有系统连接到中心系统，一个完备分析将被执行来确定系统内的数据，什么字段需要从中心系统导出，什么字段需要导入，什么影响这些数据。一旦连接被执行，从中心系统继承的字段不再被被那个系统编辑。用户需要被重新告知系统怎样工作。
揭开真实的面纱
中心系统的组建是什么？至今我们看到了在普通用户接口中的各种数据元素的复合显示，这些接口被X公司的雇员管理和查看。我们也了解了一系列的接口，通过这些接口，数据可以从中心系统入栈，确保系统持续更新，但是，在这个层之下是什么呢？
中心系统有两个主要的组建：
1 核心
中心系统的核心由下面几个部分组成：
·中心系统的主数据，存储所有的接受信息，将这些信息作为自身的数据和字段。
·一个单独的用户接口——大概基于Web——通过这个接口用户可以查看和管理数据。
·一个接口管理，这个可以检查系统下面和中心系统的交互效应。
2 虚拟
它包含了系统和存储库。这个的用户接口将反映了核心。这些包含了改变控制工作流或者X公司产品使用的图片的储存库。
这两个元素组成形成了我提到的一个观点——MDMS，看下面的例图。
怎样管理
被给定了中心系统纯粹的作用域和大小，它几乎不可能由一个人来管理这个项目。但是，仔细了解这个组建后我们发现它允许我们定义三个工作方面：
·技术：负责发展，基础设施和网络等等。
·数据管理：负责管理主数据，比如公司数据建筑师。
·进程管理：负责过程控制端，包括连接。
联合这三项，我想你已经是一个高级经理人员来援助计划和整个项目的管理。某些时候，你可以谨慎的分派其他项目经理和开发者工作任务并通过核心词群来管理他们。
探索的道路永远那么漫长崎岖
虚拟中心系统的观念在理论上是非常棒的，但是，在执行的时候却非常复杂。系统的数量需要被综合到里面，商业进程的数量也需要被它采纳，IT和商业观点必须的改变对于项目来说是非常重大的。所有，这条路非常漫长。
我认识的一位项目经理描叙MDMS好像潘多拉的宝盒，因为它随时会有好的建议。一旦你打开它，就不会停止。商业和IT界的很多人最初只看到了MDMS最终结果的好处，但是没有看到获得这个方法的痛苦之处。
这就是为什么计划是如此重要。为了获得象这样的最后结果，就要花费很长的时间；因此，认真计划是非常重要的，同时你要利用商业界来解决一些棘手的问题。