SOA案例研究-技术开发专区

Customer Order Analysis and Tracking System 是供全球二十多个工厂使用的共享订单输入应用程序，每个工厂都具有自己的自定义需求和访问模式，如“高容量低价格”与“高价格低容量”。COATS 是 IBM Supply Chain 的一部分，在订单执行中扮演着重要的角色，可处理大量订单，帮助每天处理 10,000 个以上的包裹。COATS 提供全天候服务，可接受 IBM 客户、业务合作伙伴和 IBM 销售专业人士的复杂配置硬件订单：System i、System p、System z、Storage、Printers 和 Retail。

购买者通过提交有关新计算机、升级、定制的订单和对现有订单的其他更改来间接访问 COATS。应用程序会将这些订单与制造规则和客户已安装硬件库加以比较，从而进行排序和确定优先级。COATS 会将订单流“翻译”为制造材料列表（物料清单，Bill of Materials）和其他指令，这些内容通常被转发到全球相应的 IBM 制造工厂。制造工厂将随后开始执行订单，并运送到客户的收货地点。订单的一个例子是指定了详细规格、预装软件和交付日期等的大型机。对应的输出示例将包括特定工厂的制造车间的配置，而对应的相关术语包括物料单、配置计划等。

原始应用程序是已经使用了 25 年的复杂旧式批处理系统。其中包含 140 万行 PL/1、OS/390 汇编语言、Java 和其他编程语言代码，峰值时已非常接近其处理容量极限。批处理瓶颈和冲突数据对订购和配送造成延迟。

COATS 具有硬编码的业务规则、过程、逻辑和数据访问，已发展为难于针对现有和新兴业务需求进行调整的系统。更改业务流程通常要求进行大量的重新编码工作：开发人员必须理解一组复杂的点到点连接和组件独立性，以便预测变更的效果。为了应对不断发生的订单变化（包括调度系统为了满足客户的交货日期而进行的自动调整），必须对多个数据库进行更新和查询，具体取决于地理位置和其他参数（如所保留的五到十年的计算机销售历史记录等）。

为了支持新活动、新产品和业务机会，频繁地对应用程序进行了更新。由于采用了严格的遗留代码，花费了大量资源（时间和资金）进行新功能开发——每个版本的开发时间都要花费六个月时间，占用超过 8,000 小时开发时间。

存在这样的实际需求，需要提高对功能和驻留在现有遗留系统中的宝贵业务数据的访问，并要求能够从其他系统方便地进行访问。

和很多企业关键应用程序一样，大规模进行替换费用太高，且会带来干扰。

COATS 转换项目的重点在业务涉众认为非常重要的几个目标上：

降低应用程序更改或错误导致的生产停滞频率
降低由于 COATS 子系统间订单批处理方式的差异而导致收益损失的可能性
通过加速更新周期和允许以增量方式重写、更改和重新部署功能来更快、更简单地满足业务需求
允许通过建模和监视业务流程模型来进行业务流程管理。

图 1. COATS 体系结构概览

订单管理组件服务项目负责将总体 COATS 系统转换为实时的订单提交系统。

解决方案的面向服务的体系结构（参见图 1）对业务流程和 IT 需求进行了标准化。在此体系结构中，业务规则被外部化，而遗留系统功能则被组件化，以便提高灵活性、可伸缩性和重用性。

Order Process Subsystem 负责接收处理客户订单组的请求，并随后将订单发送到其他服务。此系统能够处理多个通道，包括用于实时处理和批处理的 B2B 消息传递系统。

接收到订单后，Order Process Subsystem 将其标记为需要进行验证，并将订单转发给 Validation and Topology Generation 服务。该服务将进行分析，并为不同类别的订单使用专门的验证服务。

传递验证步骤的制造订单组将随后发送到 Manufacture Plant 服务，以转换为物料单，并转发给制造工厂。这些服务将通过服务适配器与实际向目标工厂交付物料单的现有遗留应用程序或业务合作伙伴应用程序交互。

开发过程将首先从支持 IT 系统中分离业务流程和数据。在 IBM WebSphere® Business Modeler（以下称为 Business Modeler）内对业务流程进行了建模和表示。

COATS 开发团队采用了迭代的方法进行此转换项目。迭代过程从使用 Business Modeler 进行业务分析开始，业务分析的目的是为了构建原始 COATS 应用程序中使用的“原样”业务流程的模型。获得了模型后，分析人员就能够确定进行改进的机会、提出更改建议，并能够预估更改对 COATS 应用程序的影响。此外，对“原样”模型的分析还能帮助标识现有资产，以供进行重用。

为了创建模型的“原样”版本并最终确定业务流程的规范，团队使用了业务涉众认为重要的项目目标来确定服务和组件。这些目标用于定义标识“原样”模型的各个领域的决策标准，以从转换到利用工作流和业务规则的灵活实现获得最大的好处。

为了标识和指定 COATS 业务服务，该团队采用了一种可重复方法，而这个方法后来促成了 IBM 面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的形成。SOMA 是一种旨在通过从 SOA 基础标识、指定和实现与业务一致的服务来支持目标业务流程的方法。SOMA 将业务特征扩展到 IT 分析和体系结构决策中，从而创建了业务意图与 IT 实现间的连续体。SOMA 期间执行的分析和建模工作并不特定于技术和产品，而是要建立一个上下文，以便在生命周期的以后阶段进行技术和产品特定的决策。其目标是提供 SOA 建模（分析和决策）的指南。IBM 流程工程师和架构师将 SOMA 用于进行客户合作项目和内部项目。

在进行业务分析的同时，数据架构师使用了 Rational ® eXtended Development Environment 来定义基于统一建模语言（Unified Modeling Language，UML）的数据模型。这些数据模型表示 COATS 业务流程要使用的业务对象，用于在组件间进行通信。

开发构件——业务流程执行语言（Business Process Execution Language，BPEL）、Web 服务描述语言（Web Service Definition Language，WSDL）、XML 模式定义（XML Schema Definition，XSD）和 Business Modeler 与 Rational eXtended Development Environment 产生的基于 Java 的数据模型实现——都由集成开发人员通过使用 WebSphere Studio Application Developer Integration Edition 工具进行了进一步增强。开发团队使用了 WebSphere Studio Application Developer Integration Edition 来实现以下更改，以完成工作流实现：

通过创建到 MQSeries® 和 CICS® 的适配器来允许访问遗留系统
添加用于人工决策和异常处理的成员活动
将决策点重构到存储在外部 BRBean 存储库中的业务规则内
与 WebSphere Portal 表示层集成。

COATS 的生命周期扩展到了开发之外，包含业务流程管理的各个方面。开发迭代产生应用程序的可部署工作版本（应用程序的工作构建）后，业务分析人员可以通过跟踪关键性能指标（Key Performance Indicator，KPI）来监视系统的实时性能。KPI 是在实现工作流前由涉众定义的，可提供每小时通过系统的平均订单数量、系统处理的无效订单数量以及操作员处理无效订单的平均时间等交付信息，从而便于从业务的角度监视系统运行情况。最后，执行人员可以使用通过监视应用程序收集到的信息来进行业务流程更改决策，以满足业务单位性能目标。

案例研究 2：Microelectronics“盒子里的工厂”

应用基于 SOA 的新解决方案的若干增量版本后，提高了业务性能和灵活性。此外，也实现了减少开发成本和缩短开发周期的目标。业务成果简要总结如下：

订单事务处理时间从 4 分钟缩短到 10 秒。在 COATS 中，每天平均有大约 2,500 个请求（高峰时，每小时 300 个）。因此，节约了四分钟时间，总共节约的时间每天可能超过 150 个小时，所以在转换完成后，可以提高每天的订单处理速度。
这个解决方案简化了系统间的集成方式，支持可减少交付计划中的差异的实时事务。
能够通过简单的可选择规则对运行时工作流进行随需应变的更改。
新系统消除了开发流程中的冗余
- 开发周期中的这些改进意味着，IBM 能够更灵活地应对与其他订单执行流程相关的不断更改的业务需求
- 开发时间和成本节约超过 25%
包含了更好的错误处理工具，能够更快地进行异常处理，从而提高了收益。
在此工作期间，我们获得了大量可重用的开发资产和非常好的实践。此活动帮助我们强化了 SOMA 方法。

所用的非常好的实践及获得的经验教训

此活动帮助我们创建、实现和获得了将遗留业务功能以增量方式转换为实时而灵活且支持 SOA 的解决方案的方法。所用的非常好的实践及获得的经验教训简要总结如下：

使用服务的增量实现获得早期的支持，通过对预期情况进行管理来实现无干扰迁移。与遗留代码服务共存，支持将系统功能逐步过渡到新体系结构。
通过服务建模保持业务/IT 体系结构一致。
要开发灵活的业务流程，需要在方法和工具的支持下考虑整个服务生命周期——从建模到监视。
遵循迭代设计和增量开发方法，采用建模、设计和集成模式。
创建早期 BPEL 流程模型
- 不要包含活动细节——细节应该在用例中进行记录
- 创建业务流程模型的同时创建数据模型

我们通过恰当使用服务建模、增量开发方法、工具和中间件组件说明了如何进行增量转换。在此活动中确定的流程自定义、增量转换和遗留集成方法正在 IBM 和我们的客户中广泛应用。

对公司的结构进行分解（划分）并允许将重点放在核心业务竞争力上的做法自然会导致协作生态系统的出现。制造行业首先发现了规范化和协作的强大力量，并使其达到了新的高度，随后这也在电子行业得到了广泛的认可。

在这种协作生态系统中，半导体行业正逐渐从完全自包含的制造系统的垂直集成转向合作伙伴的集成参与网络，其中的每个合作伙伴均能以高效低成本的方式提供专业的制造服务。考虑到当今希望尽可能利用全球资源的经济环境，运营环境也迅速从关注本地力量发展到了关注来自多个国家的力量的全球协作。微电子行业产品解决方案的复杂性不断增加，以满足新客户需求，而这促使自定义解决方案出现了超过传统标准产品服务的势头。这就要求制造系统具有更高的适应能力，且要具有更广泛的执行能力，而这已不再能完全通过“内部”解决方案得以解决了。

2003 年，IBM Microelectronics 认识到需要更大的灵活性，以满足与跨多个场所和供应商的晶片和模块制造关联的不断变化的制造需求。对更高灵活性和响应能力（以获得“随需应变”的制造能力）的需求是虚拟制造企业概念的起源，此概念的重点在于跨多个微电子生产场所（内部的和已外包的）进行制造控制和执行的集成方法。

2000 年中期，IBM Microelectronics 遇到了与其他同行类似的挑战：

财务模型：尽管激烈的竞争正导致单个产品单元的成本和价格下浮，但与新产品相关的复杂性和成本却在持续升高。更复杂的解决方案还提高了计划、开发和制造流程的复杂性。当今半导体行业的高级需求易失性带来了高费用投资易失性。经常很难预测产品需求的快速波动和为之准备制造系统。必须对制造基础设施的投资进行策略规划，以与预期或非预期市场情况吻合。
领域集成：尽管现在主要的重点在核心竞争力，但半导体产品存在一定程度的的多样性，需要集成以前独立的制造系统。这个集成需求也适用于各个业务领域，如工程、企业资源规划、测试、机会管理、财务、产品发布、产品设计和开发以及信息数据仓库等。
外包：新全球化趋势提出了集成多个可互换的合作伙伴的需求。内部制造功能必须通过一次性构建功能并在以后加以利用，从而在操作停机时间尽可能少的前提下快速复制到外包供应商。这些供应商功能必须针对晶片制造、晶片测试、模块构建和模块测试等功能进行集成。所有参与者之间的通路必须可靠和安全，而且 IBM 必须能看到出现的所有事件，还必须能够收集产生的所有数据。供应商参与者必须接受 IBM 的一定控制，以获得一致的产品流程结果，而且必须能访问所有必要的功能——即使不是本地/本机环境也应如此。全球化的虚拟制造体系结构要求使用开放的行业标准来提高互操作性和尽可能减少合作伙伴采用 IBM 的接口所需花费的时间。

为了处理上述挑战，IBM 的 System Technology Group (STG) 半导体制造部门基于集成的模块化体系结构创建了一套解决方案。他们的目标是创建一个虚拟化框架来管理与高效外包计划并存的内部制造资源，从而形成了他们称为“盒子里的工厂”的新概念。这是一个全球的模块化制造功能“盒子”，包括网络传输、安全性、数据管理、监视、制造控制以及独特的自定义等功能。“盒子里的工厂”是通过将这些功能打包为一组 IBM 软件产品和自定义代码实现的，而这些产品和代码也称为多源数据集成器（Multi-source Data Integrator，MDI）。MDI 安装在 IBM 和供应商合作伙伴的厂区内（如图 2 中所示），以创建 STG 的各种制造业务领域与物理制造安装之间的无缝交互，而不受其位置限制——从而创建了一个虚拟化的制造环境。这允许将供应商视为 IBM 制造环境的扩展。

图 2. 虚拟制造体系结构概述

有人可能会问，“不错，这是一个很好的随需应变业务的例子，但 SOA 在哪里呢？”关键的 MDI 集成元素包括其企业服务总线（通过 Business Modeler Message Broker）和一组基于 SOAP 的自包含 Web 服务。Message Broker 除了完成路由任务外，还可在建立了 ESB 体系结构模式后通过协议和消息转换实现高度分离。有些服务是完全自包含的，仅支持内部 MDI 功能，对盒子外部的任何对象都是透明的。不过，其他服务则可以由 IBM 应用程序用户、供应商应用程序用户访问（有时候两者都可以访问）。正是这样将 SOA 功能打包为可移植的形式，从而使有些人将 MDI 的原始名称改成了“盒子里的服务 (Services in a Box)”。

服务示例：

Wafer Die Disposition：各种与晶片制造及测试相关的功能。这些功能最初的目的是为了用于外包制造，但正越来越多地用于内部用途。
Manufacturing Execution System Transaction：为大量制造执行系统提供无依赖性的接口，允许查询制造批次状态和属性。
Module Disposition：支持涉及到模块制造和测试的各种功能
ULL Generator：支持基于规则生成特定于位置的唯一通用批次标签（Universal Lot Label，ULL）。ULL 服务通常针对每个独特的 MDI 位置进行了自定义，以使用位置特定的规则生成 ULL。

MDI 是在经过验证的 IBM 中间件和操作管理产品基础上构建的。这些产品包括 DB2®、WebSphere Application Server、MQSeries®、WebSphere Business Integration Message Broker、WebSphere Business Integration Connect 和 Tivoli Management Environment® for Monitoring。由 IBM Global Technology Services 将其安装在 IBM 和供应商的工作区内。供应商安装在 IBM 托管服务器上的非专用区域，可通过 IBM 远程通信访问，也可以通过供应商的防火墙由供应商访问。

体系结构解决方案的突出特点：

快速外包：一个由标准驱动的公共机制，用于和 IBM 内部及供应商制造工具进行交互，可以促进将 IBM 的制造工作有效外包。
“盒子里的服务”：一个全新的概念，允许在远程位置方便地传输和管理一组预定义的可配置服务。
外部化的业务规则：MDI 中的规则引擎已与操作代码分离，可提供灵活性，能在无需重新编码的情况下针对新业务情况进行调整。
“虚拟工厂”：受业务域（每个域都具有自己的一组流程和数据）间的技术隔离层框架支持的 MD 的黑盒实现。
服务：将新功能和遗留功能分解为可重用服务。

案例研究 3：法律法规遵从方面的 Export Validation Export Validation Service (EVS)

此解决方案为 IBM Microelectronics 创建了一个“虚拟”制造系统，涉及多个可互换的集成合作伙伴（供应商）——通过 SOA 实现的“盒子里的工厂”。

例如，Technology Group 将半导体测试工具外包给 Amkor Technologies，从而使得 IBM 系统在从 IBM 进行迁移的过程中仅停机四个小时，而在以前通常需要三天才能实现其新的支持 SOA 的体系结构。规则已更新到新工具的路由事务，而这个转变在很大程度上对普通操作是透明的。而这正得益于 MDI 的“盒子里的工厂”构造所实现的模块化技术。此外，这个“预先打包”的 SOA 体系结构现在可方便地完成外包计划，比针对每个新机会进行自定义更为高效。这就可以在数周前进行计划，而无需像以前一样需要三个月前就开始计划工作。

所用的非常好的实践及获得的经验教训

在此活动期间，我们获得了一些重要的经验教训：

业务域的虚拟化及与相关流程和数据的隔离形成了一个“隔离框架”，可实现域之间非常好的的分离，从而实现了“虚拟工厂”
规则引擎中包含的外部化业务逻辑与主要操作代码和服务分离，允许更快地进行业务流程更新
可以使用工具 Beta 版，从而有助于为将来的项目定义工具需求
在启动项目前完成 SOA 试验项目可帮助更有效地发挥技术的作用，减少对项目计划的影响。

美国出口法律法规规定了有关可将哪些物品出口到境外的哪些对象的限制。这些法律法规适用于涉及最广泛意义上的任何出口类型的所有情况——包括从美国向任何其他国家/地区提供硬件、软件、服务、工具或技术。除了传统的物理交付方式外，通过电子方式将软件或技术信息提供给美国之外的实体（个人、公司、组织、政府）也受到控制。

可能不可将与国家安全相关的特定产品或技术（如加密技术、核武器、化学或生物武器、或导弹）售出或提供给规定名单中的国家/地区。美国政府发布了一份实体名单，称为出口管制黑名单（Denied Parties List，DPL），不允许美国公司与其中的实体开展任何形式的业务。另外，美国政府还发布了禁运或恐怖主义相关的国家/地区名单，从而对业务活动进行了进一步的限制。

正式制定的用于确保符合政府法律法规的策略正变得越来越重要，需要在企业级别加以控制，以避免巨额罚款和其他由于违规而导致的负面影响。IBM 的 Export Regulation Office (ERO) 负责 IBM 必须如何遵循美国出口法律程序，并每月更新美国政府关于不能与之开展业务的个人、公司和国家/地区的名单。IBM 的在线软件销售和下载（免费和付费软件）需要更为自动化的方法来对交付内容及其接受人进行实时验证。这对于保证不会违反美国的相关限制非常必要。

在 IBM 内已部署了多个应用程序来支持美国出口法律法规遵从。由多个业务领域实现了多个出口检查的版本。它们都需要包含 ERO 每月更新的管制名单，以避免执行费时的手工任务来恢复与规定的名单上的实体进行的错误业务事务。公司内出口管制功能的大量增加带来了不必要的开发和维护成本，而且 ERO 需要与多个开发团队合作来确保遵从一致性。

IBM 的 Software Delivery and Fulfillment (SDF) 组织最初为自己的在线销售和交付功能创建执行各种出口检查的功能。不过，他们需要更为高效的解决方案，以便方便地进行集成，以供自己使用；此解决方案还需要具有高度可重用性，以便将其功能扩展到其他的企业部门。SDF 的业务模型允许其接受来自潜在服务使用组织的新需求，从而促进在公司内更广泛地使用服务。

此解决方案需要处理的挑战简要小结如下：

美国萨班斯·奥克斯利 (Sarbanes-Oxley) 法案提高了对需要新 IBM 内部服务来支持对各种政府法律法规遵从的认识。
应用程序之间的冗余性以及过多的开发和维护成本。
每个月需要对多个应用程序进行更新，以将美国政府的出口管制名单包含到各自的本地副本中。
如果未及时包含出口管制名单的更改，则可能导致在 IBM 的 Integrated Supply Chain 流程中出现延迟。

EVA
图 3. Export Validation 体系结构概述

与其他几个早期 SOA 业务解决方案类似，此服务的基础已经存在于 Web 应用程序，在本例中即为对通过浏览器下载软件的客户执行实时检查的应用程序。2003 年 12 月，SDF 组织对其面向浏览器的基础设施进行了扩展，创建了基于 SOAP 的 Web 服务，即 Export Validation Service (EVS)。它允许其他请求者调用其客户分析功能，以便遵循美国政府出口法律法规。

根据提交的客户人口统计学信息（如名称、地址、位置、IP 地址以及涉及的 IBM 服务产品），此服务当前支持多个关键领域的出口检查：

进行以下方面的用户检查：1) 与美国政府的 DPL 进行比对；2) 详细审核，以避免将可用于导弹、化学与生物武器或核用途的技术扩散到指定的国家/地区；3) 与美国政府的禁运国家/地区名单进行比对（通过地址、电子邮件或 IP 地址）
加密产品检查，以控制包含强加密的加密产品的出口
按照丹麦和爱尔兰政府的要求进行专门的出口检查（支持这两个国家的 IBM 软件执行操作）

图 3 中所示的解决方案包括采用 ERO 美国政府出口管制黑名单更新形式的分散企业数据。

除了 HTTPS 上的基于 SOAP 的 Export Web 服务外，此关系图还显示了更新 DPL 的后台流程——手动访问 ERO 的正式更新名单，然后使用 DPL Administration Tool 来将最新的更新包含到 EVS 数据库中。另外还描述了用于在“模糊”逻辑不正确地确定某个客户在规定名单中时覆盖错误的确定信息的管理员功能 (Override Administration Tool)。必须进行此提交信息的模糊分析，以处理名称类似而拼写存在细微差别的情况。

和很多业务服务一样，EVS 并不是完全独立的功能，它与手动业务流程进行了集成，以提供额外的服务价值。存在“人工服务总线”(Human Service Bus) 的概念，用于将人工任务集成到组织化结构中，并与服务实现进行协作，以确保遵循企业标准，而在本例中，这也反映了政府的法律法规。

此开发团队最开始使用 IBM WebSphere® Studio Application Developer™，后来随着将工具更新为最新的 IBM 应用程序开发产品转而使用 IBM Rational® Application Developer™。WebSphere Application Server Version V5.1.x、IBM DB2® Connect Enterprise Edition™ 和 IBM HTTP Server 均运行于其运行时环境的 AIX 服务器上。

EVS 已经在多个现有 IBM 业务流程中启用，将供由需要进行客户检查来遵循出口遵从性的新流程使用。这包括销售时（网上或通过电话）的事务以及在向客户交付货物前的最后检查。

案例研究 4：Common Customer Master System——IBM 内的单一客户视图

现在能以实时的方式更方便地将美国政府出口管制集成到所有与客户的网络和电话交互中。这个服务现在支持采用集中而一致的方式执行所有 IBM 出口检查功能，并确保及时将美国政府更新的管制名单包含进来，从而消除受到政府处罚的风险。

EVS 的基于服务的可重用性降低了与为多个应用程序构建冗余出口管制功能相关的开发和维护成本。除了成本外，还通过提供使用现有服务（而不是构建新功能）来减少了开发计划。

EVS 在 IBM 的企业目标体系结构中定义为主要的 SOA“企业组件”，实际就将其定义为了供所有 IBM 的业务单位重用。EVS 正在作为潜在的 IBM 商业资产进行评估，因而 IBM 可能会为客户的业务流程同时提供此服务和手动覆盖流程。企业和业务单元体系结构治理组织要协同工作，以确定何种情况下应用程序必须使用这些企业组件，而不是构建冗余功能。

所使用的非常好的实践及获得的经验教训

在处理多个业务部门的需求时，经常会考虑采用集中资金投入的企业服务。很多企业服务都通过其属于承担整个企业的业务功能任务的组织的方式来进行集中资金投入。EVS 采用了一种不同的业务模型，在其中，为满足新需求而对服务进行的更新由每个请求针对其独特需求进行更改的服务使用者组单独提供资金投入。这个模型非常成功地确保了 EVS 获得足够的资金投入，以应对新业务方向的挑战。

不过，由于采用此业务模型，使用增量开发一次满足新使用者的一个需求，有时候会导致功能改进延迟。具有独特需求的新使用者有时候不愿意为企业级服务的一般性基本功能元素提供资金投入。为了将 EVS 扩展到软件产品之外更大的企业范围需要进行更新，以获得更好的稳健性，从而确保 EVS 能够处理额外的负载。这种情况的一个例子是基于 Perl 脚本的旧代码，除了进行其他性能改进外，还必须将此代码转换为 Java™。一般企业功能（功能性和非功能性的）都在新客户具有与企业类似的需求时由 EVS 团队采用增量方式加以处理，并接受 IBM 业务转换 CIO 提供的一定指导和资金注入。

EVS 说明了使用者业务所有者需要了解更多信息，而不仅仅是其自己自动使用某个特定的 Web 服务。当前在 EVS 中需要一个手动后端流程，以进行潜在的错误出口检查结果的后续处理。很多使用者开发团队经常只将精力放在服务的接口上，事实上还需要考虑手动支持功能，这也能增强服务的有用性。

根据使用的通道（如呼叫中心、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 中创建和维护数据非常必要

CCMS
图 4. CCMS 体系结构概述

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 上）。

图 4 所示的 Core Transaction Update Service 是基于服务的 CCMS 工作流的一个示例，可供各种更新相关的流程（如 CRM update、RDc update 和 D&B update）使用，以确保一致性、数据质量和消除冗余。这个特定的更新服务包括处理标准化、进行匹配（确定输入记录是否唯一或已经存在）、聚合或持久性的活动。聚合活动实现数据聚合规则，该规则会在更新 CCMS 数据前对要更新的客户数据中每个数据组的数据的来源进行考虑。聚合规则指示更新 CCMS 数据时信任哪个数据源（按数据组确定）。

图 4 还显示了 CRM 更新服务 (CRM update service)，该服务实现了一个 CRM 更新流程，并使用 Core Transaction Update Service。

将现有资产转换为服务的示例有 Address Standardization Service、Matching Service 和 Assign Key service。地址标准化和匹配（检查记录是否唯一）的服务是通过包装现有遗留 Trillium 引擎提供的功能创建的。这些通过封装 Trillium 创建的服务现在可以在其他客户信息业务流程中重用，而不仅限于客户更新流程中。另一个步骤涉及到在没有现有基础可重用的情况下创建新服务，如 CCMS Persistence Service。