【IT168 技术文章】

    在 SOA 或数据集成项目中，关键业务术语可能会造成混淆，对其含义进行反复的争论会导致延迟、推迟修改甚至产生错误。本文是 “SOA 设计的信息透视图” 系列的第二篇文章。本文介绍业务术语表的概念，帮助您消除术语方面的误解。了解在 SOA 中应用业务术语表的价值，学习如何定义和使用它以使同事之间的交流更加清晰。

    简介

    在开发面向服务体系结构（SOA）或数据集成项目期间，常常缺少一个定义与过程、服务和数据相关的术语的统一业务术语表。术语含糊不清会使许多数据集成活动更加复杂，为业务术语提供统一的定义对于解决这个问题非常重要。如果 “客户”、“成员” 等术语表达的含义不一致，就无法正确地实现与这些概念相关的服务，甚至无法确保所有相关人员对组成这些概念的数据有一致的理解。对于业务分析师和技术人员来说，对过程、服务和数据（包括语义、结构和数据结构的格式）使用的术语形成一致的理解非常重要。

    本文讨论 SOA 环境中对业务术语表的需求，讲解如何定义和使用业务术语表。

    动机和问题 

    糟糕的是，业务人员和 IT 专家常常对同一术语有不同的解释，甚至在不同的业务线之间也有这种现象。在许多情况下，企业中常常有相似或相同数据元素的多个拷贝，这些拷贝的上下文只在其数据存储库中有效。当把这些元素向外部客户公开时，就会丢失它们的上下文；更糟糕的是，它们甚至可能导致误解或失效。业务术语表的根本价值就在于此。它统一了数据元素的定义，让数据的上下文对于数据的所有消费者都有意义。

    业务术语表不但应该包含数据元素的公认定义，还应该包含与这个元素相关联的任何变体或依赖性。这会帮助驱动概念和逻辑数据模型的定义。最终，这使 SOA 解决方案中的组件和参与者能够获得一致的业务信息定义。

    在某些场景中，一个服务需要从多个信息源获得信息，这些信息源可能包含同名的重复数据元素，数据元素还可能有隐含的定义。这些数据元素的定义或上下文可能差异很大，它们的含义只在自己的数据存储中有意义，很可能只有被相关的程序检索时才有意义。对于这些情况，业务术语表为企业中每个实体提供一个一致的统一的业务定义和依赖性，从而帮助识别和解决这种冲突。当来自不同部门的用户谈到 “客户” 或 “收入” 时，每个人都知道这些术语指的究竟是什么。

    不指定业务术语表可能导致的影响包括：

    *无法掌握业务的基本信息需求
    *由于没有充分理解信息需求，项目的成本增加
    *需要花时间对不清晰或被误解的需求进行调整

    在 SOA 环境中，提供这些统一的业务定义对于顺畅的讨论非常重要，这些讨论不仅针对数据元素的语义，还针对可以跨多个业务领域重用的数据集。例如，多个业务线很容易发现它们都需要通过一个服务访问客户的详细信息。但是，在不同的业务线之间，很难就与客户的业务概念相关的数据元素取得一致。在完成这个任务之后，还有一个难题：确定可重用的客户数据集合由哪些数据元素组成，需要通过后续的服务调用获得哪些辅助元素。如果没有业务术语表，讨论就会陷入到对命名和业务术语的争论中。更糟的是，这些讨论可能根本无法进行下去，因为业务术语缺少精确性就意味着存在分歧。

    对于企业主数据管理（MDM），也有相似的问题。为 MDM 存储库提供信息的多个源系统与多个业务线相似，它们对主数据的语义、结构和集合有不同的解释。如果没有清晰地理解这些数据集的语义差异，就很难把它们映射到单一的主数据存储库。同样，业务术语表可以减少这个上下文中的歧义，这使单一业务定义集可以跨多个源系统。

    在数据联邦和数据整合中也有相似的问题。在这些情况下，需求是相同的：必须理解业务术语中数据的含义，从而确保产生的解决方案能够满足项目原来的业务目标。

    案例研究

    卫生保健行业的一家 IBM 客户遇到了一个很常见的问题：在每次会议上，都要争论谁的数字或报告是正确的。问题并不是这家公司需要一个数据仓库。实际上，他们有若干个数据仓库。但是，这些信息源在生成报告时导致了混乱。例如，执行官无法让不同的业务部门（比如医疗管理部门和销售部门）对健康维护组织（HMO）服务的成员数量取得一致。

    这家公司请 IBM 帮助他们分析这个问题的根源并提出纠正措施。公司使用数据仓库集中存储来自业务系统的数据，但是没有为 “成员” 提供统一的业务定义。对于医疗管理部门，成员是潜在的患者、订户和他们抚养的所有家属。对于销售部门，成员是订户和他们抚养的所有家属（如果订户需要续签合同的话）。已故的订户抚养的家庭成员会从统计中排除。这意味着，虽然医疗管理部门和销售部门的成员统计数量对于一个计划（比如本地 HMO）是相同的，但是对于另一个计划，数量就不一样了。这些差异随年份变化，从来都不相同。这给执行官带来很大困扰，因为他们无法相信报告的可靠性。
 
    统一的业务术语表可以有效地解决这个问题，因为它为术语确定了单一的公认的业务含义。这样，所有报告就可以使用公认的术语，跨各个报告上下文保持一致。

    业务术语表的概念

    业务术语表有时候称为数据词典，它们定义与业务相关的术语和数据。根据业务的范围和类型不同，业务术语表的范围也不一样。它们的范围可以是一个小范围（产品或业务线）、一个信息领域或整个企业。最理想的情况是在整个企业的上下文中定义业务术语，这会促使业务术语在所有项目之间保持一致。

    但是，不同的部门或业务线常常对同一术语有不同的语义上下文。例如，对于配送部门，“地址” 元素可能是指送货地址。但是，对于财务部门，它可能是指邮寄帐单的地址。对于销售和市场推广部门，它可能是指联系地址。这是一个非常简单的示例。使用名称前缀或者使用三个不同的地址字段，很容易解决这个问题。但是，需要有办法记录和识别要处理的地址的类型以及它们各自的含义。