BPM 融合SOA提升业务价值，建立敏捷型企业（bpmf宝拉）

1          概述

对于建设敏捷型企业，企业业务流程管理（BPM）和面向服务的架构（SOA）无疑是近几年来非常热门的两大话题。

SOA 和 BPM的倡导者都提出了在保护企业现有投资的情况下，通过构建灵活的低成本的平台，及项目的可重用性，来满足企业业务不断变化的需求。通常情况下SOA和BPM被分开讨论，并且两者都被授予了很多类似的价值，所以比较容易引起困惑。但是实际上是SOA 和BPM的中心思想是不同的：SOA关注灵活的架构方法，从而能够跨越多个维度进行应用；BPM关注如何协调、优化实际企业业务流程活动的进行，是一种管理理念。在过去的几年里，SOA被广泛的讨论，本文的重点不在于深入的讨论SOA，而是在于阐述SOA和BPM的关联关系，BPM对于SOA的影响，反之依然。

本文将分别概述BPM和SOA各自的特性和价值，然后探讨如何将融合他们，从而带来更大的价值。

2          业务流程管理（BPM）

2.1       什么是业务流程管理？

对于许多的BPM从业者来说，BPM首先应该是一种管理学科，是一种基于动态，自动的优化业务流程来达到业务目标的新的思考业务的方法。通常情况下这些活动由跨越多个应用系统和组织架构的端到端的流程组成，这也正是为什么BPM会面临如此多的挑战和难以置信的价值。

虽然BPM这个名词是在2000s左右引入的，但是支持现代BPM管理理念的方法是存在已久的。BPM的倡议来自于贯穿80年代，90年代的如Total Quality Management(TQM),Business Process Reengineering(BPR),及Enterprise Resource Planning (ERP)等领域，这些领域都致力于通过考核，重组，自动化及其他的一些技术来提供企业业务的效率。

早在上世纪90年代初，BPR就开始关注提高企业的业务流程，通常为结合使用一些临时工具的管理策略理论，并没有清晰的关注自动化。BPR的理念是通过破除过期的，低效率的流程，从零开始设计与应用最优化的流程，达到相对较短的时间谌〉眯б孀畲蠡?哪康摹５??/SPAN>BPR的大多数案例都以失败告终，因为完全摒弃企业原有的流程，设计最优化的流程是一件非常困难的事情，因为市场的需求总是不断的变化和前进的。之后的一段时间一些公司就开始普遍部署ERP系统，来管理如财务，采购，销售等。ERP更多的关注在自动化而很少针对具体的公司情况来优化他们特定的各种业务流程。ERP系统的实施带来了在效率和控制方面的明显的改善，但同时也给流程的创建和改造增加了成本，因为他们总是一成不变的。很多本来是设计成希望来优化的流程，反而被系统所约束了，是时候改变ERP的工作方式了。

基于之前的倡议和创新思想，BPM应用了之前的一些教训及承担了其他系统遗漏的功能，来应付复杂的，战略的业务流程的挑战。我们这样来定义BPM:

BPM是一套战略方法，通过循环周期内的建模，执行，仿真，度量过程来持续的对企业业务流程进行优化，从而实现实现自动化管理,优化动态业务,产生真正的商业价值。

如果我们来关注一些行业的公司的成功之道的话，我们会不自觉的谈论他们的业务流程。他们或者是能够快速的迎合市场的需求推出创新的产品；或者能够快速的履行订单，审批贷款，解决客户的疑问等；或者他们的成本出奇的低。商业的竞争优势日益取决于企业的关键流程的执行情况。这也正式为什么BPM及一些帮助企业管理流程的软件最近几年倍受关注的原因。BPM的一个最重要的革新是：融合了特定的管理理论和全面的技术方面。这些技术方法在BPM解决方案的整个生命周期：建模，分析，开发，部署，执行，操作，度量，优化的每一步骤都提供了详细的支持。

2.2       BPM套件应该具有的功能？

做为一门管理学科及一种战略，很明显的BPM不仅仅是一套软件系统。但是软件日益成为BPM 的一个重要组成部门，因为软件可以帮助企业组织认识到BPM的价值和可靠性所在。以下的表格中描述了BPM软件应该具有的功能：

功能描述建模对非开发人员的业务流程建模工具，可以实现端到端的流程建模，设置规则，角色，提供结构化的活动定义支持仿真，分析提供与现有比较的KPIs，来提高项目的准确性和有效性，分析流程的瓶颈，使得流程没有部署到正式环境前对流程进行优化和改进。设计，部署一套集成的开发工具，供IT或开发人员进行活动的设计，对企业各种应用系统的联接。执行执行流程的模型，包括了人机交互流程，分离的各种系统的整合流程，保证流程按照业务规则和公司策略的顺从性及最佳实践。交互一个基于web的工作台，管理员或流程拥有者可以部署流程，最终用户可以管理他们的活动，查看相关流程的KPI指标。集成最终用户的交互环境，起草，审批，批注等，与邮件系统和桌面应用工具的集成。度量业务分析人员可以查看流程引擎执行流程的状况。业务设计人员在模型中设计的各种关键指标的指示器，可以显示KPI极限和仪表盘的警告信息来帮助业务分析人员进行决策。按照各种字段生成的各种统计分析报表监控和审计在引擎运行过程中的收集和整理全面的数据，以供历史数据的审计和实时数据的监控

从上面的表格中可以看出，BPM软件通常提供的一套闭环循环的系统来实现业务性能的提高。业务分析人员不需要了解流程的具体执行和部署技术就可以创建和分析流程。流程分析人员-通常为IT人员但并不是程序员可以对这些模型进行数据的定义和执行情况的定义。设计完成的流程被部署到流程引擎，引擎将任务传递给相关的人员参与者，实现对外部系统的集成操作，对异常过程进行自动处理，流程引擎也会对运行的流程的性能信息进行快照记录，以便这些数据能够被聚合并在仪表盘中进行展示，流程实例的状态能够被监控。实际的运行数据同样可以被反馈到流程建模阶段，以便下一轮的流程优化操作。

很多帮助企业来进流程提高的软件工具已经被运用到企业中。许多的建模工具被运用到企业中进行流程的捕获和编目，但是这些传统的工具存在一个问题就是这些工具和实际的部署环境中的来自动化流程的代码及操作活动序列和流程的监控是完全分离的环境。

这个是我们说的BPM套件不同之处，一个BPM套件必须是一个整合的环境来提供整个生命周期的管理，包含了建模，部署和执行。实现这个目标的一个关键理念是在整个生命周期中“共享的流程模型”，这种整合的方法消除了业务人员需要做的和IT人员真实做的差异问题。

对于IT人员 BPMs意味着部署业务解决方案的一种新的方法，这种方法强调了小量的编码和更多的业务参与。对于业务人员，BPMs意味着一套工具供业务人员从方案修复到主要挑战的参与，与IT人员协作来提高流程的性能。这样的结果是建立了一种从上到下的基于业务流程的实施方法，而非基于IT系统的从下向上的实施方法。

2.3       BPM的关键价值

除了通常所说的一些积极的价值，包括降低成本，增加收益，提高企业的竞争优势之外，实际上对BPM做为一门学科进行投资就等于说是建立了能够快速响应变化的组织。充分利用软件对企业某种业务进行制度化实施可以产生如下的相关价值：

2.3.1        通过分析进行改革

BPM帮助用户对已经存在于纸面上的流程在没有正式的部署资源之前进行改造，通过仿真分析获得项目的投资回报。BPM方面论的第一步就是都流程进行建模，全面的BPM套件能够进行业务分析并且文档化现有的流程并且用结构化的方式定义未来的流程，然后通过仿真分析来定义项目的业务指标。分析人员不需要懂得部署的相关技术细节，只需要定义面向业务的各种参数，比如：谁是每一步活动的参与者，资源成本，每一步的平均花费时间，节点路径的相对执行的可能性等。建模分析给了业务在正式导入开发部署前再思考和简化的机会。

2.3.2        提高操作的效率

BPM 的实施可以提供操作的效率，缩短循环的周期，降低成本，不需要增加人员的情况下处理额外的工作。这些价值来自于BPMs组件中的工作流自动化。流程的引擎将任务路由到使用者，运行他们直接通过基于web的工作台执行活动，管理活动的优先级和期限，甚至对于过期任务和异常任务的自动调整程序。

2.3.3        顺从和控制

BPM帮助提供业务流程之上可控性，形成贯穿企业的标准和遵循各种规则，策略，最佳实践。今日的企业并不是一成不变的，通过合并和收购，新的组织单元会不断的出现，这些组织通常都具有自己的系统和操作规程。因为BPMs提供了一套统一的为IT和业务人员管理流程的工具，可以驱动贯穿企业的标准的操作规程，策略和业务指标，从而保证总是“一个版本是正确的”。流程的模型可以在可以中被共享和重新利用。同时，运行流程中的每一步都有日志的记录，不断可以保证顺从性，而且能够保证顺从性能被很容易的审计。

2.3.4        敏捷度

BPM的第四个价值就是提高企业的敏捷度，帮助企业快速的将新的产品和服务推向市场，非常容易的对快速变化的要求进行响应。在过去的几年里，有关敏捷度的绊脚石是对“IT Backlog”的恐惧……寻找可使用的资源来整合各种业务系统，建设客户web应用，编写代码。BPMs避免了IT的大量的工作，因为BPMs并不依赖于编码。可执行的设计可以快速的被创建和非常容易的被改变。集成的适配器使得对各种业务系统的整合变得简单，无须编码的方式。

2.3.5        端到端的性能可视化及优化

3          面向服务的架构（SOA）

面向服务的架构(SOA)是针对IT架构的一种方法，目标在于对企业中复杂的IT资产（系统，应用，数据库等）进行管理，以便使他们能够方便的被重用，容易的相互整合，能够并不需要破坏依赖于他们的业务解决方案，而容易的持续发展。

面向服务的架构（SOA）是一种IT战略，能够将企业应用中的分散功能组织成基于标准的互操作服务；IT部门可以快速的组合和重用这些服务，以满足业务的需求。

SOA可以作为企业新的架构方案以及对已存在的IT基础设施进行重新架构和简化的蓝图规划。采用SOA后，IT部门可以获得更高的效率，更快的响应时间和更好的敏捷度。SOA是完整的业务方案里一个重要的战略，但是SOA的价值直接作用于对IT的影响，所以SOA战略里一个重要的方面就是如果融合IT和业务的价值作用体现，使得IT的投资可以通过业务上获得的价值来体现。

SOA的实施同样是需要特定的软件技术及工具和框架来使已经存在的系统服务化。SOA方面的软件很多，并不是所有的项目对需要这一系列的软件，针对具体的项目我们需要分析项目中面临具体的问题所在。不管怎样，SOA的产品都需要设计成独立齐全的组件服务，以便于可以方便的相互协作。

3.1       SOA的关键技术

关于创建和管理面向服务的架构，有一系列的相关技术，但是在本文中讨论的是和BPM结合非常紧密的集中关键技术：

3.1.1         服务总线 Service Bus

服务总线ESB位于SOA的中心，充当消息传递的中枢，它提供了强大的服务骨干总线来协调服务之间的交互。一个ESB就好像我们身体里的神经和循环系统，通过分布在血液流里的激素来实现各个器官的信息通讯。ESB通常包含如下功能：

²        服务之间的消息路由；

²        请求者和服务之间的传输协议转换；

²        请求者和服务之间的消息格式转换；

²        处理各种来自不同业务的事件；

²        保证服务质量(安全、可靠和交互处理)。

和BPM相关的，服务总线可以统一的协调业务流程中用到的各种服务。

3.1.2        服务注册Service Registry

服务注册Service Registry用来存储系统(或其他机构系统)中的服务信息，管理服务的生命周期，它帮助实现服务语义和缩小IT和业务世界之间的差距的业务含义，并提供服务的业务级视图。

服务注册能够提供给系统在什么地方发布、寻找、重用服务，从而使得SOA更加透明。

和BPM相关的，服务注册存储了流程中可能遇到的信息如：需要联接的、需要从底层系统中提取数据的或触发系统功能等。在流程设计的过程中，开发者可以在设计环境中浏览服务注册及发现在流程中需要交互的服务。作为流程设计工具的一部分，能够提供接口和数据模型，在流程引擎的运行过程中，能够在注册表中定位到使用的服务信息的位置，同样的流程本身也可以被注册成服务以便方便的被其他的系统和流程进行调用。

3.1.3        服务库Service Repository

服务库通过对元数据（业务流程，web服务，Patterns，框架，应用，组件等）的管理，提供了企业级的软件组织资产的管理。

一个高效的企业服务库可以地图化的方式管理需要联接的软件资产的相关关系和依赖程度，使得资源可以被优化和重用，将变动的影响降到最低。

和BPM相关的：服务库中可以存储和管理部署BPM方案的草稿，流程模型，流程模本，服务组件，数据组件，这些都被服务库统一管理后，将有助于BPM项目组更好的理解这些元素之间的关联关系。

4          融合BPM和SOA

4.1       背景分析

如上图，当我们分析SOA愿景的主要驱动力的时候，我们会发现业务敏捷度话题（如：客户服务提高和快速的进入市场等）是列表中最重要的部分。这就意味着企业在思考SOA战略的时候是期望SOA的投资得到真实的业务利益的。

如上图，SOA 出现主要为了解决IT的复杂度，IT的复杂度阻止了对业务快速变化的响应，但是这些问题对业务本身来说是不关心的。实施SOA可以形成灵活的，可管理的架构，但是可能并不能马上影响到业务层面所以业务人员最初的时候可能并没有看到SOA投资的回报。

因为BPM在SOA出现之前就已经有很多的项目的实施，并且在业务层面带来很多的价值，并且BPMs 系统一般会内置很多的适配器，用于和企业各种核心系统的集成，但是这种集成需要依赖大量不同的专有技术，并且底层IT的变动对业务会带来比较大的影响。

4.2       SOA 和 BPM 融合场景

如上图：实际上发展到今天，SOA和BPM已经是互相促进的状态，SOA的实施隐藏了底层应用程序和数据库的复杂性。将业务流程连接到系统的过程会更简单，因为IT可以公开更有用的接口，比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的IT工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系统所需的技术。对底层IT系统的更改不必影响流程所使用的接口。这样在BPM套件之外提供了一个独立的控制和管理层。这允许IT更好地管理他们所拥有和维护的服务的策略和资源。SOA还支持从BPM套件中获得对它所连接到的系统的更好可见度。IT可以在服务注册库中注册服务，流程开发人员可以在构建流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用，而且通常简化了业务流程，因为使用正确的服务可以将流程本身的复杂性降至最低。同样的通过BPM，SOA可以将价值扩展到业务层面。

当BPM的采用逐渐扩展到整个企业的规模，如何管理单个的业务流程就成为一个问题。第三方的应用如何调用流程？如何控制访问权限和安全策略？如何将业务流程平台对第三方的应用透明化？答案就是SOA。我们同样可以将具体的流程作为服务进行注册。一个服务架构将流程同样看作是一个服务。服务总线的代理会从服务注册表定位到作为服务的流程，这样就使得流程透明化。

4.3       SOA 和 BPM 融合的价值

4.3.1        敏捷性

从可重用的粗粒度服务开始业务流程方案可以快速的部署。因为SOA中的业务服务已经被预集成，并且是面向业务的可重用架构，所以不需要关心流程编排下面一层的具体内部细节。SOA搭积木的方式使得业务流程能更广泛的应用，更容易被重用。这种高的重用性同时有益于企业级的标准化和规范化。BPM同时使得重用性扩展到业务层面。

4.3.2        弹性

SOA 使得业务流程方案隔离于IT系统的变化。对于业务来说，在定义处理或供应补给或客户服务请求并不依赖所设计的IT系统的具体版本或地理位置。也就是说的，软件的版本升级，迁移到新的平台等对不会影响到业务。SOA的松耦合允许在不影响BPM的流程逻辑和展示的前提下来有序的发展IT资产。

4.3.3        服务质量

流程的拥有者希望获得我们上面我们谈到的BPM的益处，但是通常都是假定技术层面是完全安全、可信、和快捷的。但是所谓的服务质量并没有在web标准中内置，需要客户化程序的方式在BPM实施中保证。但是SOA 中的 ESB使这些事情变的容易。例如：流程节点中需要和SAP交互的时候，使用适配器直接联接SAP，但是更好的办法是使用基于统一管理策略的可重用业务服务，高性能的异步调用，可靠的进行传输和一致的错误处理。系统建设中强调可靠集成的需求的时候，SOA给BPM提供了增援。

4.3.4        业务和IT可以更好的协同工作

BPM引入了企业敏捷度的基础方法论，通过流程的优化及一系列的软件工具来达到精炼企业业务的目的。BPM期望与在识别和定义流程的业务人员和实施集成过程和服务的IT人员之间深入的协同工作，以便联合这两个群组共享价值体系产生新的功效。业务人员得到了能支持动态需求的快速、敏捷架构，IT通过提供这种架构得到了更好的价值体现。

4.3.5        新的业务模式

SOA 的一个重要的益处就是我们并不需要自己完成所有的事情，我们可以替换目前由内部提供的功能为我们的贸易伙伴提供的服务。当然这中情况一般不是端到端的业务处理，而是一组独立的可以低成本被其他伙伴所使用的业务服务。BPM 和 SOA允许并估计这样的创新来增加企业的竞争优势。

5          小结

在文章中我们分析了SOA和BPM融合的价值，在实际的项目中，SOA和BPM谁先行的问题是大家普遍关心的问题。实施上自上而下或自下而上或同时实施的方法都是正确的，需要针对企业的具体问题和情况做详细的策略分析。将BPM作为SOA项目的切入点也是我们所推荐的。因为实施SOA – 服务识别和发现，部署架构- 通常需要多年的时间， 很多公司都刚刚才起步。公司可以马上获得BPM带来的益处而不一定非要等等SOA的完全实施，所以可以将BPM作为SOA的切入点，识别出最有价值的业务流程模块去实施企业级SOA，在企业级的SOA的基础上，逐步积累，更加深入广泛地推广BPM应用。

image002.jpg

image004.jpg

image008.jpg

image010.jpg

image012.jpg

image014.jpg

tt.jpg

soabpm.gif