SOA 的应用 -- BPM

SOA 仅是系统设计的理念，期待包装既有投资与新开发的系统，强调如下的重点：

l   一切技术遵循公开标准

l   服务定义的边界明确

l   服务自主而不受制于其他服务

l   服务间只共享协约和原则

希望以此规范出来的系统容易整合、重用并且快速反应商业需求。立意很好，但建立出明确自主的服务后，下一步呢？

在上课中，笔者常询问来自各界的朋友：「当你们的 CEO 发现营运上的挑战，新的商机，而决定组织或流程再造，你们手中的架构可以快速因应吗？」或是「你们的 ERP 有弹性吗？」、「核心业务(Core business)有没有和 ERP、CRM、SCM 整合啊？」、「系统的重用性有多高？」、「构思规画当下的系统时，可能想到未来其他系统的呼叫或整合吗？」大多数的答案都是否定的。

个人觉得 SOA 是上述问题的必选答案，但不够。针对这些问题，另一个将热起来的是 BPM(Business Process Management)，它不是新概念，在上场上也早已有许多的产品，但随着软、硬件运算力的大幅增强，人与人、人与程序、程序与程序间的流程成熟，绘制流程模型的程序接口变得友善，XML 技术的快速发展，SOA 理念的推广，乃至于参与 IT 规划的管理阶层逐步提高，这让 BPM 不再遥不可及。

商业流程开发、整合与管理的需求

一般来说，商业流程可能是业务机密，要尽量从程序中分离出来。例如，绝大多数的服务业，乃至于通路或制造业，像 Dell ，其竞争力就是流程本身，他们不会愿意让系统整合商的开发人员学会其特殊的流程后，将其制成产品，或是成为竞争对手的顾问，而军事系统的流程更是需要保密。因此将商业流程设计与 IT 实做分开，这种基本需求早已存在。

而将商业流程转成技术人员的想法往往非常困难，流程又经常改变，据统计一个公司内，约有 70% 的流程是不常变的，但有 30% 的流程与公司业务直接相关，却变动非常大。而平均完成一个流程的时间约 4~6 个月。

而今组织与流程的变动管理已经是企业竞争力的选项之一。不仅在组织或公司内需整合与自动化流程，还同时延伸到上下游，如客户、伙伴、供货商等，能协调与整合自身与其他企业间的流程，才有整体的竞争力。

但工程师设计出来的流程模型，商业人员根本看不懂。例如在微软 BizTalk 平台用 Visual Studio 绘制的流程模型，或是其它产品用 UML(Unified Modeling Language )绘制流程模型，这可能直接吓阻商业人员想要了解 IT 流程的意愿L。而商业逻辑的困难度也可能让能技术人员在短期内摸不着边际，例如金融投资流程，这或许需要重新再教育 IT 人员，让他们痛不欲生地学习商管与投资理论L。

综合以上所述，定义流程不应该是程序设计人员，而必须要让管理阶层或业务人员透过友善的流程塑模(Modeling)工具程序，轻易地串起 IT 建置的基础服务，每一个服务都是独立的端点，只要定义条件就可组织新流程。而 IT 人员要能抽象萃取出服务单元，依照 SOA 的精神实做。而功能面抽象与简化的程度；需让非IT人员也能一目了然。这时，商业流程才可经由组装、复合来创造跟重用。

BPM 平台应有的特征

BPM 平台着眼在设计商业流程而非技术实做，重点是规划现有流程、设计新的流程、布署与版本控管流程、自动执行流程中各个工作、追踪、警示与分析流程的执行状况，其平台须涵盖完整的流程生命周期。

商业流程要有弹性就必须与程序实做分开，基础的 IT 技术，或实做个别商业逻辑的服务可以委外，但流程整合须交由公司内部的人员做。BPM 平台要能提供框架，让开发人员的成果，不管是委外制作，或是自行研发乃至于旧有系统，都可以直接整合进来。

塑模与元数据驱动

BPM 要能解决各种 Workflow[1] 的需求，包含人与人、人与程序、程序与程序间的 Workflow。现今描述程序与程序间的 Workflow，其主要的标准有 BPEL(Business Process Execution Language，于 2002 年由 IBM、BEA和微软一起制定，是基于XML技术，描述程序间 Workflow 的语言，主要功能在协调 Web Services 间的执行程序)。而撰写人与人间的 Workflow，较著名的标准则有XPDL(XML Process Definition Language，现由 Workflow Management Coalition WfMC http://www.wfmc.org/ 组织负责制定)。这些流程语言可由流程塑模工具程序产生，转交由流程引擎(workflow engine)执行。但一个完整的商业流程往往混杂这两者，因此，BPM 平台要能兼容并蓄着实不易。

另外，Workflow 的弹性需倚靠元数据(Metadata)驱动的设计理念，而非事先考虑到所有的状况，排列组合成程序的参数选项。流程的步骤须可以由上一个步骤的结果而改变。例如：流程的参与者，根据前面流程的状况而动态产生。或动态显示或隐藏窗体上须取得的字段，乃至于「窗体－人员」的权限由流程来决定，而非将权限逻辑写在窗体的程序里。而一支程序绑死一张窗体的方式，是目前部分 workflow 产品的局限性。由于 BPM 更强调弹性与重用，则塑模与元数据驱动(Model/Metadata Driven)的设计理念更形重要。

而要让一般商业人员设计流程，则流程塑模(Modeling)工具一定要直观易懂，容易上手为第一要务。让学习周期缩短，成本降低。现今企业用在 IT 的教育成本越来越高，这包含企业内所有的人，不仅是 IT 相关人员。同时，人力成本也越来越高。若导入一个新的 BPM 平台，但需要一堆人学数个月，除初期建置成本高昂外，日后必不易推广与维护。现今比较流行用 UML 当作塑模语言，或是以微软的 Visio 来绘制厂家自定的流程模型，而后转成前述的流程语言(不管是 BPEL、XPDL 或是各厂家自定义的中介语言)，再上载到独立的流程引擎执行[2]。而 UML 有标准化的好处，Visio 则较平易近人。

BPM 平台的核心是一个强大的流程引擎。一般来说，会将该流程引擎设计成独立的服务，可并行执行在多台机器上，提供负载平衡。当企业的流程越来越多，或单一流程的使用量极大，由于流程引擎是传导沟通各服务与组件的心脏，若其扩充性不佳，必定拖垮整个系统。同时，在规划系统时最好能设计流程间有不同的优先权，避免重要的流程被较不重要但量大的流程羁绊。

流程的设计能要同时处理直译式与编译式的程序代码，可解析流程描述文件(例如，以上述 BPEL、XPDL 等 XML 格式的语言所撰写)。并整合其他产品的子流程。例如，整个流程描述的步骤中，可以包含微软 BizTalk 或 Windows Workflow Foundation 的执行档。这同时保留了直译描述的弹性与编译程序的效率。若单以编译程序架构 BPM，将很难达到当流程更新后，已经跑到一半的旧流程实例(instance)还可以移转到新的流程规则上。更不用谈须回复(Rollback)该流程前面已经完成(commit)的步骤。

除了友善的流程塑模工具和引擎外，BPM 产品最好要提供程序呼叫整合开发的 Framework。让 IT 技术人员，程序设计师可以包装已有的系统。不管是 SOA 或 BPM，其基本精神都期待重用既有系统，以确保投资。但若 BPM 平台没有提供包装其它系统的 Framework，让系统开发人员包装旧有系统后，分别以不同的形式置入塑模工具和流程引擎。则可能需要大幅修改旧系统，以建置让 BPM 平台可以使用的 API。换句话说，须在旧系统上重新开发让塑模工具图形化呈现该服务的选项，又要让流程引擎照其流程语言动态呼叫该服务，这等同要 IT 大幅替旧服务撰写新接口。

最后，组件、服务与流程的目录服务、也就是整体系统的搜寻分类与版本控管，这永远是生命周期的大题目[3]。而整体平台的自动化批次执行、易管理与监控，可以透过 Portal 或丰富的报表检视流程执行的分析等等，也都是需要考虑的重点。

结论

企业核心竞争力为何？核心竞争力如何换成商业流程？商业流程又如何凝结成商业服务单元？再切割成服务导向架构的信息服务，最后将独立服务串成 IT 系统上真实运作的流程等，这是一连串长远的规划。IT 是全企业的事情，需要高阶经理人的参与。最后，引用 Gartner 的规划，若要建置完整服务导向，动态而弹性的 BPM 平台，可以整合各种商业逻辑的需求，则不仅是 CIO、CTO 等信息技术人的领导者需要参与，连 CEO 也该贡献心力，如此才推得动，且有整体的方向。

SOA/Web Services 是促成 BPM 的重要设计理念与技术选项，藉以整合跨平台的应用系统，让独立系统直接透过程序接口叫用。最终，商业人员与技术人员应可以透过相同的塑模语言沟通协调。BPM 的内涵不仅是IT，更在商业流程。经过不断地优化流程，让企业以更敏捷弹性的方式因应挑战，及时满足需求而获致优化的成果。转化流程为营运智能，加速企业的新陈代谢。