科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道SOA 的应用 -- BPM

SOA 的应用 -- BPM

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

SOA 仅是系统设计的理念,期待包装既有投资与新开发的系统,BPM 平台着眼在设计商业流程而非技术实做,重点是规划现有流程、设计新的流程、布署与版本控管流程、自动执行流程中各个工作、追踪、警示与分析流程的执行状况,其平台须涵盖完整的流程生命周期。

作者:胡百敬 来源:CSDN 2008年1月24日

关键字: BPM 应用 SOA

  • 评论
  • 分享微博
  • 分享邮件

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

l   一切技术遵循公开标准

l   服务定义的边界明确

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

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

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

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

个人觉得 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 年由 IBMBEA和微软一起制定,是基于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 来绘制厂家自定的流程模型,而后转成前述的流程语言(不管是 BPELXPDL 或是各厂家自定义的中介语言),再上载到独立的流程引擎执行[2]。而 UML 有标准化的好处,Visio 则较平易近人。

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

流程的设计能要同时处理直译式与编译式的程序代码,可解析流程描述文件(例如,以上述 BPELXPDL 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 平台,可以整合各种商业逻辑的需求,则不仅是 CIOCTO 等信息技术人的领导者需要参与,连 CEO 也该贡献心力,如此才推得动,且有整体的方向。

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



[1] 我们一般将 Process Workflow 都翻译成流程,而本文一开始就将 Process 翻译成流程,为了怕混淆,笔者在此保留 Workflow 原文。

[2] 这种模式有个附带的好处,若安装新流程是更换程序代码所编译的 DLL,也就是流程定义靠塑模工具动态产生程序代码,编译后替换流程引擎所呼叫的旧组件,这往往有安全疑虑。因为程序组件不管是 DLL EXE,就会让管理人员有病毒的疑虑。但若流程定义是靠专属的流程语言,则更新的是 Metadata,这只有数据,不会有安全疑虑。

 

[3] 就笔者猜想,以往单一程序或服务内如意大利面式的程序代码,未来将变成意大利面式的组件、服务与流程。以往 Copy/Past 程序代码再改个两行的恶习,将会从 IT 扩大到所有的商业人员。



查看本文来源
    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章