数据架构的构建

　　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个与设想不一致的字段。当你拥有一个具有数百个服务的复杂系统时，这些接口必须被明确下来。”他说。