案例研究 4：Common Customer Master System——IBM 内的单一客户视图
变化点是确定可能发生更改而应该外部化的位置。具有内置变化点的服务组件允许用户通过对这些服务进行配置来满足不同的需求。可以将可扩展性机制加入到 UI、服务组件接口、服务组件本身以及数据模型中，从而实现可配置应用程序。
非常有必要对可配置性 和自定义 进行一下对比。可配置性为我们提供在不更改代码库（编写代码）的情况下使组件适应不同需求的能力。可配置性构建到服务（Switch、Dial 和 Lever）中，可以由应用程序的用户进行调用。相反，自定义要求开发额外的代码（使用编程语言）来扩展和更改软件组件，以支持特定的“自定义”行为。
业务上下文
根据使用的通道（如呼叫中心、Internet 和业务合作伙伴）不同，IBM 有时候会让客户觉得像独立操作的多家公司。客户的体验以及客户组织和联系信息有时候会缺少一致性和连续性。这对客户满意度造成了负面影响。为了处理这个问题，IBM 部署了 Common Customer Master System (CCMS)，这是一个基于 SOA 的解决方案，支持为其客户提供“一个 IBM”的体验。
CCMS 的主要业务目标有：
通过将所有 IBM 客户数据合并到单个系统和关联的存储库中，从而消除存在于 IBM 内的多个客户信息实例以及对应的冗余维护开销。从这些其他分布式客户存储库获得的信息将退出历史舞台，由这个单一的系统予以取代。
通过将组织层次结构合并到客户数据中，从而使得客户信息更有意义、更有用。组织层次结构提供有关不同业务实体彼此如何相关、其地址以及分支机构的业务信息。必须每月对这些层次结构进行更新，并作为 IBM 的组织层次结构数据受信任来源提供。
改进客户数据质量
通过图形用户界面（浏览器）提供直接用户可访问性，从而提高客户信息使用率。
提供服务接口，从而允许服务使用应用程序将这个集中的系统作为 IBM 所有客户信息的单一客户记录创建和客户信息源加以使用。
挑战
问题的范围以及复杂性包括：
集成来自不同数据源的客户数据——包括 Dunn and Bradstreet (D&B)、存储在 Reference Data customer (RDc) 连接点的 IBM 客户数据（代表来自各个 IBM 客户数据库的客户信息）和 CRM/Siebel（具有三个实例，分布在北美、欧洲和亚太地区）。这个集成任务还将处理对来自 D&B、IBM CRM 源和 RDc 的输入间的记录重复进行数据验证和纠正的需求。
使用支持 SOA 的单个功能集同时满足用户和应用程序访问功能
由于需要支持 119 个不同的国家/地区而产生的各种需求
将多个客户数据模型集成到单个逻辑模型的复杂性，此逻辑模型符合 IBM 的标准化业务数据定义，以便支持加载D&B、CRM 和 RDc
将多个异类客户遗留数据源转换为 SOA 支持的内聚解决方案
需要以一致的方式引入能够统一进行实现的新规则，包括：
将每个数据元素从数据源的数据模型映射到新的集中数据模型的业务规则，包括数据质量和可接受的值要求的列表
每个数据源的数据元素的转换规则，这些规则对在 CCMS 中创建和维护数据是非常必要的
所有数据源的数据元素的数据聚合规则，也对在 CCMS 中创建和维护数据非常必要 \
基于 SOA 的解决方案
CCMS 团队首先标识并优化对体系结构非常重要的各种场景，以便将其作为基础来定义所需的服务。 此分析和设计工作也涉及到对使用 WebSphere Business Integration Modeler 创建的流程进行建模，从而标识和协调独立构建的服务的使用。对每个场景进行了分析，以确定服务的非常好的范围和粒度，而这涉及到进行重构来改进服务的分离。对 CCMS 遗留系统进行了研究，以确定可以将哪些现有软件组件“包装”为服务，需要开发哪些新服务来提供这些系统所没有的功能。
使用 IBM Rational XDE 来创建 UML 用例和 IT 构件的对象模型，以供在组件模型的定义中使用。使用 WebSphere Application Developer -- Integration Edition 设计基于工作流的流程，从而以现有服务集合为基础组织新服务。Rational XDE 和 Business Integration Modeler 模型直接输入到 WebSphere Application Developer -- Integration Edition 中，从而用于将其他构件（XML 模式、Java 代码、服务和规则）与 BPEL 工作流相关（后者部署到了 WebSphere Business Integration Server Foundation 上）。
图 2 所示的 Core Transaction Update Service 是基于服务的 CCMS 工作流的一个示例，可供各种更新相关的流程（如 CRM update、RDc update 和 D&B update）使用，以确保一致性、数据质量和消除冗余。这个特定的更新服务包括处理标准化、进行匹配（确定输入记录是否唯一或已经存在）、聚合或持久性的活动。聚合活动实现数据聚合规则，该规则会在更新 CCMS 数据前对要更新的客户数据中每个数据组的数据的来源进行考虑。聚合规则指示更新 CCMS 数据时信任哪个数据源（按数据组确定）。
图 2 还显示了 CRM 更新服务 (CRM update service)，该服务实现了一个 CRM 更新流程，并使用 Core Transaction Update Service。
图 2. CCMS 体系结构概述
将现有资产转换为服务的示例有 Address Standardization Service、Matching Service 和 Assign Key service。地址标准化和匹配（检查记录是否唯一）的服务是通过包装现有遗留 Trillium 引擎提供的功能创建的。这些通过封装 Trillium 创建的服务现在可以在其他客户信息业务流程中重用，而不仅限于客户更新流程中。另一个步骤涉及到在没有现有基础可重用的情况下创建新服务，如 CCMS Persistence Service。
业务成果
CCMS 的 SOA 转换是 IBM 实现随需应变企业的业务远景的一个主要步骤。通过使用 SOA，CCMS 成为了基于重用的灵活而适应性强的解决方案。企业业务流程重用 CCMS 服务，而不用自己开发冗余的等效服务。CCMS 的 Update service、Search service、Address Standardization service、Match service 都是可重用服务的良好示例。CCMS 不仅提供了可重用服务，而且现在 CCMS 还能够将其服务编排为企业流程。重用所带来的灵活性给 IBM 提供了巨大的业务价值。此解决方案的业务价值非常明显，不过尚没有从资金的角度计算可测定的业务价值好处。
CCMS 另一个明显的业务价值是将客户信息作为服务实现。由于客户信息对 IBM 的业务至关重要，因此 CCMS 是主要的 IBM 内部“作为服务的信息”之一。在 CCMS SOA 解决方案中，信息包装为供业务流程使用的服务，因此可通过标准化的方式向每个流程提供一致的可管理的信息。在采用 CCMS 之前的环境中，每个业务流程都创建自定义信息访问，从而导致了流程之间不一致的客户数据视图、不一致的规则应用和相同逻辑存在多个维护点的情况。
CCMS 的一个可测定的业务结果是数据质量的改进。为了测定客户数据质量而实现的企业流程的报告表明，CCMS 数据质量相对于之前的解决方案有了大幅度的改进。由于 CCMS 中的数据质量改进，依赖于准确而及时的客户数据的 IBM 业务领域（如销售与机会管理以及服务等）的客户满意度得到了提高。据估计，基于 SOA 的 CCMS 解决方案每年大约可带来 815 万美元的资金节约，而这主要是通过淘汰 CCMS 所替代的冗余客户数据库来实现的。
通过为其后端功能使用工作流，CCMS 启用了更为全面的方法来集成源自 IBM 内多个客户数据源的客户信息。这就减少了客户信息不完整或不准确的风险，而出现这些情况可能会对重要业务事务造成严重的延迟。CCMS 现在代表的是 IBM 的单一客户记录创建点和客户数据的主要来源。此外，可从多个业务部门方便地交叉引用客户信息带来新的销售机会。这还允许以增量的方式逐渐讨论很多冗余客户信息数据源。
所使用的非常好的实践及获得的经验教训
CCMS 是另一个 SOA 解决方案示例，其中后端流程在管理从服务接口提供的信息的过程中扮演着重要的角色，而服务接口不过是冰山一角而已。在部署服务接口前，CCMS 首先需要创建所有 IBM 客户信息的集成视图。这涉及到利用 WBI Server Foundation 提供的业务流程灵活性创建操作工作流，以将其用于管理多个来源的客户数据。
和很多企业关键应用程序一样，“大爆炸 (Big Bang)”方法费用太高，且会带来干扰。在开发 CCMS 后端流程管理客户信息之前，需要使用 Web 服务来访问主要客户信息。部署了一个战术性的解决方案，从而向现有 RDc 连接点公开了一个服务接口。此战术实现使用了策略客户信息访问接口（CCMS 最终部署了此接口）。此增量方法尽可能减少了从战术服务到 CCMS 的迁移工作。
从遗留客户数据系统迁移到 CCMS 所需的成本和资源导致有必要采用没有干扰的渐进迁移路线。由于 IBM 处理过很多设计用于满足企业需求的常见服务，将会通过一段时间以渐进方式迁移到这些服务，并可以采取积极有效的措施进行加速，以快速讨论遗留客户数据存储库。
