反模式

    反模式一:无控制语义混乱

    由于各种原因，语义互操作性很难实现。之所以出现此情况的原因示例如下:

    1.我们不能简单地“拆除”和更换遗留资产。无论任何时候，组织在创建新的应用或者集成现有应用时，都不可避免地需要对遗留资产进行集成。许多企业的关键业务应用仍然运行的是COBOL或CICS。通过查看COBOLCopybook来确定语义不是一项简单的任务。

    2.由于合并、收购、法律法规、市场竞争和客户需求等各种原因，业务在不断发生变化。信息和应用集成永远不会百分之百的完整。

    3.由于职务、经验和知识基础等方面的差异，人们不可避免地发现很难达成一致。参与者数量越多，就越难达成一致。EDM涉及各种业务单位和开发团队。人们发现采用竖井(Silo)方式构建应用和数据比较容易，而在多个团队参加的情况下则很难达成一致。

    4.有些情况下，人们似乎表面上对某件事达成了一致，但是解释方法却各不相同。以采用行业标准的数据模型为例，很多模型十分模糊，而且可以套用不同的语义解释。人们可能将它们用于不同的目的，以此来维护行业标准的作用，而实际上则是违背了标准的初衷。

    5.直接来自于开发人员的普及XML和XSD没有经过协调，因而只会导致语义混乱。

    到目前为止，我们可能显得比较悲观，但是我们真正的主张是对语义混乱加以控制。语义混乱意味着所有人都定义自己的方案和词汇，而不遵守任何信息标准，也不考虑与系统的其他部分之间的语义互操作性。人们使用自己的术语，相互之间难以理解。系统是在竖井中构建的。

    反模式二:目标过大

    无控制语义混乱的另一个反面极端是目标过大。项目涉及许多参与者，而参与者之间很难达成一致。范围过于扩大，时间安排过长。由于计划过于雄心勃勃，强制应用和数据库仅遵从一个数据模型，这在过去造成了很多EDM失败。

    反模式三:缺乏信息集成逻辑重用

    有三种主要的信息集成模式可用于实现语义互操作性:数据联合、数据整合和企业应用集成(EAI)。

    在实际中，企业内不同的部门通常擅长使用其中一种模式。例如，数据仓库和业务智能(BusinessIntelligence，BI)部门通常擅于使用数据整合模式，而业务应用部门则擅长使用EAI模式。如果没有跨团队协调和企业级长期战略，将很容易产生一个新的集成竖井集——业务应用程序组为了实现跨越异类数据源的语义互操作性而进行重复工作，而BI部门却早已经解决了这个数据仓库难题。由于采用了竖井工作方法，每个组的语义集成和数据处理逻辑可能略有不同。

    反模式四:业务术语和定义混乱

    通常情况下，业务用户将请求信息技术专业人员提供数据，以帮助他们利用业务术语和定义对业务进行分析，而这些业务术语和定义在不同的部门可能差别很大。例如，一个部门定义的“客户”可能与另一个部门的定义存在很大的差异。IT专业人员必须将这些业务术语逐一转换成为已知的ER或UML用语。在会计系统中，“客户”可能被定义为组织已经向其销售了产品的对象，而在市场营销系统中，可能被定义为组织想要向其销售产品的对象。这种混乱的核心在于确定使用哪一种“客户”定义。