企业中高度分散的数据接口和数据模型早就该进行有效的集成了。在实施SOA的过程中，这是无法跨越的必要环节。为了享受SOA的诸多效益，企业数据需要时刻预备着！
Carlson Hotels Worldwide公司的IT经理John Kolodziejczyk指出：“首先需要解决的问题是：‘我们将使用什么样的数据库作为客户的信息来源？’”为此，这家餐饮企业为其所有的应用设计了一种通用数据架构和一个治理该架构的平台。同样，轴承制造商GGB公司的IT经理Matthias Kenngott认为，GGB需要一个中心集线器确保Oracle电子商务套件与3个老的ERP系统之间一致的数据映射。
如今，大量的企业数据要么深锁在数据库中，要么就被封闭在应用中。通常情况下，应用“知道”数据的含意和处理结果的含意，因此企业至少要在本地创建一个一致性的数据模型。然而，随着企业跨应用组合不同的功能，这些数据模型也被混合在一起，而且经常是在IT开发人员不知道的情况下被混合的。
Starwood Hotels的技术经理Song Park说：“你分发越多的数据，就越可能出现问题。”人们往往会怀疑服务和应用产生结果的准确性。ZapThink高级分析师Ron Schmelzer指出：“对数据而言，始终存在一种上下文关系。甚至当一个字段为空白时，不同应用会对它的含意做出不同的假设。”
而这些问题数据会让集成的应用集合或大量的服务变得不可靠和难于修复。而解决的办法就是以服务的形式提供多种应用需要的数据，即在需要的地方加入上下文元数据，以及调和分散的数据源之间存在的不一致关系。
SOA的训诫
SOA的双重优势是开发执行常用功能的服务以减少多余的开发工作，以及通过利用标准化接口或外壳使应用功能可以跨系统使用，从而增加应用的灵活性。而SOA松耦合的、抽象的本质对于服务使用、处理和生成的数据具有深远意义。
Song Park在Starwood Hotels开始部署SOA时曾发问：“到底是把它分散开还是提供一种中心服务？”这个问题引导这家公司沿着很多企业走向SOA时的必由之路走下去：即用一种基于对数据含意的了解（无论数据来自何方）来处理数据的服务方式。Schmelzer强调：“SOA凸显了数据不一致这一事实。”
当服务交换数据时，发生误搭配和非对应转换的可能性大大增加。Common Sense的DePalma说：“SOA把这个问题推升到了最高层面。”他说，“当你尝试建立第一个3路或4路数据服务，你会很快发觉数据治理之痛。”Hurwitz Group总裁Judith Hurwitz说，没有最初的数据架构努力，SOA就无法扩展到整个企业。
专家称，最佳的解决办法是开发一个数据服务层，它会对将要使用的数据进行分类，将其上下文关系展示给其他服务。这种方法把数据逻辑与业务逻辑分离开来，把数据访问和处理作为由业务流程调用的独立服务集合对待。
新需求催生MDM
这种解决办法不同于传统的数据集成。ZapThink的Schmelzer回忆说：“我们过去一直通过在要害堵点上实施控制来解决数据集成问题。而SOA消除了这些堵点。这意味着每个数据访问点都必须能转换和治理数据。”
IDC集成系统集团的副总裁Henry Morris说：“数据集成和流程集成是紧密连接的。”他建议企业必须考虑利用服务来治理数据，以及影响主数据的流程。
Kanbay国际咨询公司主设计师Nikhil Shah指出，SOA还提出了并行性问题。例如，当旧数据通过流程传播，或者当多个服务在不同时间访问数据时，流程过程中数据的变化就会影响到结果，尤其是在复合型应用中。
Shah建议，IT要部署监测服务，至少部署在发生变更时通知其他服务的服务，以使它们可以决定是重新启动流程，还是调整对它们的计算。
此外，Shah说，数据服务的颗粒度越细，编排（orchestration）的开销对流程的影响就越大，因为它会增加响应时间，导致同步问题。他建议IT在服务能够消费数据前，就建立数据治理需求模型。
为SOA环境中的数据治理提供缓存技术的PRogress 软件公司数据治理副总裁Ken Rugg说，另一个问题是SOA的“雪犁效应”，这种效应发生在服务把有关数据处理的上下文关系传递给复合应用中后续服务的时候。
IDC的Morris说，公布这些转换可以帮助以后的服务了解它们正在使用数据的上下文关系。不过，这也可能使系统被非常庞大的数据文件所沉没，降低每个服务的速度。
SOA的兴起使厂商有理由重新利用他们的工具为SOA和非SOA环境简化数据治理。很多厂商正在推广MDM（主数据治理）工具，来确保应用或服务在正确的上下文关系中使用正确的、当前的数据。“主数据”不仅包含数据本身，而且还包含了供不同系统使用所需要的属性、语义及上下文关系（即元数据）。一些厂商把这类系统称为企业信息集成（EII）工具。
下一步是数据集线器
AMR Research公司研究主管Bill Swanton指出，MDM虽然不是新概念，但它基本上属于事后数据系统，例如数据仓库和业务智能。在SOA出现前，企业基本不用担心主数据问题，因为大多数信息保存在应用套件中，而在应用套件中，厂商至少部署了隐含的、内部的数据架构。所以，IT可以只关注在应用套件之间传送的或原始的数据，通过连接器的建立使应用能够处理大多数的上下文关系。
SOA的多对多架构让IT不能继续把这个问题留给应用厂商和集成渠道。不过Swanton说，现在连非SOA环境也将放弃开发连接器的方法，转而向更易于集成的数据架构迁移。
IBM、Informatica、Oracle和Siperian等公司开始从数据仓库着手解决这一问题，它们提供一个或更多的数据集线器当作可信赖代理，服务从净化的数据存储或由其他应用生成有效数据的服务访问数据集线器。数据集线器类似于传统企业环境中常用的中心辐射架构。
专家警告说，目前这些技术还很不成熟，最多只能对特定的数据治理流程起作用。
很多数据集线器含有一个适用的数据主题，比如客户或产品信息。i2公司MDM业务高级经理Satish Krishnaswamy说，MDM作为一个初始构件还是不错的；但在以后，IT必须普及数据集线器或使用特定的数据集线器联盟。IDC的Morris说，“我们不会总局限在一个数据集线器上，因此IT应当向一个标准、规范、分级、跨不同来源的数据视图的方向努力。”
为使这个系统易于治理，IT部门通常为一个主题领域定义规则和上下文关系，然后逐步扩展到其他领域。决定是从一个特定主题系统，例如SCM中的产品信息入手，还是从一个一般化的系统入手，这取决于对具体应用套件集成工作的关注力度。假如你的关注焦点放在与ERP或SCM的互动上，那么从特定主题的数据中心入手可能是更为合理的选择。反之，假如你的焦点放在服务与不同应用互动的SOA上，那么从一个一般的数据中心入手则更合理。
数据架构的构建
MDM工具的确能够帮上忙，但假如企业不了解自己的数据，那么这类工具就无法发挥作用。EDS公司的Fred Cummins说，由于集中式数据存储一般涉及事后结果，而不涉及状态和交易，因此，MDM系统越来越像传统的数据仓库或主数据库，那么无论是在传统环境还是SOA环境中，它就越不可能满足交易系统的需要。
Cummins说，对SOA来说，单纯重新打包EAI工具的MDM工具没什么太大帮助。这是因为SOA应当受到业务流程的驱动，而EAI一般将重点放在把应用连接在一起，而不关注每种应用基础数据的上下文关系。
从根本上讲，这是个设计问题。正确地设计架构和具体服务需要开发人员了解他们与之互动的服务，以及应用所使用和产生的所有数据，而这是个需要投入大量劳动的过程。这正是为什么IT需要方便地访问数据服务集合或是数据映射的原因。Common Sense的 DePalma说：“到了一定阶段，就必须建立信息库。这不仅对SOA至关重要，在传统环境中也是如此。”
映射建立后，IT就可以将注重力放在开发执行它们的连接或服务上。IT必须了解哪些映射应当提供给多个服务和应用，因此要被当作独立的流程来实现；还有哪些映射是特定业务逻辑所特有的，应当与这个业务逻辑封装在一起。
而由于没有清楚的ROI，许多企业并没有开展数据架构的建设。不过，IT部门可以循序渐进地参与进去，围绕用于满足特定应用或服务需要的信息开发规则和元数据。
BEA总设计师Paul Patrick说，数据架构通常包括多个数据模型，每个模型面向特定的主题或流程类型。IT部门可以采取分段开发的方式，同时需要精确定义数据模型之间所需的映射。
IT部门还要集中精力来应付异常数据。例如，IT应当开发查找异常数据的服务，而不是去尝试开发映射每一种可能的状态或关系企业范围的本体。最后，专家建议，企业应当构建分发主数据的数据服务层，尽管实现这一目标的基础设施和工具目前尚不成熟。
预备行动
在企业中以服务的形式提供数据源是一项宏大的工程。对传统的集成工作而言，这意味着了解每个应用中的上下文关系，以及数据在交付给其他应用时该如何转换。对SOA来说，这需要了解数据与不同的业务流程间的多种关系和依存性。
专家认为解决这种环境的复杂性，需要在建立数据架构模型前进行IT投入，要求企业系统地考虑数据的依存性和上下文关系。IDC的Morris说，发现数据模型和建立映射的工作量占到SOA数据架构开发工作量的70%左右。GGB的Kenngott说，建模与发现的工作量占其ERP整合项目中数据集成工作量的30%左右。
Starwood的Park说，这是非常值得做的预备工作。“否则，你会在实施项目很长时间后才发现有10个不需要的字段、10个需要但在设计服务时不知道的字段，以及5个与设想不一致的字段。当你拥有一个具有数百个服务的复杂系统时，这些接口必须被明确下来。”他说。
