在SOA或数据集成项目中，关键业务术语可能会造成混淆，对其含义进行反复的争论会导致延迟、推迟修改甚至产生错误。本文是 “SOA 设计的信息透视图” 系列的第二篇文章。本文介绍业务术语表的概念，帮助您消除术语方面的误解。了解在SOA中应用业务术语表的价值，学习如何定义和使用它以使同事之间的交流更加清晰。
简介
在开发面向服务体系结构（SOA）或数据集成项目期间，常常缺少一个定义与过程、服务和数据相关的术语的统一业务术语表。术语含糊不清会使许多数据集成活动更加复杂，为业务术语提供统一的定义对于解决这个问题非常重要。如果 “客户”、“成员” 等术语表达的含义不一致，就无法正确地实现与这些概念相关的服务，甚至无法确保所有相关人员对组成这些概念的数据有一致的理解。对于业务分析师和技术人员来说，对过程、服务和数据（包括语义、结构和数据结构的格式）使用的术语形成一致的理解非常重要。
本文讨论 SOA 环境中对业务术语表的需求，讲解如何定义和使用业务术语表。
动机和问题
糟糕的是，业务人员和 IT 专家常常对同一术语有不同的解释，甚至在不同的业务线之间也有这种现象。在许多情况下，企业中常常有相似或相同数据元素的多个拷贝，这些拷贝的上下文只在其数据存储库中有效。当把这些元素向外部客户公开时，就会丢失它们的上下文；更糟糕的是，它们甚至可能导致误解或失效。业务术语表的根本价值就在于此。它统一了数据元素的定义，让数据的上下文对于数据的所有消费者都有意义。
业务术语表不但应该包含数据元素的公认定义，还应该包含与这个元素相关联的任何变体或依赖性。这会帮助驱动概念和逻辑数据模型的定义。最终，这使 SOA 解决方案中的组件和参与者能够获得一致的业务信息定义。
在某些场景中，一个服务需要从多个信息源获得信息，这些信息源可能包含同名的重复数据元素，数据元素还可能有隐含的定义。这些数据元素的定义或上下文可能差异很大，它们的含义只在自己的数据存储中有意义，很可能只有被相关的程序检索时才有意义。对于这些情况，业务术语表为企业中每个实体提供一个一致的统一的业务定义和依赖性，从而帮助识别和解决这种冲突。当来自不同部门的用户谈到 “客户” 或 “收入” 时，每个人都知道这些术语指的究竟是什么。
不指定业务术语表可能导致的影响包括：
*无法掌握业务的基本信息需求
*由于没有充分理解信息需求，项目的成本增加
*需要花时间对不清晰或被误解的需求进行调整
在SOA环境中，提供这些统一的业务定义对于顺畅的讨论非常重要，这些讨论不仅针对数据元素的语义，还针对可以跨多个业务领域重用的数据集。例如，多个业务线很容易发现它们都需要通过一个服务访问客户的详细信息。但是，在不同的业务线之间，很难就与客户的业务概念相关的数据元素取得一致。在完成这个任务之后，还有一个难题：确定可重用的客户数据集合由哪些数据元素组成，需要通过后续的服务调用获得哪些辅助元素。如果没有业务术语表，讨论就会陷入到对命名和业务术语的争论中。更糟的是，这些讨论可能根本无法进行下去，因为业务术语缺少精确性就意味着存在分歧。
对于企业主数据管理（MDM），也有相似的问题。为 MDM 存储库提供信息的多个源系统与多个业务线相似，它们对主数据的语义、结构和集合有不同的解释。如果没有清晰地理解这些数据集的语义差异，就很难把它们映射到单一的主数据存储库。同样，业务术语表可以减少这个上下文中的歧义，这使单一业务定义集可以跨多个源系统。
在数据联邦和数据整合中也有相似的问题。在这些情况下，需求是相同的：必须理解业务术语中数据的含义，从而确保产生的解决方案能够满足项目原来的业务目标。
案例研究
卫生保健行业的一家 IBM 客户遇到了一个很常见的问题：在每次会议上，都要争论谁的数字或报告是正确的。问题并不是这家公司需要一个数据仓库。实际上，他们有若干个数据仓库。但是，这些信息源在生成报告时导致了混乱。例如，执行官无法让不同的业务部门（比如医疗管理部门和销售部门）对健康维护组织（HMO）服务的成员数量取得一致。
这家公司请 IBM 帮助他们分析这个问题的根源并提出纠正措施。公司使用数据仓库集中存储来自业务系统的数据，但是没有为 “成员” 提供统一的业务定义。对于医疗管理部门，成员是潜在的患者、订户和他们抚养的所有家属。对于销售部门，成员是订户和他们抚养的所有家属（如果订户需要续签合同的话）。已故的订户抚养的家庭成员会从统计中排除。这意味着，虽然医疗管理部门和销售部门的成员统计数量对于一个计划（比如本地 HMO）是相同的，但是对于另一个计划，数量就不一样了。这些差异随年份变化，从来都不相同。这给执行官带来很大困扰，因为他们无法相信报告的可靠性。
统一的业务术语表可以有效地解决这个问题，因为它为术语确定了单一的公认的业务含义。这样，所有报告就可以使用公认的术语，跨各个报告上下文保持一致。业务术语表的概念
业务术语表有时候称为数据词典，它们定义与业务相关的术语和数据。根据业务的范围和类型不同，业务术语表的范围也不一样。它们的范围可以是一个小范围（产品或业务线）、一个信息领域或整个企业。最理想的情况是在整个企业的上下文中定义业务术语，这会促使业务术语在所有项目之间保持一致。
但是，不同的部门或业务线常常对同一术语有不同的语义上下文。例如，对于配送部门，“地址” 元素可能是指送货地址。但是，对于财务部门，它可能是指邮寄帐单的地址。对于销售和市场推广部门，它可能是指联系地址。这是一个非常简单的示例。使用名称前缀或者使用三个不同的地址字段，很容易解决这个问题。但是，需要有办法记录和识别要处理的地址的类型以及它们各自的含义。
业务术语表定义业务的语言和项目的语言。因此，业务术语表中定义的术语必须完全符合要求，并提供特定的描述性定义。应该尽可能提供应用于整个企业范围的定义。如果不同的部门以不同方式使用同一术语，那么应该捕捉这些定义并与适当的上下文（部门）相关联。
在构建企业范围的业务术语表时，可以同时包含术语的语义定义和表示定义。语义定义（semantic definITion）主要为每个术语提供精确的含义。表示定义（Representational definition）主要定义在 IT 系统中如何表示每个术语，比如整数、字符串或日期格式（参考数据类型）。业务术语表是为组织创建精确的语义和表示定义这一过程中的一个步骤。
在任何 SOA 或数据集成项目中，业务术语表都要捕捉在任何探索活动（比如过程分解、重用分析或对现有资产的分析）中出现的术语。术语可以与过程活动和业务目标相关，也可以只由确定的单个源的定义组成。
由此产生的术语表模型映射到在各种结构化分析期间出现的工件 —— 业务模型、数据模型、需求模型等等。
如果组织中还没有术语表，就要考虑构建一个术语表。实际上，无论企业是否有术语表，或者是否有多个分散的术语表，模式是非常相似的。
由谁创建业务术语表？
现在讨论哪些人应该参与创建业务术语表。在一些组织中有业务分析师，他们了解数据的业务定义。在其他组织中，有一些非正式的专家了解数据的信息含义。在许多情况下，公司的大多数数据都缺少正式的定义和相关的依赖性。在越来越多的公司中设立了数据管理员（data steward）这种新职位。他们通常负责创建和维护业务术语表。
在各个组织中，业务术语表的所有者各不相同，甚至在同一组织的不同领域中也不一样。在理想情况下，应该在企业数据/IT 管理结构中定义信息领域及其所有关系，而且这些信息领域和所有权层次结构可以应用于业务术语表。如果还没有这样的管理结构，那么在 SOA 项目期间，很可能由数据架构师担任管理的角色，负责确定长期的所有权策略。强烈建议项目包含或使用管理流程。如果公司中还没有这种流程，那么项目应该实现这种管理流程。
通常，每个信息领域有一位业务分析师或数据管理员，甚至可以采用更细的粒度，比如解决方案涉及的每个操作性数据源、领域或实体。在某些情况下可以由同一个人负责，但是在其他情况下可能涉及来自 LOB 或拥有数据的部门的人员。一个数据源可以有多位数据管理员，每个管理员都精通某个特定领域。甚至一个术语也涉及多位数据管理员。以 “客户类型” 这个术语为例。市场推广或财务领域都有客户，与客户相关的数据集可能由一位来自部门或功能领域的数据管理员负责。在上面的示例中，“地址” 可能需要添加一个限定符或者扩展数据结构，从而识别 “地址” 的类别。数据架构师可以帮助设计符合逻辑的识别 “地址” 类型的方法。这个示例说明在建立这些定义时需要多种技能。如果只让业务分析师负责，那么产生的定义可能无法满足后续阶段中各种活动的需要。
对于任何数据源或数据源的任何部分，必须指定一位适当的主题专家（subject matter expert，SME）担任数据管理员。这个人应该熟悉项目可能涉及的所有业务术语的业务用法。根据数据量和专家知识水平的不同，可以由一个人负责，也可以指定多个人。他们还应该了解（或能够学习）所有这些实体之间的依赖性和关系。
让数据架构师参与这个过程常常非常有帮助，因为他们通常了解数据源的物理约束和结构特性。他们还可以帮助判断数据之间的关系和依赖性。
指定了 SME、业务分析师和数据管理员之后，这些人必须与业务专家充分交流，询问他们对于术语的业务定义的意见，让所有相关人员都认可术语的最终定义。这个任务并不轻松，常常要花费大量时间和精力。项目不但需要获得核心信息需求的定义，而且要在整个企业上下文中定义这些术语。正如前面提到的，业务术语表应该在整个企业范围内就每个数据元素或术语的精确定义取得一致。这样就可以建立一种统一的语言，数据的所有消费者都使用这种语言进行交流。实现这一目标的方法因公司和项目而异。什么时候应该创建业务术语表？
您必须记住，必须及早创建业务术语表，而且它不只是在早期探索阶段进行的一项活动。可以而且应该尽早考虑业务术语表，甚至在需求收集阶段和项目定义阶段就开始这项活动。业务术语表并不限于现有的数据源或数据库；它还包含用来描述 SOA 中业务过程和服务的所有业务术语的定义。越早开发术语表，就能够越快地为整个项目或企业提供一致的术语定义。
无论项目采用什么开发方法，都应该在初始探索阶段开始创建业务术语表。随着项目的发展，业务术语表应该不断更新和优化。
如何创建业务术语表？
在创建业务术语表时，应该考虑采用以下步骤：
1.收集信息源
术语表中的业务术语可能来自多种来源，例如行业标准或 IBM 的 Industry Models。其他常见来源包括需求文档、现有的数据词典和遗留解决方案。
现有的系统或行业标准可能已经定义了业务术语表。如果已经有术语表，那么可以审查它并把它融入统一业务术语表中。
2.提取业务术语
业务术语表最有价值的方面也是最难实现的方面 —— 业务概念的公认的统一定义。可以通过与主题问题专家进行讨论、举行会议或进行问卷调查来实现这个目标。一个术语使用的范围越广，其含义要取得一致往往就越困难。如果一个术语只在较窄的业务范围内使用，那么 SME 或业务分析师可能已经掌握了公认的定义。如果整个企业都使用一个术语，那么要获得一致的定义就会困难得多；可能需要先收集各种定义，然后与各个 SME 会谈，尝试形成统一的理解和定义。在这种情况下，最初的一个术语常常被分解为多个术语，从而满足所有上下文的需要。但在术语表中这不一定是必须的。不同的人员常常用同一术语表示非常不同的东西 —— 这种情况是由术语模糊性引起的，而后者是因为缺少清晰的业务定义。调查表明，使用同一术语描述多种不同需求的现象很普遍，以术语表形式提供详细的业务定义有助于区分这些需求。
业务术语表比较简单的方面是术语的物理方面，也就是数据类型定义、约束等等。这方面的信息经常被忽略，但是很容易获得。值得注意的是，根据术语的不同，物理结构可能不是必需收集的信息，可以以后在开发数据模型时再确定。即使这些信息是在以后添加的，在业务术语表中维护这些信息仍然是有意义的。可以手工添加这些信息，也可以使用市场上的自动化信息分析工具。这些工具有助于了解术语的物理性质，对于评估现有信息的质量非常有帮助。
3.构建术语表
维持术语表的完整性和规范化是很重要的。允许术语表有组织地增长可能会导致业务术语出现大量重叠，这会加剧术语方面的混乱，而消除混乱正是术语表的目标。在业务术语表中添加术语时，应该检查术语，判断它们与现有术语的重叠之处，并通过适当的调整避免术语表中出现重复或其他冲突。但是，可以作为公认术语的别名保留这些冲突。在这样做时，应该注明别名的上下文，也就是记录允许使用它的范围。这样，即使某些用户坚持采用他们的局部用法，也不会造成混乱。
4.检验
有许多现象可以表明业务术语表已经接近完整了。例如，术语开始收敛了 —— 跨新领域识别出的新术语越来越少了。第二个迹象是，所有关键的参与人员已经检验了用来构建业务术语定义的数据源的完整性，而且他们的所有术语都已经按照业务概念成功地分类了。业务定义的质量也是一个重要的指标。业务相关人员应该能够确认术语对于业务是有意义的，分类是适当的，并具有适当的上下文。
良好的业务术语表可以为规范化数据建模活动提供有价值的输入，提供在这些模型中创建实体和关系所需的核心定义。尽管业务术语表是规范化数据建模活动的输入，但是一定要认识到，业务术语表并不能替代规范化数据模型。这两者在详细程度、规范化程度和结构方面有显著差异。业务术语表的作用是提供清晰的业务术语。逻辑数据模型在此基础上更进一步，分析数据的详细结构，包括关系、子类型、属性和包含关系。
更新业务术语表
业务术语表并不是编写好之后就不再修改的静态文档。相反，业务术语表是动态的需要反复修改的工件。无论是文档形式的术语表，还是在 WebSphere Business Glossary 等工具中维护的术语表，都是不断修订、逐渐成熟的工件。
从最初的探索阶段直到以后的阶段，术语表越来越成熟，用户也越来越多地引用其中的业务术语。无论这个工件是采用文档形式，还是在一个工具中维护，它们的基本物理结构是不变的。
结束语
业务术语表是一个权威性的工件，它控制并定义常用的词汇、术语的语义和相关的分类法。对于数据集成和 SOA 来说，它是一个重要的起点。业务术语表可以确保组织中不同角色的业务人员和 IT 人员对术语的含义有相同的理解，并在 SOA 上下文中用术语组合成可重用的信息结构。如果弄不清楚提供什么信息以及这些信息的含义，就不可能提供可信的信息。
