如何创建业务术语表？

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

    1.收集信息源

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

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

    2.提取业务术语

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

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

    3.构建术语表

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

    4.检验

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

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

    更新业务术语表

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

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

    示例

    下面的示例取自一个以开户（account-opening）过程为中心的业务术语表。根据现有定义的成熟程度不同（例如，在识别阶段的早期，定义可能还不成熟），术语可能有完整的定义和值，也可能不完整。通过各个开发阶段，术语表会随着项目一起成熟。随着对业务术语了解的深入，应该不断更新业务术语表中的信息。

    图 2. 业务术语表示例
 

    结束语

    业务术语表是一个权威性的工件，它控制并定义常用的词汇、术语的语义和相关的分类法。对于数据集成和 SOA 来说，它是一个重要的起点。业务术语表可以确保组织中不同角色的业务人员和 IT 人员对术语的含义有相同的理解，并在 SOA 上下文中用术语组合成可重用的信息结构。如果弄不清楚提供什么信息以及这些信息的含义，就不可能提供可信的信息。