业务术语表的概念
业务术语表有时候称为数据词典,它们定义与业务相关的术语和数据。根据业务的范围和类型不同,业务术语表的范围也不一样。它们的范围可以是一个小范围(产品或业务线)、一个信息领域或整个企业。最理想的情况是在整个企业的上下文中定义业务术语,这会促使业务术语在所有项目之间保持一致。
但是,不同的部门或业务线常常对同一术语有不同的语义上下文。例如,对于配送部门,“地址” 元素可能是指送货地址。但是,对于财务部门,它可能是指邮寄帐单的地址。对于销售和市场推广部门,它可能是指联系地址。这是一个非常简单的示例。使用名称前缀或者使用三个不同的地址字段,很容易解决这个问题。但是,需要有办法记录和识别要处理的地址的类型以及它们各自的含义。
业务术语表定义业务的语言和项目的语言。因此,业务术语表中定义的术语必须完全符合要求,并提供特定的描述性定义。应该尽可能提供应用于整个企业范围的定义。如果不同的部门以不同方式使用同一术语,那么应该捕捉这些定义并与适当的上下文(部门)相关联。
在构建企业范围的业务术语表时,可以同时包含术语的语义定义和表示定义。语义定义(semantic definition)主要为每个术语提供精确的含义。表示定义(Representational definition)主要定义在 IT 系统中如何表示每个术语,比如整数、字符串或日期格式(参考数据类型)。业务术语表是为组织创建精确的语义和表示定义这一过程中的一个步骤。
在任何 SOA 或数据集成项目中,业务术语表都要捕捉在任何探索活动(比如过程分解、重用分析或对现有资产的分析)中出现的术语。术语可以与过程活动和业务目标相关,也可以只由确定的单个源的定义组成。
由此产生的术语表模型映射到在各种结构化分析期间出现的工件 —— 业务模型、数据模型、需求模型等等。图 1 显示业务术语表与其他工件之间的关系:
图 1. 业务术语表与其他工件之间的关系

如果组织中还没有术语表,就要考虑构建一个术语表。实际上,无论企业是否有术语表,或者是否有多个分散的术语表,模式是非常相似的。
由谁创建业务术语表?
现在讨论哪些人应该参与创建业务术语表。在一些组织中有业务分析师,他们了解数据的业务定义。在其他组织中,有一些非正式的专家了解数据的信息含义。在许多情况下,公司的大多数数据都缺少正式的定义和相关的依赖性。在越来越多的公司中设立了数据管理员(data steward)这种新职位。他们通常负责创建和维护业务术语表。
在各个组织中,业务术语表的所有者各不相同,甚至在同一组织的不同领域中也不一样。在理想情况下,应该在企业数据/IT 管理结构中定义信息领域及其所有关系,而且这些信息领域和所有权层次结构可以应用于业务术语表。如果还没有这样的管理结构,那么在 SOA 项目期间,很可能由数据架构师担任管理的角色,负责确定长期的所有权策略。强烈建议项目包含或使用管理流程。如果公司中还没有这种流程,那么项目应该实现这种管理流程。
通常,每个信息领域有一位业务分析师或数据管理员,甚至可以采用更细的粒度,比如解决方案涉及的每个操作性数据源、领域或实体。在某些情况下可以由同一个人负责,但是在其他情况下可能涉及来自 LOB 或拥有数据的部门的人员。一个数据源可以有多位数据管理员,每个管理员都精通某个特定领域。甚至一个术语也涉及多位数据管理员。以 “客户类型” 这个术语为例。市场推广或财务领域都有客户,与客户相关的数据集可能由一位来自部门或功能领域的数据管理员负责。在上面的示例中,“地址” 可能需要添加一个限定符或者扩展数据结构,从而识别 “地址” 的类别。数据架构师可以帮助设计符合逻辑的识别 “地址” 类型的方法。这个示例说明在建立这些定义时需要多种技能。如果只让业务分析师负责,那么产生的定义可能无法满足后续阶段中各种活动的需要。
对于任何数据源或数据源的任何部分,必须指定一位适当的主题专家(subject matter expert,SME)担任数据管理员。这个人应该熟悉项目可能涉及的所有业务术语的业务用法。根据数据量和专家知识水平的不同,可以由一个人负责,也可以指定多个人。他们还应该了解(或能够学习)所有这些实体之间的依赖性和关系。
让数据架构师参与这个过程常常非常有帮助,因为他们通常了解数据源的物理约束和结构特性。他们还可以帮助判断数据之间的关系和依赖性。
指定了 SME、业务分析师和数据管理员之后,这些人必须与业务专家充分交流,询问他们对于术语的业务定义的意见,让所有相关人员都认可术语的最终定义。这个任务并不轻松,常常要花费大量时间和精力。项目不但需要获得核心信息需求的定义,而且要在整个企业上下文中定义这些术语。正如前面提到的,业务术语表应该在整个企业范围内就每个数据元素或术语的精确定义取得一致。这样就可以建立一种统一的语言,数据的所有消费者都使用这种语言进行交流。实现这一目标的方法因公司和项目而异。