凤凰公司信息系统SOA转型报告 团队成员：钟培德 吴邦欲 陈 哲 李 鑫 指导教师：支志雄 教授 团队成员：钟培德 吴邦欲 陈 哲 李 鑫 指导教师：支志雄 教授 各位老师，大家好！我们来自清华大学，我们参赛的题目是“”，这是我们的指导老师，支志雄 教授，这是我们团队的三位成员

提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施 我们将从以下五个方面进行介绍：

1、项目背景 行业现状 IT面对的挑战 IT迎接挑战的SOA方法论 凤凰公司的问题及需求

行业现状 经济全球化，企业面对急剧的市场竞争 迫切需要利用IT进一步提高生产效率 1、项目背景 业务整合：提高业务流程的执行效率，对市场机会做出敏捷的反映 企业整合：实时掌控企业信息，将传统的以部门为导向的纵向决策转换到面向市场的横向决策 “飞机上的仪表盘” 迫切需要利用IT进一步提高生产效率 经济全球化使得企业面对急剧的市场竞争，企业必须提高业务流程的执行效率，对市场机会做出敏捷的反映，这就要求对原有的业务进行整合， 同时，管理部门必须能够实时掌控企业信息，，以便将传统的以部门为导向的纵向决策转换到面向市场的横向决策，因此需要对企业进行整合，这也是SOA讨论中经常提到的“飞机上的仪表盘”问题。 所以，对行业来讲，迫切需要利用IT进一步提高生产效率

IT面对的挑战 系统：部分IT系统由没有实现互联互通的信息孤岛组成 开发：业务系统开发周期太长，容易导致业务机会的丧失 1、项目背景 IT面对的挑战 系统：部分IT系统由没有实现互联互通的信息孤岛组成 开发：业务系统开发周期太长，容易导致业务机会的丧失 支持企业和业务整合时的局限性 传统技术关注单个对象，不强调整体规划，不适应跨部门集成的需要 IT整合存在高成本和高风险：局部的变化会影响整个系统，牵一发动全身，顾此失彼，系统越改越乱 那么IT又面对什么样的挑战呢？ 这使得IT部门竭尽全力寻找新的开发方式，特别是在设计观念上，不能单纯地关心技术，同时要重视业务，设计实施需要取得业务人员的配合 为了应对市场竞争，需要对企业和流程进行整合，但传统的IT技术完成整合存在一定的局限性。

IT迎接挑战的SOA方法论 1、项目背景 一种方法论： 特点： 价值： 业务需求与技术积累发展到一定阶段的产物 将不同粒度的元素以服务为单位打包发布，构成服务大集市，各取所需，求同存异，松散连接 特点： 强调继承与发展，与传统技术方法互补：继承（组件、对象、分布式系统等），发展（综合利用传统技术提供的功能） 实现IT灵活与统一的平衡：标准平台 价值： 实现了跨越不同应用系统、不同技术的整合 降低了企业整合时IT信息架构的风险和成本 业务与IT的融合剂，填补 IT能力与业务需求之间的鸿沟 为了迎接挑战，业界提出了ＳＯＡ方法论 ，他是业务需求与技术积累发展到一定阶段的产物，将成熟的业务流程用先进手段来表示， 灵活是指，不同的IT实体可以采用不同的技术，提供的功能可以简单，也可以复杂， 统一意味着这些异构的实体通过SOA的标准平台构成统一的整体。 草稿本

公司架构 1、项目背景－凤凰公司的问题及需求 前面我们简单探讨了一些概念性的问题，现在以一个具体企业为例来分析。这是凤凰公司的架构图，总公司设有一个生产工厂，在各地设有分公司，总公司负责全公司的管理运营，设有相应的业务管理部门， （各部门介绍），各分公司拥有独立的业务部门， （各部门介绍）

公司运作 总公司 分公司 1、项目背景－凤凰公司的问题及需求 制定销售计划 安排生产任务 执行产品配送 产品销售 合作与竞争 公司的云做实体是总公司和分公司，总公司主要负责管理协调和规划，分公司主要履行销售职责。 分公司与分公司在总公司的协调下互相合作。

IT环境 具备了基本的IT环境 1、项目背景－凤凰公司的问题及需求 总公司和分公司拥有各自的ERP和CRM系统

例子： 销售业务 操作流程 问题： 业务层面 IT层面 1、项目背景－凤凰公司的问题及需求 表示销售人员完成一个销售活动。上面这部分是指销售人员利用CRM系统产生销售订单，由于CRM和ERP系统不联通，然后，又在下面部分将销售订单输入ERP系统处理。 我们以此为例，分析公司在业务层面和IT层面存在的问题

业务层面问题 1、项目背景－凤凰公司的问题及需求 分公司销售人员不能在第一时间产生销售定单 由于CRM和ERP的信息不能共享，在完成与客户的商谈后，需要人工完成ERP订单提交，影响销售人员最终确定订单的效率。 分公司之间不能有效实现资源共享，缺乏共同面对市场的应急反映能力 例如：当某一分公司的库存无法满足销售需求时，那么要么冻结相应定单，要么业务人员需要花费大量精力和时间去了解其他各个分公司的库存情况，协商调货安排（包括定价，折扣，数量和产品运输）。 后果：增加了公司的总体运作成本，不能实现整体利润最大化和客户满意度最大化。 总公司不能实时综合分公司的销售，财务，库存等关键信息，不能根据市场变化及时调整公司运营策略

IT层面问题 分公司的CRM和ERP分别被部署，缺乏信息沟通，所以 各分公司之间的CRM和ERP缺乏信息共享 1、项目背景－凤凰公司的问题及需求 IT层面问题 分公司的CRM和ERP分别被部署，缺乏信息沟通，所以 业务人员只能分别操作CRM和ERP 部分数据重叠，部分功能重叠 导致大量的重复工作 各分公司之间的CRM和ERP缺乏信息共享 资源不能共享，业务执行不能最优化 总公司与各分公司之间的CRM和ERP缺乏信息聚合 总公司不能及时掌控分公司的信息 现有的系统正在发挥作用，整体上全部重新设计不可行 更大的问题在于：

业务层面需求 改进业务流程，实现流程自动化 提升分公司之间合作协调、共同面对市场的能力 实时掌控分公司信息，对市场变化做出敏捷反应 1、项目背景－凤凰公司的问题及需求 业务层面需求 改进业务流程，实现流程自动化 提升分公司之间合作协调、共同面对市场的能力 实时掌控分公司信息，对市场变化做出敏捷反应 前面分别分析了业务和IT存在的问题，我们接下来分析解决问题的需求。

IT层面需求 1、项目背景－凤凰公司的问题及需求 CRM与ERP实现互联互通 通过数据整合实现信息服务 IT整合的成本不能过高，代价不能太大 公司内部，分公司之间，总公司与各分公司之间 通过数据整合实现信息服务 IT整合的成本不能过高，代价不能太大 意味着不能更改原有的IT系统 采用合适的架构，基于现有资源进行整体规划，缓和业务需求和IT间的矛盾 这意味着

1、项目背景－凤凰公司的问题及需求 提出了基于SOA的转型方案 目标 提升IT系统的能力，支持凤凰公司完成企业整合和业务整合

1、项目背景－凤凰公司的问题及需求 这是我们的目标例图，系统互联互通，整合各分公司的数据信息和各部门的业务流程，为企业的宏观管理和全局优化提供支持，最终提升凤凰公司的业务能力

1、项目背景 基于SOA的项目过程 企业业务建模 服务建模 服务实现架构设计 项目实施 为了达到这个目标，我们采用基于SOA的项目过程。

提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施

2、业务建模 目标 分析现有的业务流程，确定业务改进方向，构造新的业务模式 业务创新 公司管理决策支持 订单流转 业务模式重构

公司管理决策支持 2 、业务建模－业务创新 目标 业务流程分析及相应的信息聚合 管理部门能够实时聚集客户和产品信息，对市场变化做出敏捷反应 业务部门能够有效执行相关业务 决策支持优化模型：最大化企业利益、最优化客户需求 业务流程分析及相应的信息聚合 销售流程－－－－销售流程信息聚合 调货流程－－－－调货流程信息聚合 生产/供应流程－－生产/供应流程信息聚合 财务运作流程－－财务流程信息聚合

2 、业务建模－业务创新 例：销售流程信息聚合

2 、业务建模－业务创新 公司管理决策支持 凤凰整合项目对凤凰公司的销售，生产/供应流程进行改进。此外，凤凰公司的各个分公司之间是既竞争又合作的关系，各个分公司之间的调货业务流程正体现了该关系。凤凰整合项目也将各分公司的调货业务作为项目重点进行改进。 改进后的销售业务流程将原先分别处理CRM和ERP的两个流程合为一个流程。 此外，凤凰整合项目将分公司和公司总部的ERP系统整合后，为公司的总体财务运作业务改进提供了IT基础。

优化模型 2 、业务建模－业务创新 目标 主要优化策略 需要考虑因素 最大化客户满意度 最大化企业利润 客户 面向公司 库存信息 价格信息 最经济 最快 面向公司 最低成本 最短时间 需要考虑因素 库存信息 价格信息 货运信息 工厂生产信息 原材料信息

订单流转 目标 内容 2 、业务建模－业务创新 以订单为中心，精简重复的业务环节，实现订单在各业务流程中自动流转，提高对客户需求的响应速率 新的概念解释 订单流转过程

新的概念 订单分解 2 、业务建模－业务创新 意向订单 预售订单 销售子订单 销售订单 当订单不能被满足时，可以将其分解到各个分公司 订单分解采用决策优化模型：面向企业的、面向客户的 意向订单 销售人员按照业务机会，与客户协商，确认客户需求后形成意向订单 预售订单 当意向订单不能被某一分公司完全满足时，需按优化模型进行订单分解，得到一系列预售订单 销售子订单 每一个预售订单是一个解决方案，其中包含多个销售子订单 销售订单 销售子订单被客户确认后变成最终的销售订单 意向订单能够被某一分公司完全满足时，直接转换为销售订单

2 、业务建模－业务创新 订单业务流转

2 、业务建模－业务创新 重构的业务模式：

提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施

3、服务建模 任务 服务挖掘 应用业务组件对服务进行封装，形成服务模型 服务积累 抽象出支撑业务模型的服务，建立服务模型 根据业务与IT环境的变化，不断发现服务，丰富服务模型

（1）业务流程分解 3、服务建模－服务挖掘 按层次识别业务流程的各项活动，进而得到各个层次的服务 例：对订单流转的业务流程分解 对业务框架中七个阶段中各项活动进行分析，将顶级的业务流程进行分析，可以获得支持业务模型的各项活动，这些活动在服务建模的过程中将被作为服务的候选者。考虑到服务的粒度与流程灵活性，我们对主流程只进行了一级的分解，以免出现服务过多，整合复杂的问题。 对业务流程的分析获得服务基础候选者

（2）分析现有系统 3、服务建模－服务挖掘 对现有系统功能的分解，为已发现服务的实现提供依据，并发现遗漏的服务 例：对CRM系统的功能分解 通过对现有的CRM系统组件进行分析，我们在现有系统中找到支持改进业务模型的业务组件，发现这些组件能够极大的利用现有的IT资源降低开发成本

核心业务目标 在进行业务模型重构时，确立了两个核心业务目标： 3、服务建模－服务挖掘 最大化业务机会成功率 提高流程效率，最大化企业利润 及时响应客户需求变更 对定单进行分解处理，将满足客户需求部分与变更部分分开处理 提高流程效率，最大化企业利润 降低由业务机会生成销售定单时间 提供最佳的定单处理方案，优化企业利润 对于前面发现的服务，可以采用核心业务目标进行验证

（3）验证服务 3、服务建模－服务挖掘 通过分析实现核心业务目标的手段来验证服务并发现遗漏的服务 服务挖掘的第三步是根据发现的服务和制定的核心业务目标来验证服务

构造服务模型 通过服务挖掘形成服务集合之后，基于以下业务组件对它们进行封装，构造服务模型 3、服务建模 产品管理组件 销售管理组件 订单管理组件 客户管理组件 系统应用组件

3、服务建模 组件模型 这张图描绘了上述的5个业务组件及其输出的服务

服务积累 3、服务建模 新服务的出现 不断的服务发现与积累 业务需求的变更 IT环境的变化 虽然前面我们已经构造了服务模型，那么是不是说这个服务模型就一成不变呢？不是的，因为业务需求会 不断变化，IT环境也会不断变化，这些变化会导致新服务的出现，因此我们需要不断地进行服务发现与积累，丰富服务库

提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施 提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施 在完成了服务建模后，就获得了封装各类服务的业务组件，那么下一步目标是把这些组件部署到系统中，因此 需要进行系统架构设计。

4、系统架构设计 系统架构设计考虑的因素 关键技术决策 系统高层框架 应用场景 系统需求 数据交换 在系统架构设计过程中，我们首先需要从三个方面进行考虑，包括应用场景、系统需求、和数据交换。 其次需要对一些关键技术进行决策，最终形成系统高层框架。

应用场景描述 4、系统架构设计 决策人员： 订单处理决策——企业的全局信息 销售人员： 创建业务机会——企业产品信息和客户信息 财务人员： 审核订单——订单信息，客户财务状况 客户： 交流，反馈——直接参与企业的业务活动 对于整合后的信息系统，主要的使用人员包括：销售人员，财务人员，决策人员和客户。 销售人员需要通过系统获得产品信息和客户信息，创建业务机会。财务人员需要通过系统获得订单信息和客户财务状况来审核订单，决策人员需要根据企业的全局信息来做出决策，客户可以通过系统与企业交流。

系统需求 上述应用场景对系统提出了新的需求，包括： 4、系统架构设计 数据抽取 决策支持 流程整合 统一、规范、标准——分在企业各处的数据均能“为我所用” 决策支持 丰富的信息展现，多种信息聚合，为业务决策提供可靠依据 流程整合 应对业务流程的变更，整合现有的销售流程 新的业务需求带来了新的IT系统的需求，在原有的系统的基础上，整合的信息系统应至少提供在以下几个方面的功能： 1，数据抽取,现有的企业中应用的各种系统中存在的大量的丰富的数据，但是这些数据由于天然的IT系统异构性使得无法被使用者充分利用，将各种异构的数据抽取出来，提供给用户统一，规范，标准的的数据展现形式，使得这些数据能够被充分利用。 2，决策支持的能力，将分布在企业中各个IT系统中的不同信息进行有效的聚合能够为决策者提供可靠的依据，帮助他们作出合适的决策。 3，灵活的流程整合能力提高的信息系统的利用率，能够应对按需而变的业务流程为企业的业务创新提供的基础。 4，建立客户与企业之间的信息交流平台，能够将客户进一步融合到企业中的业务流程中来，企业销售人员能够更好的与客户交流，在获得更多的客户信息的同时也能够从另一个角度展现企业的现状。

数据交换 4、系统架构设计 定单处理流程与决策支持需要从现有系统中抽取各种信息 建立统一的数据交换框架，实现异构数据之间的交换 下面我们从数据交换的角度分析需要构建的系统，不难看出，定单处理流程与决策支持需要从现有系统中抽取各种信息，例如 需要从ERP系统抽取产品信息、价格信息等。因此，需要建立统一的数据交换框架

数据交换框架 4、系统架构设计 在各系统之间建立数据转换器，利用XML实现数据交换

数据交换－信息服务 4、系统架构设计 建立以订单业务对象为主的信息服务 订单业务对象：在以订单流转为核心的业务处理过程中，由各种信息汇集形成 信息服务为系统提供了更加通用的连接支持，降低了流程服务实现的复杂度 数据交换的实现，为建立以订单业务对象为主的信息服务提供了支持。这里的订单业务对象是指，在以订单流转为核心 的业务处理过程中，由各种信息汇集形成，如图所示， 包括客户、产品等。 在凤凰的公司业务流程中，以 在实现订单流转过程中，订单成为核心的处理内容。原有系统中各种信息向订单信息的汇集，多种信息汇集形成了 订单业务对象。

关键技术决策（1） 4、系统架构设计 信息服务效率 由于现有系统的整合中，信息服务被各种其它服务频繁使用，很可能成为系统的瓶颈 采用CDN技术，为信息服务建立多个二级信息提供点，提高信息服务的效率。 前面我们分别探讨了系统架构设计中需要考虑的三个因素，同时还需要考虑影响系统可行性的重要问题， 首先，信息服务的效率问题，。。。。 如图所示，各系统可以选择最合适的信息服务实体。

关键技术决策（2） 通信安全 4、系统架构设计 总公司系统与分公司系统间通信通过Internet完成，网络环境不安全 需要建立数据保护机制，防止企业核心数据外泄 在企业服务总线的建立过程中引入VPN技术 其次，影响系统可行性的是通信安全问题，这是因为。。。我们认为，需要在企业服务总线的建立过程中应用VPN技术。

关键技术决策（3） 4、系统架构设计 数据访问安全 不同的用户对数据具有不同的访问权限 采用基于角色的访问控制策略，防止企业信息被不恰当的使用 角色 权限 销售人员 客户信息，产品信息 财务人员 销售定单信息，财务信息 管理决策人员 定单相关所有信息，企业信息 客户 定单处理状态信息 第三，影响系统可行性的还有数据访问安全问题，因为不同的用户对数据具有不同的访问权限，例如销售人员可以访问 客户信息和产品信息，而客户只能访问定单处理状态信息。因此采用基于角色的访问控制策略，防止企业信息被不恰当的使用。

系统高层框架 4、系统架构设计 在前面一系列的分析设计基础上，引用IBM SOA参考架构，建立了我们的系统高层框架。该框架主要包括: 实现订单流转的流程服务、提供订单业务对象的信息服务和ERP、CRM系统 同时利用CDN技术提高了信息服务的性能，在ESB构建过程中，使用VPN技术保证通信安全，使用基于角色的访问控制策略保证数据访问安全

提 纲 1、项目背景 2、业务建模 3、服务建模 4、系统架构设计 5、项目实施

5、项目实施 参考IBM SOA解决方案流程以及部分IBM产品，现作如下规划： 项目内容 时间安排 各阶段所需软件

项目内容 5、项目实施－项目规划 项目设计 以服务为中心的开发与集成 服务部署及管理 流程优化和服务优化 测试 项目实施效果分析 CRM、ERP服务封装 编写现有系统中缺少的服务 生成组件 交互界面实现 实现信息服务 设计企业服务总线 整合业务流程 服务部署及管理 流程优化和服务优化 测试 项目实施效果分析 进行详细的

5、项目实施－项目规划 时间安排

5、项目实施 各阶段所需软件

团队优势 四名团队成员来自清华大学ICSE实验室，均从事SOA方向的研究工作 优秀的指导老师 团队成员背景： 多年的分布式并行系统经历，系统已在多个重要行业发挥作用 4年的网络安全经历 2年的J2EE和JSP项目经验 4年多的操作系统相关开发经验， 精通多种实际操作系统 6年多的C/C++程序设计经验， 精通面向对象程序设计思想和模式 1年多的编译器开发经验， 对IT的主要领域均有所了解

总结 业务创新 技术创新 订单流转 （借鉴电子政务中公文流转的概念） 决策支持 （面向客户和企业的优化模型） 利用CDN技术提高服务效率 订单流转 （借鉴电子政务中公文流转的概念） 决策支持 （面向客户和企业的优化模型） 技术创新 利用CDN技术提高服务效率 利用VPN技术提供数据通信安全 基于角色的访问控制保证数据访问安全

感想 收获 最大的挑战 更加深刻的理解了SOA的理念 掌握了IBM的整套SOA解决方案 认识到ESB在架构中的重要作用 认识到团队合作的重要作用 优秀的指导老师是成功的基础 最大的挑战 缺乏熟悉企业管理的人员

致 谢 感谢指导老师支志雄教授的殷切教诲 感谢清华大学ICSE实验室全体成员的大力支持 感谢IBM公司给我们这样一个展示自己的平台

谢谢各位老师