自20世纪90年代以来，内部业务应用程序开始从两层的架构模型，转向更为分散的N层架构模型。目的很简单：提取出表现层中复杂的数据层，实现其灵活性。这样做的结果是，不需要对整个程序进行大规模的重新设计，数据模型就能够支持新特性和新业务功能。看到这一优点，设计师们很快意识到他们可以将相同的提取工作应用于业务逻辑，并已经开始将越来越多的逻辑从表现层转移到应用层（图1） 。

 
　　图1：三种不同的分布式解决方案，每一种都建有自己的程序孤岛

　　随后，垂直的业务应用程序孤岛打乱了IT现状。这些程序孤岛通常就是复写业务逻辑和复制数据，从而导致大量冗余事件的普遍出现，给IT企业造成了不必要的负担。

　　为了减轻这种负担，当前的分布式技术（DCOM，RMI-IIOP）被视为一种使复用成为可能的手段。虽然这种技术有时在设计相似的系统下运作良好，但它却无法成为真正适合企业的解决方案。看到因在异构企业之间共享业务逻辑而带来的技术挑战，技术人员对EAI解决方案做出改进，跨越技术所有权和程序所有权限制实现了数据的抽取。

　　大约在20世纪90年代末，开发团队发现互联网标准协议具有互操作性，并开始利用这些协议处理企业解决方案中的问题。许多项目最初采用简单原始的XML（POX）Web服务，随后又采用SOAP Web服务。当时，数据已经遍布于企业内部，单一逻辑的业务实体属性存储于多个系统中。

　　从最初一种发展优质服务的范式，SOA迅速转变成一种从复杂的整合/持久层提取出业务流程层、或从技术模式提取出商业模式的方法。现在，我们看到Web服务所具有的作用，看到后端复杂性的消除，看到服务生命周期管理（SLM）的采用，就能够很好的理解企业SOA现在所具有的涵义。不过，由于开发团队是在整个企业内部创建抽象层，所以他们经常会遇到与数据有关的难题。

　　虽然开发团队通过迅速采用Web服务节约了时间，但是他们却没有时间确定读取或写入的某种属性是否来自正确的记录系统。即使团队清楚的知道从哪里能获得可以采信的数据，但他们还是经常会遇到一些问题，包括存储的整合数据使用的关键字不同、多余的属性彼此不一致。企业组织应当要认识到SOA基础设施的开发是件困难的事情。效益的实现要依赖那些利用该基础设施的后续项目。不过，面临的难题却往往很难描述，而且最终可能会损害SOA项目。但所幸的是，这些难题的解决方案都可以在称为主数据管理（MDM）中找到。

　　MDM是将分布式企业数据规范化、合理化，并且表面上将其集中化。MDM这个名词并不新鲜。自从开发出关系型数据库管理系统（RDBMS），企业组织就曾试图建立一个中央数据储存库。中央数据储存库通过修改现有程序和开发新程序以利用共享数据库，而MDM则允许数据孤岛的存在，而且任何试图彻底消除数据孤岛的尝试都将失败，因为这项工作太复杂，或数据孤岛消除后可能不够灵活。

　　举一个典型的例子

　　假设一个机构中有：

　　·储存在ERP系统中的用户账单信息

　　·储存在自定义LOB程序中的用户订购数据

　　·储存在CRM系统的呼叫中心中的用户交互数据

　　图2：三种与用户有关的数据，分别存储在三种环境中。

　　图2显示重复的数据具有附加属性，支持各系统的特定功能，而最终存储于每一个系统中。而因为相同的数据往往会被不同的名称、或包含不同数据的相同逻辑属性所引用，所以这一情况变得更为复杂。举例来说，ERP Cust.Type领域面向商业用户的代码中可能含有“BUS”，而CRM Customer.AcctType领域面向商业用户的代码中与之相对应的则可能是“Business”。因此，在三个系统中要想找出相同的实体很困难，而且如果主键不同的话还需要人为的干预。在大型系统中，由于拥有许多类似的记录以及很多不同质量的数据，这项任务将变得更加困难。让我们看看你找到的这些记录：

　　·John Smith

　　·Jon Smith

　　·Jonathan Smith

　　·Jon Smyth

　　你可能不仅无法识别相同的实体，而且更有可能在识别相同的实体时出现错误。当一个系统更新时，EAI或ETL进程频繁的同步更新其他系统。在大型IT企业中，这种同步状态可以发展成一种复杂而灵敏的控制体系，以至于业务实体的属性发生的任何改变，对于业务实体本身来讲都将成为一项艰巨的工作。

　　新系统将不断试图寻求用户资料读取的高效率。如果一个交互语音应答（IVR）解决方案正在开发中，比如说，为了查看订单状态和帐户余额，那么它就需要访问储存在ERP和LOB程序中的数据。但是，呼叫中心的顾问却想知道是否正是因为来电者一直在使用IVR，而导致无法完成期望的开发工作。

　　这一系统的开发人员会问这些问题：

　　·哪一个系统才是记录系统？

　　·如果没有一个明确的记录系统，我们是否应该立即更新所有系统？

　　·如果立即更新所有系统，那么在分布式事务处理中，我们应当怎样做？

　　·这将如何影响系统的可用性？

　　·这将如何影响系统的性能？

　　在LOB系统中，在哪里可以找到用户数据？

　　服务层的作用就是为服务面向的用户消除这种复杂性。然而，对于服务供应商来说，企业数据层的复杂性需要进一步得到重视。不仅服务供应商需要排除整合过程中的障碍，而且企业也必须要相信执行的逻辑是正确的，返回的数据也是正确的。  

　　因此，要提供可信赖的服务就需要采用新的技术，可以立即应用现有的概念、技术及进程。举例来说，在用户数据中，在系统之间会重复使用帐户余额，这很常见。然而，在大多数情况下，公司只相信一个系统中的帐户余额数据。因此，如果开发人员已准备进入到另一个系统中，服务面向的用户间则可能会显示不一致的数据。当这种情况发生在项目中时，整合开发的效率无论怎么提高，都会被企业主要求的数据映射过程抵消掉。

　　而当SOA继续与创建复杂、异构、分布式IT环境的技术决策者们交流思想时，有效管理数据的能力才是提供可靠服务的根本。

　　主数据

　　主数据的建立是首要目标。其目的是建立一个高质量的数据存储，储存已汇总、映射、规范化和标准化的企业信息。通常，我们将主数据建立在一个新的数据库中，因为现有的系统状态中命名约定并不理想，而且数据质量可能不高。在某些情况下，系统可能需要具有足够的质量而发挥主数据的作用，而且可能需要添加只有在其他系统中才能找到的属性。

　　数据整合

　　企业信息有机地散布在整个组织结构中。虽然不同的系统拥有相同的核心属性，但是通常都会有独特的属性，支持系统的特定功能。要想真正从企业的角度认识核心业务实体，比如说用户，那么就必须识别出独特的属性列表，并将其储存，如图3所示。 

　　图3：一份扩充的用户属性名单

　　在这种情况下，用户主数据要包括ERP、LOB和CRM系统中的共同属性，以及每个系统中各自独特的属性，如帐户余额、帐户信用额度上限、电子邮件、上次交易日期、交易原因等。

　　数据映射

　　人们经常发现，如果不主动对数据进行管理，数据就会独立的发生变化，导致表名称和列名称不同，以及命名惯例异类。数据映射的任务之一是识别出哪些列代表所有系统中相同的实体属性。一个原始的例子是surname, last name和family name它们都指代相同的信息。

　　数据规范化

　　不同的系统必然具有不同的数据质量，彼此互不同步。主数据应代表the single point of truth单点的真相，必须可以信赖。数据的规范化使得电话号码、社会安全号码及邮政编码具有一致的格式。同时也对地址进行有效性验证，并按照邮政标准统一其格式。

　　数据标准化

　　经过适当的映射和规范化过程后，数据元素在整个系统环境中仍然可能未保持一致，状态代码的管理方式也可能不同。举例来说，交易日期可以在系统中完成映射，并且格式一致，但代表的是不同的时区。（日期和时间应该根据格林威治标准时间标准化，同样，状态代码也需要标准化）。

　　主数据应该能提供一个关于业务实体的聚合视图。而且要注意，有一些属性只针对某一特定系统，这些属性并不一定包含于主数据中，因此也不需要将其纳入数据清理和数据移动过程。 

　　这不仅会产生用户数据的聚合视图，而且也能通过规范电话号码格式、验证地址有效性、按格林威治标准时间规范时间格式等提高数据的质量。既然主数据已经确定，下一个目标就是确定拓扑结构和合并策略。

　　确定拓扑结构

　　主数据及组成系统的可用性和性能特点，将在很大程度上影响拓扑结构。有一点很重要：参与的系统可以直接使用主数据表；或者主数据表可能只是作为企业的数据中心，而因此应该是透明的，可为现有的系统所调用。中央拓扑模型是最简单的结构，因为它只需要主数据的一个复本。

　　图4：集中式拓扑模型

　　分布式拓扑模型能够将主数据的本地副本部署到每一个组成系统中。这种方法能够分散主数据承担的负荷，而修改后可直接获取主数据的系统，由于要存储本地数据其负荷则可能会增加。

　　图5：分布式（分散）拓扑模型

　　对于分散模型，人们普遍关心的是主数据的多个副本所需的存储量。为了解决这个问题，可以将每个系统设计成只订阅主数据的某一个子集，从而仅涉及与该子集有关的程序。

　　确定合并模型

　　在主数据管理解决方案的实施过程中，对于其长远的成功和维护工作来讲，一个有效（或无效）的合并模型所造成的影响至为重要。

　　确定合并模型时易犯的两个常见错误：

　　1．认为所选择的拓扑结构应该要能推动合并模型。

　　2．认为编写工作应该要始终面向中心主数据存储。

　　举例来说，部署分布式主数据并不一定意味着每个系统都能更新各自的本地数据副本。但是，在某些情况中，要求对主数据进行本地更新，并要求将该更新传递给所有参与的系统。

　　所有这一切都需要从识别可更新的节点开始。可更新的节点可以只有一个，也可以包括所有参与的节点。如果只有一个可更新的节点，则该节点可以是参与节点中的任何一个。
 
　　让我们来看一看节点的选择：

　　可更新的单节点——中心主数据

　　只要有可能，服务就应该直接面向主数据进行读取和编写，但这不可能总是可行。如果选择这一种节点，参与的系统可来去自由，而只受到很少的干扰或根本不受到干扰。而因为数据的良好结构，服务的开发效率也能得到提高。

　　图6：可更新的单节点/中央主数据模型

　　可更新的单节点——本地主数据

　　这种方法常用于那些经过修正而能使用本地主数据的关键程序。一个典型的例子是呼叫中心代理所使用的用于进行调整的结算系统。利用本地主数据可以提高性能，而且企业可能只会信任程序中的业务逻辑来完成更新。

　　图7：可更新的单节点/本地主数据模型

　　可更新的单节点——本地数据

　　这一方法常用于那些没有经过修正的程序，以及通过ETL过程与主数据明显参与的程序。它通常与使用本地主数据作为可更新的单节点的情况类似。

　　图8：可更新的单节点/本地数据模型

　　可更新的多节点

　　当存在潜在的合并冲突，而该冲突必须以手动方式解决时，一般在合并过程中使用这种方法进行描述。虽然合并冲突可能会发生，但是此方法只需要对参与系统做出最少程度的改进。

　　图9：可更新的多节点模型

　　在与本地主数据（或不是单个或多个更新节点）有关的任何情况下，主数据作为一个枢纽，保持各参与系统的同步状态，并储存整合后的、规范化的、标准化的数据。这些系统虽然可使用相同的技术移动数据，但是没有这个必要。CRM系统可以利用商务智能（BI）中的技术，并使用ETL工具。ERP系统可利用行之有效的方法转移FTP文件。较新的LOB程序可能会收到更新通知，就像在BizTalk等EAI工具中发生的一样。与大多数架构的确定情况相似，选择的方法将取决于独特的程序、可用的工具及队伍的技术能力。

　　EDW的考虑

　　强大的主数据也将简化企业级数据仓库（EDW）的工作，因为EDW从主数据中加载的数据，可以自身实现数据汇总、数据规范化和标准化。虽然EDW和MDM解决方案提供了一个业务实体的企业视图，利用了许多相同的概念和技术，但是，与MDM解决方案相关的模型却是事务型的而不是空间型。

　　结论

　　面向服务因为其能消除可操作界面、LOB程序及业务伙伴的后端复杂性而得以迅速的应用。应用Service Fa?ade模式可以实现运行和维护过程所需的后端优化。MDM是该优化过程中的一个辅助技术。通过后端优化，能够轻松实现对现有服务的维护，并使其运行更为出色；同时能够轻松实现对新服务的开发，并可避免费时长久的数据映射过程，使其成为业务可信赖的服务。