本文发表于《中国计算机用户》杂志2009年第1、4期

http://media.ccidnet.com/art/2655/20090106/1652443_1.html

http://media.ccidnet.com/art/2655/20090223/1686267_1.html

大型企业信息化中的BPM 和SOA 实战

万星 [1]

JPort Group

北京交通大学

1   概览

对于 BPM 和 SOA 的理解一直是非常困难的，我认为如果没有企业信息系统的丰富开发背景，以及对于软件工程历史的充分了解，想要从纷繁的概念中理清一条思路，进一步为己所用更是让人难以下手。 SOA 和 BPM 概念的提出都具有悠久的历史，在学术界的研究也在向语义 SOA 和语用 SOA 等方向发展（这也是我们另一个实验室正在探索的方向）。而厂商的驱动使得 SOA 和 BPM 逐渐落地，从早期的大量文献在解释 SOA ≠ Web Service ，到后来 ESB 的出现，以及最近的 SCA/SDO 规范的完善（特别是具体产品的落地），直至今年兴起的 BPM 和 SOA 热潮，我们可以看到 SOA 离我们的工业实践越来越近了，它不再是一个时髦的大词。工作流抑或业务流程的辨析同样也使用户为难，简单而言，业务流程∈工作流。业务流程管理，或 BPM ，强调的概念是企业应用集成（ EAI ）。而 Workflow 领域的研究则显得单纯一些。许多开发者都是从技术的角度来考虑 SOA ，因此相信 SOA 只是一种新的分布式架构或者是一种新的 EAI 方式。起初，我也兴奋的认为将 BPM 和 SOA 结合起来是伟大的想法（两种以 EAI 为目标的技术整合在一起），以流程的方式整合服务，这是比 ESB 的想法更加先进的主意。然而，随着研究和实践的深入，我越发觉得 SOA 和 BPM 结合带来的好处远不止于此。

1.1   我们做了什么？

我们 JPort 团队主要研究了 IBM 的 BPM 和 SOA 方法论，并结合了企业管理中的一些方法，又融合了软件开发领域几十年的模式和最佳实践，对于我国南方某大型港口企业的业务流程进行了优化，并基于优化的流程设计了 SOA 风格的 IT 系统。

我们的主要工作包括：

1 找到了从企业战略到业务操作具有完整映射的组件模型方法论—— IBM 创造的 CBM （组件化商业模型），设计业务组件模型；

2 引入了企业价值树模型从企业战略出发推导出业务流程的 KPI （关键绩效指标）；

3 结合既有的业务流程优化模式， CBM 方法论，企业价值树模型，创建了一套业务流程重构方法论，包括业务流程 Bad Smell ，重构名录，以及评估测试模型体系；

4 利用用例对企业的既有业务流程和业务规则（包括国家法规和企业内部的规章制度以及其他更为细节的业务规则）进行了详尽的调研；

5 通过使用 IBM Websphere Business Modeler （ WBM ）对那些画在纸上或 Visio ，甚至是 Rational Rose 中的现有业务流程模型（ AS-IS Model ）进行了重绘，并利用其按照我们提出的业务流程重构方法论进行业务流程优化，得到未来的业务流程模型（ TO-BE Model ）。在 WBM 中，我们可以为组件（在 WBM 中每个流程任务都是一个组件）的一些特别的事件属性赋值，并将那些由企业价值树模型推导出的 KPI 设置在相应的组件上；

6 利用 IBM 的 SOMA （面向服务建模和架构）方法论识别，规约和实现服务；

7 使用 IBM Websphere Integration Developer （ WID ）来设计和开发 SOA 系统。其中除了包含一般服务，业务流程服务，人员任务服务，状态机服务和业务规则服务，还包括与第三方服务（无线通讯服务，消息服务以及金蝶财务系统， AIS 等）的交互，与远程 RCP （ Rich Client Platform ）客户端的交互，以及遗留系统集成；

8 将系统部署在 IBM Websphere Process Server 和 IBM Websphere ESB 之上，并通过企业 Dashboard 监控之前在 WBM 中设置的 KPI ；

9 提供了一份完整的投资回报分析报告。

1.2  本文提供什么？

在针对该大型港口企业信息化项目中，我们遇到了一系列的问题，在理清了 SOA 和 BPM 、企业信息系统这几个大的主题纷繁复杂的知识结构，以及 IBM 在这些领域的众多概念之后，对关于这些主题的如下问题进行了重新的审视：

两个首先被提出来的大问题是：

  1 从企业角度看 SOA 和 BPM ， SOA 有何不同？

      2 SOA 如何帮助企业进行业务流程管理？

大量的文献都在讲解什么是 SOA ，然而关于它究竟有何不同的讨论却难以具有说服力。本文试图结合理论和实践，规范与实现来说明实战中的 SOA 和 BPM 是如何相互作用帮助企业提升企业绩效，满足企业核心战略，以及实现 ROI （投资回报率）。

2      从企业角度看 SOA 和 BPM

2.1   SOA 有何不同？

正如前文所说，理解 SOA 一定要站在企业的高度，与其他方法学和技术相比， SOA 具有以下特点：

      1 SOA 是一种架构模式（现在来看，其应该是一整套方法论），而非一个产品。

      2 SOA 比过去的任何 IT 技术都要更关注企业，其中的服务应该是指业务服务，或者说企业服务，而非具体技术提供的服务，注意这是一个识别和设计服务时选取视角的问题。与领域建模中所提到的服务区分比较困难，因为对于这两个概念的理解因人而异。

      3 SOA 比过去的任何 IT 技术更加强调抽象、关注点分离，也更加强调基于标准和规范，平台中立，技术无关，这与计算机科学的发展是密不可分的。

   

SOA 绝不仅仅意味着企业应用集成（ EAI ），也绝不仅仅就是一种分布式架构，与 JEE ， .Net ，以及更早的 CORBA （公用对象请求代理（调度）程序体系结构 Common Object Request Broker Architecture ） 等技术相提并论。

SOA 的革命性之处在于其把企业定义为提供服务的组织，服务提供的单元作为组件，就像 OO （面向对象）是革命性的一样（也不仅仅只是一个编程模型）。在从面向过程、结构化方法论向 OO 迈进过程中（其间还经历过很多的开发范型），我们需要改变过去以机器指令看待业务执行的思维，而应以对象来建模业务。而 SOA 中，则需要我们从更加宏观的企业关注点出发，其最高纲领当然就是企业战略了。

在 1.1 节中我所提到的那些方法论，相辅相成，浑然一体，完成了一个从企业战略逐步推向 IT 实现，又以 IT 实现帮助企业监控企业绩效，从而调整企业战略的过程。在环环相扣的 BPM 和 SOA 解决方案中，可以更好的体会， SOA 中的服务，是如何从企业的高度得来的。   

2.2   Component Business Model

CBM 是 IBM 提出的以组件方式重新理解企业的方法论，在这个方法论中，包括三个主要步骤：洞察，架构和投资。其中最为重要的就是设计业务组件模型。

业务组件模型就是将企业中那些使用了相似的资源（人员，技术等）的类似活动聚合起来，其实这一概念和好处是非常容易理解的。快速理解这一概念的好方法是（我们就是这样做的），把企业的流程搜集起来，然后使用 Excel 将 每个流程作为一列，然后行表示业务活动，你可以将那些相同的活动（不同的流程总是会共享一些共同的流程活动，比如付款，计费，查询订单号）放在同一行，给 他们起一个名字，这个名字就是服务名，然后在将一些看上去属于同一类的活动用一个彩色的方块围起来，这就是一个业务组件了。企业的组织结构将帮助你设计业 务组件，然而对于大型企业进行分析，你就会发现其中存在很多冗余、重复甚至是莫名奇妙的组织单元或职能部门，因此需要注意的是，不要让糟糕的组织模型限制 了设计业务组件的思维。

CBM 将组件放在一个二维矩阵中，横轴是责任等级，纵轴是业务能力，交点是业务组件。责任等级与我们在信息管理专业课本上看到的那个信息系统分级是一致的， CBM 中定为 Direct （引导）， Control （控制）， Execute （执行），对应的信息系统分级实际上就是战略层，战术层和操作层。其中 Control 主要完成的是业务的监管，包括一些分析，报告等内容。

按照 IBM 的官方说法 ⁷ ：业务组件包含五个方面，分别是业务用途，活动，资源，治理模式和业务服务。如果你使用过 WBM ，那么看到活动，资源和业务服务一定会感到兴奋，如果这些直接转成 IT 设计，那么我们就完成了一次从业务直接映射到 IT 的过程！而其中的业务服务，就是我们在 SOA 中的服务的一部分（因为还包括其他两类来源的服务，见 2.3 节）。

2.3   Service-Oriented Modeling Architecture

IBM 的 SOMA 方法论主要就是用来识别、规约和实现服务的。识别服务主要有三种方式，第一种就是分解业务领域，其实这种方法可以借助 CBM 来完成，还记得前面所说的业务组件包含的业务服务吗？那个业务服务实际上就是这么推导出来的。第二种就是基于对既有系统的分析（这也是 SOMA 方法论中包含的一个活动），在已有的系统中（这些系统不久就变成遗留系统了），提供了哪些功能，完成了业务，这就是服务了，第一种方法叫自顶向下，第二种方法叫自底向上，而第三种方法当然就是从中间向两边了（没有创意的 IT 理论界）。这种方法就是从其他方面考虑一下，有没有落下的服务。

第二个步骤是制定服务规约，包括接口签名，数据对象，组件设计等。列举出的就是最重要的。其实这些设计的原则以及模式，大都可以来自于过去分布式系统的经验，而对于服务识别，我们亦可参考分析模式，我主要参考的是 Martin Fowler 的《分析模式》。在实际项目中，我主要需要研究计费模式。服务是通过接口暴露的，而由组件来提供相应的服务实现。这没什么特别的。而数据对象设计，这里的数据对象并非单指持久化对象，也非表现层数据对象或者数据传输对象（ DTO ） ¹ 、值对象（ VO ） ² ，而是指贯穿于各层之间的数据对象。这些数据对象就是 Pure Data Object ，只有属性没有方法。

第三个步骤就是决策服务的实现。每种服务究竟该如何实现，是自己实现还是封装遗留系统提供的服务 / 第三方服务（映射已有 / 外部服务），自己实现是新建 Java 服务，还是流程服务（包括状态机），或是人员任务，抑或是业务规则。

从这套思想的步骤我们就可以看到，从来自于业务域（其来自于更高层的企业战略分析）识别出来的服务，到规约上的设计，以及最终的实现决策，充分的体现了， SOA 方法论中更加注重从企业出发和关注点分离这两个特点。换个角度，由于当前 IT 技术以及计算机科学的发展，才使得我们可以如此轻松的实现从业务到 IT 的映射。下面就来讲一下技术标准，以及它在现实世界中是什么样子的。同时，也可以体会一下思想，理论，技术与实现是如何很好的结合起来的。

2.4   SCA/SDO 规范与实现

就在我搁置对于 SOA 的研究有半年之久的时候，忽然打开互联网，发现 SOA 已经有标准了，那就是刚露头角的 SCA （ Service Component Architecture ）和 SDO （ Service Data Object ）。因此，在 SOA 有何不同的论述中，我尤其强调了 SOA 注重标准和规范这一事实。

SCA

SCA 是一个 SOA 的编程模型，就好比 JSP 是 Web 开发的一个编程模型一样， Web 是一种架构模式，而 SOA 亦然。 SCA 有很多部分组成，核心理念是 1 ）将业务功能作为一系列的服务而提供， 2 ）将这一系列的服务组装起来。 SCA 致力于创建服务组件，以及解决各服务组件间的多技术互访问题。 SCA 的核心工件是组件（ Component ）。 ⁵

如果想要问 SCA 与其他诸如 JMS 、 CORBA 这样的编程模型有何不同，我觉得 IBM 的 Barcia 和 Brent 给了我们最好的答案： SCA 向您提供一个以与技术无关的方式定义接口、实现和引用的模型，从而使您能够将这些元素绑定到所选择的某一技术的特定实现。 ³

OK ，当我们谈及组件或对象时，无非要涉及这么几个抽象关注点（如果你认同每个实组件或对象都要将接口与实现分离的话）：其接口是什么，实现是什么，以及其依赖了什么（依赖的组件或对象当然又包含接口和实现）。 SCA 则把关注点分离发挥到了极致，接口，实现，以及引用都是可选的。如图 2.4-1 所示。

图 2.4-1 SCA 组件模型

于是在 SCA 规范中 ⁵ ， SCA 当前支持接口类型系统包括： Java interfaces 和 WSDL （ WSDL 1.1 portTypes 和 WSDL 2.0 interfaces ）

而对于实现，则可以包括 Java ， C++ ， BPEL 流程， Web Service 以及 SCA Composite 。在 IBM WID 中可以选择实现（ generating implements ）为 Java ， Web Service ， Process ， State Machine ， Rule ， Human Task 等。 Process ， State Machine （特定的 Process ）由 BPEL 技术支持。

当 SCA 模块（在 SCA 规范中即 Composite ，在 IBM 的产品中被称为 Module ）被导出（作为服务），或者需要导入其他服务时， SCA 中还可以指定要访问服务使用的机制是什么。这是通过 Binding 实现的。由于导入、导出都是抽象概念，因此需要绑定通讯机制。

通过 Binding ，来指出想要调用服务和服务被调用时的访问机制，包括 SCA ， JCA ， Web Service ， JMS ，无状态会话 bean 等。

OK ，接口，实现， Binding ，引用，全是独立变化，自由组合的，全面的灵活，与技术无关。前所未有，这就是 SCA 。

 

在 IBM 的实现版本中，可以借助 WID ，很方便的开发 SCA 程序，并且提供了很多便利的扩展。比如谈及实现问题时， IBM 提供的诸如 Process ， State Machine 之类的实现类型。

SDO

SDO 是一个数据应用系统开发框架，它包括架构和 API 。它在 SOA 系统中充当抽象数据。 ⁶

SCA 规定了怎样编写 SOA 程序，组件、服务、引用等都是如何定义的，以及它们之间如何通讯，而且还规定了如何传递数据，数据的类型可以有很多种，但是首选 SDO 。

那么 SDO 又是如何超越以往任何技术或规范实现技术中立、平台无关的呢？没什么令人惊奇的，做到这些无非就是增加中介和中间层次，将不同的关注点隔离。 SDO 客户端通过 SDO 框架工作在 SDO 数据图（ Data Graph ）之上。数据图中包含多个数据对象和改变摘要（ Change Summary ）。 DMS （数据中介服务）访问数据源，即 DMS 负责从数据源创建数据图，并且基于对数据图的改变更新数据源。

如果想要更新 SDO 数据，将如何做呢？首先 SDO 客户端（即 SDO 应用）遍历数据图，修改其中的数据对象，然后将修改的数据图传回 DMS ，然后 DMS 根据修改的数据图更新数据源。

可以看出，正是由于有了数据图和数据中介服务这两个隔离，才将具体的数据源与 SDO 应用分离开，而由 SDO 框架来做出相应的转换。

IBM 对 SDO 进行了扩展，就是所谓的 BO （ Business Object ）。

阅读和理解规范，并且与具体的实现产品联系起来，可以更好的理解 SOA 思想。

BPEL

BPEL 是用来编排流程服务的规范，这里的服务技术是 WS*- 堆栈的 Web Service 。 BPEL 规范中详细的定义了如何引入 Web Service ，其中包含的各种活动（诸如 Invoke ， IF ， Scope 等）以及如何建立引用。在规范中，对于引用的其他服务称为 Partner ，可以看出，这样的说法更贴近于业务层次。 ⁴

 

正是由于 SCA 、 SDO 这样的将抽象发挥到极致的规范，使得我们可以按照 CBM 、 SOMA 方法来设计 SOA 系统。我想使用一下 WID 来进行 SOA 系统的开发，将使你更容易体会我想说的内容。可见， SCA 和 SDO 中规定的组件，服务，接口，数据对象，以及 BPEL 中提到的活动，与之前 CBM 、 SOMA 方法中提到的组件，业务服务，接口，数据对象，和活动，是非常吻合的，而且这是一个前后照应，完整的方法体系。

 

小结

写到这，似乎可以将理论和实践、规范和实现联系起来了，再强调一次， SOA 的思维是从企业业务出发，甚至是企业战略出发，来考虑服务和组件，而不是从远程方法调用（ RPC ），消息服务，或者是分布式对象（ EJB 等）的角度去考虑服务。

SOA 不只是 EAI ，这句话的另一个意思是， SOA 包含 EAI 的部分。前文我提到了，通过 BPEL 和 SCA Composite 这样的技术，我们可以实现系统的集成，企业是流程驱动的，流程是由业务组件组成的，那么我们就可以通过 BPEL 将服务组合起来，或者通过 SCA 将服务组装起来（ SCA 的基本理念之一）。那么，还要 ESB 干嘛？ ESB 在哪？

2.5   ESB 在哪？

ESB （ Enterprise Service Bus ，企业服务总线）继承了 EAI 的思想。我不必重复讲解 Hub/Spoke 和 Bus 这两种拓扑结构。因此， ESB 的出现是为了解决集成问题。

ESB 是 SOA 的一种实现模式，任何接入 ESB 的应用都将封装为服务的形式，其核心是个中介流（在 IBM Websphere ESB （ WESB ）中是通过策略 SCA/SDO 实现的中介流组件），可以在其中设计消息路由，然后由其来完成消息的路由，格式、协议的转换 / 翻译，以及消息的分发。消息路由当然是要按照业务逻辑来设计。两个系统（包括但不限于异构系统）需要进行通讯难道不是因为业务逻辑的需要？这其中的业务逻辑就包括了业务规则和业务流程，不过也有可能就是某个业务需求，需要对两个系统进行消息转换。

可以简单的说， SCA+BPEL 就可以代替 ESB 的存在了， BPEL 可以充当中介流，只不过它更为强大（尤其是 IBM 将 SCA 作为 WESB 的编程模型之后，这进一步模糊了直接使用 SCA 和使用 ESB 的界限，如果说状态机是 Process 的一个特定实现，那么 WESB 就是 SCA 的一个特定实现了）。但是如果仅仅是想做 EAI ，或者尝试用 SOA 的方式做 EAI ，而不是如我前文所讲，采用一套完整的、从业务到 IT 的水到渠成式的 SOA 解决方案，则采用 SCA+BPEL 会面临更加复杂的学习曲线，虽然我认为它是更好的实现。

3       BPM 与 SOA 互动

     BPM 是从 BPR （业务流程重组）发展而来，在大型的企业中，想要实施 ERP （企业资源计划）往往都要经历一个 BPR 的过程，然而想要一蹴而就的 BPR 很 难在大型企业中实现。预先看不到一点好处的改革将会受到巨大的阻挠，因此，一个更好的方式，先将企业的流程监管起来，发现流程运转中的问题，或者那些大幅 度创造价值的热区，然后在对业务活动扬长避短，以提高企业的效率。那么，如果才能有效的监管流程呢？答案当然是数字化业务流程，还记得 CBM 方法论吗？我们需要一套从执行到控制再到战略的、互相沟通的组件。然后在组件之上设定 KPI 和特别事件（执行时间和成本，资源，等待时间和成本，角色 / 人员等）的属性。当企业正常运转时，我们就可以从现场直接搜集到第一手资料，进行企业的监控了。然后根据监控结果进行流程优化。优化后再监控，再根据新的结果优化，如此反复。

    这里就存在两个问题，一个问题是 KPI 如何得来；第二个问题，当发现了问题，并且找到了优化方案后， IT 如何能够快速的随需而变。以下两节将解决这两个问题。

3.1    企业价值树模型

企业价值树可以帮助我们从企业战略到业务流程 KPI 的推导，当然，这不是数学，严谨的推导是不可能的。我们可以先从企业战略主题出发，然后由主题发现企业关键绩效指标，然后在寻找影响这些企业关键绩效指标的核心驱动流程，最终推导出流程的关键绩效指标（ KPI ）。

不得不说，详细完整的 CBM 方法论应该包括这个部分，但是这一方面大概是 IBM 内部的机密，因此我们只能通过引入其他的模型来解决问题。

3.2  SOA 帮助企业数字化 BPM

从 CBM 方法论我们可以看到（你可以回顾本文的相应章节），其核心的业务组件模型包括了活动、资源等，我们也提到过，业务组件是从业务流程中归纳出来的，它们是一个互动的关系。

从概览部分你可以了解到 JPort 团队做了哪些工作，这些工作连起来就是为了利用 SOA 帮助企业数字化 BPM 。

SOA 的方法论支持 BPM 中需要监控业务组件的需求，因为 SOA 的服务是由业务组件来实现的。另外， SOA 也可以满足随需应变的业务要求，就像领域驱动建模一样，基于业务建立的模型，神奇的可以随业务更好的变化。 SOA 的方法论可以完整的更好的以这种方式建模，就像本文始终所演示的那样。

4   结论

    采用 SOA 方法论一定要站在企业的角度去思考问题，具体的、可操作的方法就是 CBM ，更重要的是其中蕴含的思想。首先要了解企业的战略是什么，根据战略再来了解企业的业务，可以通过业务流程建模软件模拟企业流程，分析企业问题。然后俯视整个企业，设计出业务组件模型，并暴露服务。接下来在通过 SOMA 方法识别出所有的服务，之后再考虑服务规约，数据对象模型的设计。最后，才是决策实现的方式，复用遗留系统的功能，引入第三方服务，还是自行开发。当然并非所有的企业应用都有必要采用这样的步骤，比如只是一个新的功能，可以不妨以 SOA 的思想来开发这个新功能，关键是要为企业提供合理的 ROI 。

新的 SOA 编程模型 SCA ，与过去的众多用于 SOA 实现技术相结合，使得 SOA 的思想可以更好的实现，比如复用遗留系统， Web Service 不再是不二法门，诸如无状态会话 Bean ， JMS 之类的应用，亦可无缝的连接到 SOA 系统之中。 SDO 也增加了更多的抽象层次，其目标也更为宏大，这与 JDO 等目标不同。

SOA 和 BPM 结合起来，使得 SOA 找到了新的务实方向，对于企业信息系统而言是大有裨益的。

当然，本文主要是从 IBM ， BEA ， Oracle ， SAP ， JBoss ， Sun 等这些 Java 世界的领导者的视角来看待 SOA ，以它们的产品和理论为基础，然而不得不说 Microsoft 有其自己的一套产品和理念，但是，其根本的 SOA 理论是一致的：以企业为圆点，高度抽象，关注点分离，技术中立，平台无关；另外，就是其亦看中与业务流程管理的整合。毕竟，微软是 BPEL 的缔造者之一。

    一种务实的精神是，开发那些真正为企业创造价值的系统，如果某个业务单元本身就是低效和没有价值的，我们是不是可以考虑一下改变它的运作模式？

 

 

参考文献

1.     Deepak Alur , John Crupi , Dan Malks ， Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) ， Prentice Hall PTR

2.     Martin Fowler ， Patterns of Enterprise Application Architecture ， Addison-Wesley Professional

3.     Roland Barcia ， Jeff Brent ，使用服务组件体系结构构建 SOA 解决方案 —— 第 1 部分 http://www.ibm.com/developerworks/cn/websphere/techjournal/0510_brent/0510_brent.html

4.   Tony Andrews, Francisco Curbera,.etc,2003 ， Business Process Execution Language for Web Services ， Version 1.1

5.    Michael Beisiegel,Henning Blohm,.etc,2007,SCA Service Component Architecture ： Assembly Model Specification

6.     Bertrand Portier, Frank Budinsky,2004, Introduction to Service Data Objects:Next-generation data programming in the Java environment,http://www.ibm.com/developerworks/java/library/j-sdo/

7.     IBM 商业研究院， 2006 ，组件化业务模型：企业实现专业化的有效工具

8.     IBM Business Consulting Services, New competitive weapons in the insurance business: Insurance component business modeling, http://www-935.ibm.com/services/us/imc/pdf/g510-4033-new-competitive-weapons.pdf

9.   Anurag Goel, Enterprise Integration:EAI vs. SOA vs. ESB, http://hosteddocs.ittoolbox.com/Enterprise%20Integration%20-%20SOA%20vs%20EAI%20vs%20ESB.pdf

 

不自量力,来评论两句.
纯粹是纸上谈兵.基本上没有啥实用价值.
在企业信息化开发中,最重要的因素,其实不是技术,不是业务,而是人.
企业是由不同的人构成的,各个部门也是由不同的人构成的,所谓的业务流程也都是由人来组成和驱动的.
不同的企业,运行流程完全不一样,是因为他们的历史不同,人员不同引起的;同一个企业,同样的事情,有时这样处理,有时那样处理,因为对应的是不同的人.
同样的职位,这个人这样做是可以的,另一个人这样做是不行的,因为人和人是不同的.
IBM这些业界巨头,巨忽悠,他们提出的种种理念也好,概念也好,方案也好,都有一个基本的假设:所有的企业都是一样的,因此可以用一个统一的方法论,统一的解决方案来解决这些问题.具体到执行路线上,就是搞一个巨复杂无比的解决方案出来,结果在实施的过程中,所有人的注意力都被引到如何使用这些庞然大物上面去了,而对于自己原本要解决啥问题,时间长了,就忘的差不多了.
等到醒悟过来,木已成舟,有苦都没地方去说了.
------------------------------------------------------
就说SOA这东西吧.
它究竟是指业务流程的分析方法呢?还是指开发的分析方法呢?说不清楚,很多文章都在混淆这两个概念.
第二个是文中的CBM的概念,这个概念也存在上面的这个问题,究竟是用来分析业务流程呢,还是用来开发设计呢?概念本身在文章里面多次发生偏移.
-------------------------------------------------------
无论和企业谈啥SOA,任何新概念,都有一个额外问题.
问题就是: 开发商究竟是给企业提供何种服务的?或者说,到底是来干啥的?
为啥有这么奇怪的问题呢,是因为上文中提到了KPI的概念.
而且还说到了如何抽取KPI的方法.
正确与否先不论,这个根本就不是软件开发商的事情,是企业自己的事情.
--------------------------------------------------------

以前在项目接触过少少的ESB，目前为止，花在websphere6.0上维护webservice的代价是很高的。
   它里面定义的什么概念、工作流程是不敢在项目中使用，咱们项目组人不才，太难掌握了，虽然有IBM的工程师过来培训咱们，但谁也不敢保证用了这东西会出现什么，怕被套牢，培训是要按小时收费的。我们是乖乖的凭经验自己弄整一套山寨版。
所以只用到一部分,接口的定义，然后就是跨省的联调（漫长的等待时间）
对这个了解甚少。

不了解 曾经借了本ibm的讲soa的书  上厕所看  看了一个礼拜没明白

以后多上厕所就能搞明白了

文章的标题“大型企业信息化中的BPM 和SOA 实战”和文章内容在很大程度上不一致，“实战”这个词汇在文章没有很好地体现出来，文章讲得最多除了一些SOA,BPM,ESB,SCA,SDO,BPEL的概念之外就是再说这些概念之间的相互关系了。如果真是站在“实战”的角度来写文章，那么可以将如何具体实施SOA和BMP写出来，这样对读者更加有实际意义。

 

     一共就是这几个步骤，然后具体的方法是在之前的介绍里，比如通过企业价指树模型从企业战略推导出业务流程的KPI（如果你有业务流程优化和大型信息系统总体规划的经验那么会很容易理解这件事的重要意义），通过CBM方法确定业务组件并暴露服务，然后通过SOMA方法识别、规约、和实现服务。具体在每节中都有详细的并且是可行的步骤。

     因为这不是讲编程，怎么通过一篇短文写实战，还请赐教（因为我觉得可行的步骤已经代表实战了）~

    我觉得哥们儿的话说的太搞笑了，我看过《人件》~~~

 

 

 

    我在做项目的时候，比较看重的是理论和实践的结合，IBM的RUP背后是有很深的理论和行业最佳实践的，迭代，用例驱动，面向对象，这些东西体系都很繁杂。但是，我的体会是，当真你做一个大系统，你可能刚开始用自己的方法，然后最终你可能会发现，你自己摸索出了的好多东西，在RUP中都已经有了。之所以会觉得把关注点都引入到那个庞然大物上，原因就在于你的经验太薄弱了，如果你有很丰富的经验，根本不会觉得的它复杂。

    还记得刚开始写用例时，Cockburn的用例模板实在是太多Item了，觉得很多都没用，而且格式也不是我们习惯的，然后我们就做了一个简化版本，然后随着我们需求的探讨逐步的深入，越写越复杂，然后不断的添加Item，最终发现，Cockburn的模板就是个最实用的集合，所有项目都是必要的！

    然后就是学习IBM的CBM，SOMA方法，学习IBM的WID，好几千页的文档，但是真的用起来，发现真的每一项都那么重要。

    之所以复杂，是因为我们本身的领域就很复杂，软件业就是如此的复杂！

 

 

    业务流程分析的方法是在BPM范畴之内的，SOA是一种开发范型，一种架构风格，和一套技术规范。

    不知道您是不是知道结构化方法论，其中分为结构化分析，结构化设计，结构化开发等环节，其中系统分析中包括业务流程分析，请问结构化方法论是用来干什么的呢？

    我们的团队做两件事情，第一件是 帮助企业用IT系统优化业务流程 第二件是 基于优化了的流程构建IT系统。

    归根结底是我们要利用IT技术为企业创造卓越的ROI~~~