1. Process Platform带来的价值

OpenText Process Platform平台是完全建立在标准、前瞻的架构之上，从一开始就设计成业务运营的支撑平台。用户可以利用该平台的SOA架构和完整的BPM能力，将后端系统开放出的共享服务组合在一起，构建完整的业务运营环境。

Process Platform的解决方案帮助企业搭建一套具备完整多中间件能力的综合性平台。不仅能够帮助企业完成诸如系统集成、业务流程管理等常见的企业级平台功能，能够将业务上确立的模型原原本本地落地执行，做到业务与执行的真正统一，更为重要的是，该平台可以作为企业IT信息化架构中的骨干平台，使得企业整个信息化架构在未来5-10年的长期演进过程中保持稳定坚固的架构体系以及灵活应变的扩展性和伸缩性。

1.1 选择Process Platform的理由

1.1.1 稳定、可靠、具有极强的性能伸缩性

作为重要的企业级平台，稳定性、可靠性、以及性能伸缩性是大型企业的首要特性。这也是为什么像中国联通、中国移动、中国商飞等众多国内外企业选择OT Process Platform的原因。

OT Process Platform拥有什么样的技术，使其能够在众多竞争对手中脱颖而出，获得这些对稳定性、可靠性、以及性能伸缩性要求极高的企业的青睐呢？

首先，Process Platform采用多进程组的应用服务器架构，相对于传统基于J2EE或者.Net单一进程的应用服务器架构，具备更稳定、更易于伸缩、更可靠的特性。

传统基于单一进程应用服务器架构的应用或者平台需要将所有相关功能放在一个应用服务器实例中运行，即一个JVM进程中运行所有功能。无论如何进行伸缩性部署，任何一个JVM上都要部署和运行所有功能。也就是说，单个JVM进程需要同时执行页面渲染、流程或者集成逻辑、相关的数据库操作、集成API调用等各种复杂多样的任务，如下图所示。

这样做会带来两个主要问题：

第一、 对于单个JVM来说，需要它执行的任务过于繁重，所有类型的任务都需要跑在一个JVM上。我们可以想象一下，如果像Process Platform这样的综合性平台，同时提供那么多中间件能力，在加上相关的管理、监控等功能，那对于一个JVM来说就过于复杂了。我们都知道一个简单的道理，那就是任务越复杂和繁重，就越容易出现稳定性问题。这就是为什么迄今为止，除了Process Platform之外，没有其它产品可以仅仅通过一个一体化平台就可以提供多中间件的综合性平台。

第二、 伸缩性也会出现局限性。如果集群中某个JVM发生问题，那么整个集群的性能会急剧下降。原因就是单个JVM进程会承载所有功能。举例来说，一个双应用服务器实例（即两个JVM进程）组成的集群，如果其中一个发生额问题，那么性能会下降至少50%。如下图所示

基于针对上述问题的考虑，OpenText Process Platform采用自己独创的多进程组的架构体系来搭建相关的应用服务器。

其中的道理很简单，就是化繁为简，虽然仍然使用JVM作为任务的执行容器，但是由原来单一JVM进程执行所有类型任务，转化为多个JVM进程组共同完成整个平台的所有功能，而每个JVM进程组仅仅负责其中一项任务类别。如下图所示：

我们可以看到，Process Platform中有用来执行页面渲染的JVM进程组，有负责执行流程流转的进程组，也有负责执行数据库事务的进程组、执行针对某个系统集成调用的进程组，等等。

这样做的好处在于：

第一、 每个JVM进程所要执行的任务变得非常轻量，因为其所在的进程组只需要执行一类任务。越简单就越稳定，因此大大降低单个JVM进程出错的可能性。

第二、 整个平台的伸缩性与高可用性也大大增强。在同一个进程组中的不同JVM进程可以部署在集群中的不同计算机上，也可以部署在同一台计算机上。管理员只需要点击鼠标来自由选择如何部署这些JVM进程。一个进程组中，很少出现所有进程都出问题的情况。因此，即使某些个别JVM进程出现问题，应用也不会发生停车事故，而且性能也不会大规模降低。如下图所示

其次，Process Platform的关键执行引擎，如流程引擎、规则引擎、XML解析引擎等均采用C语言实现，执行效率相对于基于传统应用服务器（如J2EE、.Net等）的解决方案来说得到了大幅提升。

最后，由于Process Platform是一体化平台，各个模块之间采用统一的技术体系和数据传输方式，因此数据在各个模块之间传递时，不需要进行打包拆包。而市场上有许多同类产品，如I公司、O公司等，由于各个产品模块之间的架构体系不一致，因此数据在不同产品之间传输时，需要不断的打包、拆包，这个过程也会造成系统还大的性能损耗。

因此，在相同的硬件配置下Process Platform可以带来更高的处理性能。

更重要的是，由于采用了Process Platform独有的无状态信息连接与含状态信息XML对象的技术，使得Process Platform消除了传统分布式体系架构中必须维护系统间连接状态的开销，从而在Process Platform服务器数量增加的时候，整体性能不会出现衰减，而恰恰相反，整体性能会呈现线性增长的趋势。

随着Process Platform服务器数量的增加，其整体处理性能不会出现衰减，而是呈线性增长。

1.1.2 集SOA（ESB）与BPM于一身的一体化平台，拥有极为经济的安装、维护、与扩展性，适应企业长远的发展要求。

首先，从平台构成来看，Process Platform可以提供相对完整的多中间件能力。

我们可以清晰地看到Process Platform具备的SOA、BPM以及快速应用开发的多项企业级平台能力组件。

其次，Process Platform是通过一个一体化平台提供上面提到的关键中间件能力，而不是由不同产品拼凑出的方案。因此具备更轻量级的平台方案，更容易安装、维护、升级、扩展等，以最小化的IT团队投入换来最大化的IT信息架构优势。后文还会对此专门进行讲述，请参见后面的Process Platform一体化平台与其他非一体化平台的比较。

1.1.3 多租户的企业级平台，适合平滑向众多分支机构拓展

对于需要拓展众多市场的企业，Process Platform的多租户特性可以不借助任何虚拟机，就可以从安装好的实例中创建其它租户，这些租户如同自己安装部署了一套完整的平台，拥有所有平台的中间件能力，而且彼此有着严格的权限和数据隔离。这样的特性带来的好处包括：

1. 各个分支机构在不增加硬件和软件成本的前提下，各自拥有独立的平台空间，即租户，拥有自己的权限管理与数据存储。

2. 企业可以在平台上统一部署所有分支机构共享的标准化流程或者业务逻辑。这种SaaS模式的应用只需部署一次，就可以在所有分支机构的租户内执行。但是业务数据和权限都是各个租户彼此隔离的。

3. 企业可以在特定分支机构内重载或者个性化相关的业务流程或逻辑，以适应该业务在相应分支机构内的个性化需求。但是这种个性化改变仅限于相应租户内，不会影响其它分支机构的租户。

综上所述，这种多租户的特性，可以让企业将业务平滑拓展到多个分支机构，既可以强制标准化，又可以应对个性化。

1.1.4 经过多年市场检验的成熟平台

Process Platform自2004年开始，在全球范围内获得了众多注重稳定性、可靠性、以及性能伸缩性企业的青睐，这其中就包括中国联通、中国移动、中国商飞、工银租赁等国内大型企业。

1.1.5 实现跨部门、跨系统的端到端业务流程

能够帮助企业建立完整的流程体系，从价值链模型（描述与上下游企业的业务关系），到业务环境模型（描述自身企业的业务划分），一直深入到可执行的具体业务流程，层层关联、层层掘进。并且在完整的端到端流程中既可以包含自动化任务，也可以包含人工任务。因此，在业务人员完成业务模型之后，技术人员不必对其进行拆分，形成独立的人工工作流和自动化流程，因此可以做到业务与执行的一致统一。

1.1.6 编排源自不同系统的业务功能和接口

为不同系统接口的维护提供性能上的线性伸缩性、扩展性、高可用性、负载均衡、以及集群等企业级应用所需的基本保障。

1.1.7 快速实施跨系统业务解决方案，并提供高附加价值

Process Platform 平台可以大大缩短跨系统、跨部门业务解决方案的实施周期，而且可以让具有不同技术背景（如SAP、.Net、J2EE）的技术人员协同工作，能够更快、更容易的实施跨系统项目。

1.1.8 轻量级的一体化企业平台

Process Platform的轻量级主要表现在：1）全B/S架构，只需在服务器端安装，不需在客户端安装任何设计工具或插件，就可以通过浏览器方便地访问平台上的功能，并进行业务流程的建模与开发，因此易于维护与升级；2）只需一张光盘，在半小时内就可以完成整个企业级平台的安装，安装过程简单。不需购买多个模块，并进行复杂的安装过程。一体化特征表现在：1）Process Platform在一个平台上就包含企业业务所需的建模、执行、监控、与优化等功能；2）建模环境的一体化和执行引擎的一体化，省去了许多不必要的模型拆分、导入、导出、监控信息汇聚等步骤，大大降低了平台的复杂度和学习曲线，缩短了项目周期。

1.1.9 实现业务流程的集中管理与维护，并符合业界开放标准

在Process Platform平台上建立的业务模型最终会成为企业的流程库，供企业在实际应用中依据实际情况自由取用。另外，以图形化模型表达的业务流程存放在集中的区域，也会大大降低日后的维护复杂度。相比之下，以代码方式编写的业务逻辑不仅分散、难于管理和维护，而且难以调整，因而无法满足企业长远的业务发展要求。符合开放标准对企业是非常重要的，因为如果采用私有标准的解决方案，不但难以与其他系统兼容，而且在私有标准系统上实施的解决方案今后无法移植到其他平台。

1.1.10 让业务管理人员及时获得关于流程状态的实时信息

Process Platform支持跨部门、跨系统的业务流程运行，所以能够提供全面、实时、端到端的企业运营状况信息。帮助企业管理人员随时通过直观的KPI图表掌控业务进展情况。

1.1.11 允许企业充分利用新的计算服务

Process Platform平台完全基于SOA架构，允许企业将任何计算资源转换成一个共享服务，并将其提供给企业内外的用户和系统使用。由于将业务流程与接口代码彻底解耦，使得企业可以在不需要调整现有业务流程的情况下，对现有系统进行升级、替换，或接入新的计算资源。

2. Process Platform一体化平台与其他非一体化平台的比较

市场上有许多同类产品，如I公司、O公司等。虽然就功能来讲，他们都可以提供BPM完整的功能，但是需要用户从不同的产品线中采购不同的产品，如I公司，需要从Tivoli、WebSphere、FileNet、Rational、Lotus等产品线中选择购买相应的产品；而O公司则需要从其BPA套件、Process Manager、以及并购的BEA产品线中选择产品。

这样，在实施完整端到端业务流程项目之前，必须在这些产品之间先行进行集成。而且各个产品的实施顾问也只局限在各自的产品模块中，因此需要相对较多的实施顾问才能覆盖到完整的知识领域，保证项目顺畅进行。而且，各个产品之间的功能重复现象很严重，造成用户投资的浪费。

另外， 由于各个产品模块之间的架构体系不一致，因此数据在不同产品之间传输时，需要不断的打包、拆包，这个过程也会造成系统还大的性能损耗。

而Process Platform的一体化平台则可以很好地避免上述问题，让整个项目变得更容易实施。其区别具体体现在：

2.1 Process Platform VS I公司

I公司虽然拥有庞大的产品线，但是与Process Platform相比：

为了实现完整的BPM解决方案，I公司需要众多产品的组合，从而带来更贵的价格以及更长的实施周期。Gartner认为：“there is no unified product experience for any role engaged in the process improvement life cycle.”

业务流程建模与流程执行的分隔造成了很多问题。最大的问题在于，业务人员建立的业务流程模型无法直接100%映射到基于BPEL的流程服务器上（例如，WPS具有自己的人工工作流扩展）。

建模与执行环境的分离造成流程的更改极为困难。这使得业务人员和高层管理人员难以从动态的灵活的BPM中获得收益。

用户界面的开发工具彼此脱节，并且需要大量的开发工作量，可能需要的开发工具有 Lotus Forms, WebSphere Portal 和 JSF 工具。

I公司 WebSphere的业务规则引擎功能非常弱，例如，不支持规则嵌套，不支持规则链等。I公司新近收购ILOG，但是尚未整合。

与FileNet的集成非常弱。FileNet BPM的路线图尚未明确，因此给潜在的客户造成不确定性。

I公司 缺乏一些必需的BPM的功能，例如，组织架构建模，流程发现，基于活动的成本计算等等。

同样是完成端到端的业务流程实施项目，使用Process Platform要比使用I公司更快捷、更迅速、而且跟简单，如下图所示：

2.2 Process Platform VS O公司

与I公司类似，O公司也通过不断并购别的公司和产品而获得庞大的产品线。与Process Platform相比，O公司：

缺乏一体化的设计环境。业务人员和开发人员能使用的工具不同，双方的协同工作将受到限制；

总体的用户体验为传统的开发方法论，而不是模型驱动、协作和敏捷的方法；

模拟功能只能使用BPA套件在设计阶段支持。

缺乏一体化的运行环境。不同类型的业务流程需要在不同的引擎中加以执行，这样会带来模型同步与导入、导出等麻烦。

Fusion中间件非常复杂难用，即使是有经验的技术人员也很难熟练掌握。

重量级的架构体系。由于完全基于J2EE，从而继承了J2EE复杂，集群可扩展性不高的弱点。

2.3 Process Platform VS 某国内厂商

大多数国内厂商一般都面临研发不够深入，基于开源内核外包一层UI的问题。这些方案可以作为小工具使用，但是如果作为企业级骨干平台使用的话，将会面临稳定性、伸缩性等问题。与Process Platform相比：

 无法提供一体化平台，集成往往局限在API调用层面，增加其他核心功能负担，而无法做到用进程组来分摊复杂任务

 由于应用使用开源内核，因此产品支持出现问题时，只能依靠开源社区来解决内核问题

 如果需要达到企业级支持，需另外采购稳定可靠的独立应用服务器，无形中又增加了整体解决方案的厂商复杂性，发生技术问题时容易发生互相推诿扯皮的情况

 由于内核基于开源方案，很多时候在应对复杂流程场景时力不从心，如很难在一个流程中提供两种以上的表单

 缺少Case Management方案