动机和问题

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

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

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

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

　　*无法掌握业务的基本信息需求

　　*由于没有充分理解信息需求，项目的成本增加

　　*需要花时间对不清晰或被误解的需求进行调整

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

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

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

　　业务术语表的概念

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

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

　　业务术语表定义业务的语言和项目的语言。因此，业务术语表中定义的术语必须完全符合要求，并提供特定的描述性定义。应该尽可能提供应用于整个企业范围的定义。如果不同的部门以不同方式使用同一术语，那么应该捕捉这些定义并与适当的上下文(部门)相关联。

　　在构建企业范围的业务术语表时，可以同时包含术语的语义定义和表示定义。语义定义(semantic definITion)主要为每个术语提供精确的含义。表示定义(Representational definition)主要定义在 IT 系统中如何表示每个术语，比如整数、字符串或日期格式(参考数据类型)。业务术语表是为组织创建精确的语义和表示定义这一过程中的一个步骤。

　　在任何 SOA 或数据集成项目中，业务术语表都要捕捉在任何探索活动(比如过程分解、重用分析或对现有资产的分析)中出现的术语。术语可以与过程活动和业务目标相关，也可以只由确定的单个源的定义组成。

　　由此产生的术语表模型映射到在各种结构化分析期间出现的工件 —— 业务模型、数据模型、需求模型等等。

　　由谁创建业务术语表?

　　现在讨论哪些人应该参与创建业务术语表。在一些组织中有业务分析师，他们了解数据的业务定义。在其他组织中，有一些非正式的专家了解数据的信息含义。在许多情况下，公司的大多数数据都缺少正式的定义和相关的依赖性。在越来越多的公司中设立了数据管理员(data steward)这种新职位。他们通常负责创建和维护业务术语表。

　　在各个组织中，业务术语表的所有者各不相同，甚至在同一组织的不同领域中也不一样。在理想情况下，应该在企业数据/IT 管理结构中定义信息领域及其所有关系，而且这些信息领域和所有权层次结构可以应用于业务术语表。如果还没有这样的管理结构，那么在 SOA 项目期间，很可能由数据架构师担任管理的角色，负责确定长期的所有权策略。强烈建议项目包含或使用管理流程。如果公司中还没有这种流程，那么项目应该实现这种管理流程。

　　通常，每个信息领域有一位业务分析师或数据管理员，甚至可以采用更细的粒度，比如解决方案涉及的每个操作性数据源、领域或实体。在某些情况下可以由同一个人负责，但是在其他情况下可能涉及来自 LOB 或拥有数据的部门的人员。一个数据源可以有多位数据管理员，每个管理员都精通某个特定领域。甚至一个术语也涉及多位数据管理员。以 “客户类型” 这个术语为例。市场推广或财务领域都有客户，与客户相关的数据集可能由一位来自部门或功能领域的数据管理员负责。在上面的示例中，“地址” 可能需要添加一个限定符或者扩展数据结构，从而识别 “地址” 的类别。数据架构师可以帮助设计符合逻辑的识别 “地址” 类型的方法。这个示例说明在建立这些定义时需要多种技能。如果只让业务分析师负责，那么产生的定义可能无法满足后续阶段中各种活动的需要。

　　对于任何数据源或数据源的任何部分，必须指定一位适当的主题专家(subject matter expert，SME)担任数据管理员。这个人应该熟悉项目可能涉及的所有业务术语的业务用法。根据数据量和专家知识水平的不同，可以由一个人负责，也可以指定多个人。他们还应该了解(或能够学习)所有这些实体之间的依赖性和关系。

　　让数据架构师参与这个过程常常非常有帮助，因为他们通常了解数据源的物理约束和结构特性。他们还可以帮助判断数据之间的关系和依赖性。

　　指定了 SME、业务分析师和数据管理员之后，这些人必须与业务专家充分交流，询问他们对于术语的业务定义的意见，让所有相关人员都认可术语的最终定义。这个任务并不轻松，常常要花费大量时间和精力。项目不但需要获得核心信息需求的定义，而且要在整个企业上下文中定义这些术语。正如前面提到的，业务术语表应该在整个企业范围内就每个数据元素或术语的精确定义取得一致。这样就可以建立一种统一的语言，数据的所有消费者都使用这种语言进行交流。实现这一目标的方法因公司和项目而异。

　　什么时候应该创建业务术语表?

　　您必须记住，必须及早创建业务术语表，而且它不只是在早期探索阶段进行的一项活动。可以而且应该尽早考虑业务术语表，甚至在需求收集阶段和项目定义阶段就开始这项活动。业务术语表并不限于现有的数据源或数据库;它还包含用来描述 SOA 中业务过程和服务的所有业务术语的定义。越早开发术语表，就能够越快地为整个项目或企业提供一致的术语定义。

　　无论项目采用什么开发方法，都应该在初始探索阶段开始创建业务术语表。随着项目的发展，业务术语表应该不断更新和优化。

　　如何创建业务术语表?

　　在创建业务术语表时，应该考虑采用以下步骤：

　　1.收集信息源

　　现有的系统或行业标准可能已经定义了业务术语表。如果已经有术语表，那么可以审查它并把它融入统一业务术语表中。

　　2.提取业务术语

　　业务术语表最有价值的方面也是最难实现的方面 —— 业务概念的公认的统一定义。可以通过与主题问题专家进行讨论、举行会议或进行问卷调查来实现这个目标。一个术语使用的范围越广，其含义要取得一致往往就越困难。如果一个术语只在较窄的业务范围内使用，那么 SME 或业务分析师可能已经掌握了公认的定义。如果整个企业都使用一个术语，那么要获得一致的定义就会困难得多;可能需要先收集各种定义，然后与各个 SME 会谈，尝试形成统一的理解和定义。在这种情况下，最初的一个术语常常被分解为多个术语，从而满足所有上下文的需要。但在术语表中这不一定是必须的。不同的人员常常用同一术语表示非常不同的东西 —— 这种情况是由术语模糊性引起的，而后者是因为缺少清晰的业务定义。调查表明，使用同一术语描述多种不同需求的现象很普遍，以术语表形式提供详细的业务定义有助于区分这些需求。

　　3.构建术语表

　　维持术语表的完整性和规范化是很重要的。允许术语表有组织地增长可能会导致业务术语出现大量重叠，这会加剧术语方面的混乱，而消除混乱正是术语表的目标。在业务术语表中添加术语时，应该检查术语，判断它们与现有术语的重叠之处，并通过适当的调整避免术语表中出现重复或其他冲突。但是，可以作为公认术语的别名保留这些冲突。在这样做时，应该注明别名的上下文，也就是记录允许使用它的范围。这样，即使某些用户坚持采用他们的局部用法，也不会造成混乱。

　　4.检验

　　有许多现象可以表明业务术语表已经接近完整了。例如，术语开始收敛了 —— 跨新领域识别出的新术语越来越少了。第二个迹象是，所有关键的参与人员已经检验了用来构建业务术语定义的数据源的完整性，而且他们的所有术语都已经按照业务概念成功地分类了。业务定义的质量也是一个重要的指标。业务相关人员应该能够确认术语对于业务是有意义的，分类是适当的，并具有适当的上下文。

　　良好的业务术语表可以为规范化数据建模活动提供有价值的输入，提供在这些模型中创建实体和关系所需的核心定义。尽管业务术语表是规范化数据建模活动的输入，但是一定要认识到，业务术语表并不能替代规范化数据模型。这两者在详细程度、规范化程度和结构方面有显著差异。业务术语表的作用是提供清晰的业务术语。逻辑数据模型在此基础上更进一步，分析数据的详细结构，包括关系、子类型、属性和包含关系。

　　更新业务术语表

　　业务术语表并不是编写好之后就不再修改的静态文档。相反，业务术语表是动态的需要反复修改的工件。无论是文档形式的术语表，还是在 WebSphere Business Glossary 等工具中维护的术语表，都是不断修订、逐渐成熟的工件。

　　从最初的探索阶段直到以后的阶段，术语表越来越成熟，用户也越来越多地引用其中的业务术语。无论这个工件是采用文档形式，还是在一个工具中维护，它们的基本物理结构是不变的。

　　出处：赛迪网