在SOA中应用业务术语表模式的价值

案例研究

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

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

　　统一的业务术语表可以有效地解决这个问题，因为它为术语确定了单一的公认的业务含义。这样，所有报告就可以使用公认的术语，跨各个报告上下文保持一致。

　　业务术语表的概念

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

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

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

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

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

　　由此产生的术语表模型映射到在各种结构化分析期间出现的工件 —— 业务模型、数据模型、需求模型等等。图 1 显示业务术语表与其他工件之间的关系：

图 1. 业务术语表与其他工件之间的关系

　　如果组织中还没有术语表，就要考虑构建一个术语表。实际上，无论企业是否有术语表，或者是否有多个分散的术语表，模式是非常相似的。

　　由谁创建业务术语表？

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

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

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

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

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

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

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

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

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

　　如何创建业务术语表？

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

　　1.收集信息源

　　术语表中的业务术语可能来自多种来源，例如行业标准或 IBM 的 Industry Models。其他常见来源包括需求文档、现有的数据词典和遗留解决方案。

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

　　2.提取业务术语

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

　　业务术语表比较简单的方面是术语的物理方面，也就是数据类型定义、约束等等。这方面的信息经常被忽略，但是很容易获得。值得注意的是，根据术语的不同，物理结构可能不是必需收集的信息，可以以后在开发数据模型时再确定。即使这些信息是在以后添加的，在业务术语表中维护这些信息仍然是有意义的。可以手工添加这些信息，也可以使用市场上的自动化信息分析工具。这些工具有助于了解术语的物理性质，对于评估现有信息的质量非常有帮助。

　　3.构建术语表

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

　　4.检验

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

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

　　更新业务术语表

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

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

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友