业内人士Kyle Gabhart称，他最近在一项大的SOA应用计划中实施了两个主数据管理计划。在这两个案例中，客户发现他们在如何解决主数据模型与一个或者更多的SOA组件（如业务流程、服务接口等）之间的冲突方面陷入了僵局。每一个客户都从不同的角度接触了这个问题。但是，冲突实际上都是一样的。谁取得了胜利并且按照自己对于企业数据的观点顺利运行？是主数据管理团队，还是SOA团队？另外，企业架构团队也许感到疑惑是主数据管理团队的观点向SOA团队的观点妥协了，还是相反。

　　状况1：客户A决定建立一个权威的数据模型，不依赖于现有的应用程序或者业务流程。这个客户执行一个简单的流程：

　　·建立一个概念的数据模型

　　·识别逻辑子域（数据的逻辑组合）

　　·为这个子域建立一个逻辑数据模型

　　现在，如果出现一个业务流程（如向提供商提出涨工资要求），这个流程就包括访问提供商的数据和这个要求的数据域。客户如何建立这个方案，如何不打破在逻辑的权威模式中建立的关系？替代的方法是，这个客户如何能够把这个方案与基本的权威模型联系起来。为了企业面向服务的观点，主数据模型必须要妥协，或者面向服务的观点必须要修改以便与主数据计划相一致。

　　分析：因此，这里真正的问题是我们已经在真空中创建了一个模型。我们现在面临一个具体的数据应用。这可能会让我们对于数据在企业中如何应用的实际情况有一个新的了解。这里有两个观点：

　　1.我们把这看作是一个修改这个模型并且使这个模型符合真正业务应用的机会。

　　2.我们不理会需要管理的用户/客户的莫名其妙的东西。

　　如果我们根据这个新的信息更新这个模型，我们就会有被一个流程曲解的风险。但是，我们也许会认识到这个流程提出的更广泛的事实。如果我们不改变这个权威的模型，那么，我们或者说服用户接受这个“标准的”模型，或者提出一些数据镜像，这样，业务流程就能够按照他们自己的数据模型执行这些服务。

　　无论采用哪一种方法，面向服务的设计的最佳方法都是规定这个业务流程只能看到一种数据模型。这可以是来自业务应用实例中的一个独特的模型，也可以是以前创建的权威的模型。只要业务流程看到一种数据模型，数据模型的来源没有关系。此外，业务流程比一个企业应用集成工作流好，并且带来了围绕维护客户集成逻辑和巧妙处理不同的数据模型的全部复杂性。这带来了不可接受的维护成本。这是靠不住的，很快将成为过时的和不可靠的。

　　总结

　　有效地应用SOA需要在物理和逻辑层有一个设计良好的数据模型。许多机构甚至要开发一种权威的域模型。主数据管理和SOA的交叉越来越频繁地出现，这种趋势在未来几年将继续下去。