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

　在SOA或数据集成项目中，关键业务术语可能会造成混淆，对其含义进行反复的争论会导致延迟、推迟修改甚至产生错误。本文是 “SOA 设计的信息透视图” 系列的第二篇文章。本文介绍业务术语表的概念，帮助您消除术语方面的误解。了解在SOA中应用业务术语表的价值，学习如何定义和使用它以使同事之间的交流更加清晰。

　　简介

　　在开发面向服务体系结构(SOA)或数据集成项目期间，常常缺少一个定义与过程、服务和数据相关的术语的统一业务术语表。术语含糊不清会使许多数据集成活动更加复杂，为业务术语提供统一的定义对于解决这个问题非常重要。如果 “客户”、“成员” 等术语表达的含义不一致，就无法正确地实现与这些概念相关的服务，甚至无法确保所有相关人员对组成这些概念的数据有一致的理解。对于业务分析师和技术人员来说，对过程、服务和数据(包括语义、结构和数据结构的格式)使用的术语形成一致的理解非常重要。

　　本文讨论 SOA 环境中对业务术语表的需求，讲解如何定义和使用业务术语表。

动机和问题

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

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

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

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

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

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

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

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

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

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

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

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