原文:[url]http://www.flowring.com/pagelogic/mainpage.jsp?pl=ma300030010000sc[/url]
前言
BPM(企业流程管理，Business Process Management)技术 与 SOA (服务导向架构，Service Oriented Architecture)各自历经多年的发展，至今成为广为业界接受的技术架构。本文将从 BPM & SOA的历史演进开始，深入浅出描述各标准的发展过程与彼此的关系，让读者轻松了解其应用范围与来龙去脉。另外，也将以相关标准组织的最新资料为基础，介绍当前制定中的新技术标准以及其演进。
以流程为中心的管理思潮
BPM的范畴涵盖企业营运的各项构面，如研发、生产、行销、业务、人事、财务等企业营运活动，甚至往上下游扩及供应商与经销商，以及客户端的客服活动。诉求是企业应以流程化的思考方向，串连原本各自独立而未协调的营运活动，使串连后之营运活动成为具有步步加值效果的企业营运流程，并辅以各项管理手法使其落实运行，达成企业流程管理目标。
1990年麻省理工学院 Hammer、Champy[ ]，哈佛大学Davenport[ ]等人，相继在学术刊物发表企业流程再造(Business Process Re-engineering)观念。1993年Hammer 与 Champy 继续发表《企业再造》[ ]一书，强调BPR的重要性，以及IT技术在BPR过程的角色，使BPR成为当时的热潮。1997年，Hammer又发表《企业再造之后》[ ]，宣告了流程化组织的必然性与重要性，并且预言 BPM/BPR将改变人的工作方式。
2003年，Smith与Fingar发表《企业流程管理：第三波》[ ]，预言往后50年BPM仍将是企业经营的重要议题，也指出21世纪BPM的型态与新特征，并给予可行的教战守则，更罗列数十个企业运行BPM的实际案例与经验，让推行BPM的蓝图更加具体，使本书成为当年企管领域的畅销书，让BPM的风潮持续不灭。
2003年，Smith与Fingar发表《企业流程管理：第三波》[ ]，预言往后50年BPM仍将是企业经营的重要议题，也指出21世纪BPM的型态与新特征，并给予可行的教战守则，更罗列数十个企业运行BPM的实际案例与经验，让推行BPM的蓝图更加具体，使本书成为当年企管领域的畅销书，让BPM的风潮持续不灭。
BPM的推行观念的改变与进程
根据1993年《企业再造》一书的调查，当时企业推行BPR/BPM 有高达5~7成的失败率。因为这么高的失败率，所以即使BPM是企业势必要面对的议题，也让他们把BPM的推展视为畏途，甚至抱持负面的看法。之后，整个BPM产业继续历经十几年的学习经验，与前仆后继的推行案例，不断从许多案例归纳关键的成功或失败因素，让推展BPM的蓝图逐渐浮现。在蓝图中，错误的作法逐步被修正，更多的BPM管理工具被界定(identified)出来而丰富了整个蓝图。众人慢慢认同，一个成功的BPM推行，是由以下金三角共同构成：
- 明确而有共识的组织流程规范
- 成熟的BPM 软件系统架构与建置
- 企业主管与员工的认同与运行力
从变动幅度来看，以往革命性大刀阔斧的 BPR (流程再造)口号，已转变为温和的BPM(流程管理)实践。这种务实的作法，事实上是察觉到组织变革、流程思考企业文化的形成，需要一年到数年的时间；革命性的快速改变，若无充分的准备与良好管理体质，反而让企业乱了原有的脚步。所以一步一脚印的务实作法，渐渐获得认同。企业从核心BPM流程的落实与推行开始，逐步拓展到外围系统与业务伙伴，将可降低失败机率。
而从管理成熟度来看，过去企业推行BPM，多半以流程计算机化这种短程目标为主，却忽略了BPM的终极目标在于「管理」 [ ]，而非计算机技术，也非流程细节。所以高阶经营决策的需求常常被忽略而缺乏规划。而因为缺乏指导目标，在BPM的需求导引过程当中，企业员工常会无明确的指导目标，而以为工作流程计算机化就是把自己手边的工作巨细靡遗计算机化，而模糊了BPM的管理焦点。当这些与终极BPM管理目标无关的软件需求被列入计画讨论，不仅模糊焦点，也无形地垫高BPM的整体成本。
事实上，BPM的管理可以归纳为以下几个可逐步提升的层次，从这些层次也可了解一般组织推行BPM的成长历程：
- 混沌阶段：没有明确的企业流程定义。
- 明文定义：具有书面的企业流程定义或标准作业程序，但没有根据正规的记号(notation)，因此规则也许含混不清。
- 验证与共识形成：定义的企业流程，通过公司组织政策的验证，如质量政策，市场策略，管理原则，并获得高层决策通过，达成组织共识。
- 组织人员的流程准备：组织成员经过教育训练，认同组织制定的企业流程，并且具备运行的能力，包含专业基本技能的养成，并习惯流程化、信息化的作业方式。
- 企业本身的流程准备度：现行的企业组织架构，若与流程化的思考方式冲突，则应及早准备组织架构的调整，特别是毫无章法的职务与部门阶层架构(hierarchy)。良好的组织设置与权责划分，可以使流程定义更为精简易懂、便于遵循，也容易分析企业规则之间是否相互矛盾；同时可降低BPM软件系统的开发成本。
- 采用标准的企业流程表示法：使用一致的标准记号与格式来表达企业流程的内容。这里的标准记号应该是广被业界采用的格式，例如OMG在UML所定义的活动图(activity diagram)、BPMI (现已并入OMG) 组织所定义的BPMN，以及OASIS组织的BPEL。当然，企业流程的内容确实相当复杂，单一标准记号或格是通常只能描述部分构面，所以仍会有些构面暂时没有业界共同认可的记号或格式可供选用。
- 流程自动化：使用软件系统落实企业流程的运行流程。包括使用流程定义工具来定义企业流程内容，以及使用工作流程管理系统(WfMS ? workflow management system)来运行定义的企业流程。
- 进度监管：企业流程的运行进度可以被监看(monitored)与追踪管理。
- 流程集成：流程运行过程中，能进一步与其他内外部的流程互通，或者与既有应用系统(legacy system)交换资料，以延伸流程的触角，发挥综效。
- 流程绩效评量：企业流程的运行效能可以被测量(measured)，并且透过公式计算，以报表呈现有意义的管理指针。
- 流程分析与仿真：持续搜集企业流程的运行资料，分析组织的流程运行瓶颈，并回馈到流程定义，调整业务的运行方式。另外，也根据历史资料与预测参数，透过仿真分析试算，比较不同流程调整方式所获得的改善程度。
- 智慧型流程环境：透过流程资料的资料采撷(data mining)，主动分析流程统计数据，并回馈至流程系统。举例来说，在客服流程系统中，主动归纳顾客过去使用服务的频率与分布状况，归纳未来的趋势与规律(pattern)，并根据现有流程环境的现况(如现有承接量，以及可动用的客服人力资源)，自动调度客服人力分配策略，或向资源管理者建议客服人力调度策略。
BPM 的技术现况与趋势
BPM的其中一个技术构面是流程，它的IT技术解决方案的来源可追溯到 1970年代晚期的文档传阅(routing)应用系统，主要目的是让商业文档与图象能在不同计算机间传递，使文档能从输入或扫描人员，传递到审核人员与其他角色。典型的应用流程包括保险公司的保单资料处理作业，或者银行的融资申请与签约作业。这些需求促成了工作流程(workflow)技术的崛起，而软件业也开始把工作流程技术应用到这类应用系统，成为核心组件。
工作流程技术是中立的角色，随着不同应用领域的兴起而有不同的运用方式，在办公室自动化、公文系统、研发专案管理、制程管理、品保系统，或者客户服务系统等等，都可以查找工作流程技术扮演的重要角色。即便是面对企业管理领域被炒得火热的 BPR/BPM，或者在IT / Web Services领域被当成新兴技术议题讨论的 Web Services Orchestration[ ]、Choreography[ ]与企业流程运行语言(BPEL－Business Process Execution Language) ，只要详细分析其技术本质，仍不脱工作流程技术既有的范畴。这些当红的企管或技术名词，一旦底层抽离工作流程技术，就无法独立存在。
然而，狭义的工作流程技术并不是推行BPM所需的IT技术的全部。早期工作流程技术与图象扫描与辨识技术结合，造就了文档图象流程系统。近年，工作流程从BPM领域切入，成为解决方案的重要一环；狭义的工作流程技术，历经多年汇流了多项技术元素，成为当代的BPM解决方案，主要特色如下：
- IT技术面：采用工作流程技术为主体，结合入口网站(Portal)、企业应用集成(EAI－Enterprise Application Integration)、报表与商业智慧(BI－Business Intelligent)工具、流程模型分析(process model analysis)、与仿真(simulation)技术。这些现成(COTS ? commercial off-the-shelf)软件组件结合运作，可大幅降低信息系统的建置成本、时程，以及开发风险。
- 管理活动面：可提供策略地图、平衡计分卡、六个标准差、TQM等管理活动的必要管理信息，搭配合适的管理决策工具呈现企业整体的BPM成效。
- 贴近特定产业的流程需求：每个产业都有其特有的企业经营模式与参考模型，如制造业、买卖业、医疗业、物流业等产业，都存在产业专属的流程模型与标准。像是 RosettaNet 替电子商务交易的询价、下单、交货、付款等流程作业，制定了日常实际应用的参考模型；而供应链协会(Supply Chain Council)则在供应炼与物流领域，制定SCOR流程运作模型(Supply Chain Operation Reference)。若流程定义工具能够直接提供这些参考模型的语意支持，或者提供现成可套用的流程样板(template)，将可以减少开发这些特定产业应用所需的成本。
- 服务接取(access)面：解决方案能满足不同的使用者，如习惯大量资料输入作业的专业使用者、少量资料操作的一般使用者、偏重BPM绩效报表的主管，或者行动装置的使用者。也就是说，可提供不同的操作界面，如常规桌上型应用程序、Web Browser应用程序、PDA，或者Smart Phone等装置，给参与BPM系统的各种人员使用。
- 交互情境面：BPM技术解决方案需同时兼顾「人对程序」、「人对人协同作业」，以及「程序对程序」等交互情境。
由于BPM解决方案并不是一次到位的架设，而是持续多年的活动，因此整体BPM蓝图必须考虑分期开发，渐进导入的特性，建议BPM的IT规划者应参考本文稍后[ ]所提的SOA架构当成蓝图的基础。
BPM与工作流程相关标准组织
想深层了解一个专业的产业发展，透过产业标准组织是一个不错的方式。对技术底层感兴趣的BPM技术人员来说，以下的列表可以作为探索的起点。
| 组织名称 | 组织全名与网址 | 与BPM相关之标准 | 说明 |
| WfMC | Workflow Management Coalition [url]http://www.wfmc.org/[/url] |
Workflow Reference Model |
工作流程系统模块架构的参考模型 |
| XPDL | XML - Process Definition Language | ||
| WfXML | Workflow XML | ||
| ASAP | 主持人为WfMC工作小组成员之一，但此工作放在OASIS，请参阅OASIS的项目 | ||
| WAPI | Workflow API | ||
| OASIS | Organization for the Advancement of Structured Information Standards [url]http://www.oasis-open.org/[/url] |
ebXML ? BPSS CPA CPP |
e-Business using XML ? BP Specification Schema Collaboration Protocol Agreements Collaboration Protocol Profile |
| BPEL | Business Process Execution Language | ||
| BTP | Business Transaction Protocol | ||
| ASAP | Asynchronous Service Access Protocol | ||
| UDDI | Universal Description, Discovery and Integration (从UDDI.org 并入OASIS) | ||
| WS-CAF | OASIS Web Services Composite Application Framework | ||
| WS-RM | OASIS Web Services Reliable Messaging | ||
| UN/CEFACT | United Union, Centre for Trade Facilitation and Electronic Business [url]http://www.unece.org/cefact[/url] |
ebXML | (参考OASIS的 ebXML部分) |
| OMG | Object Management Group [url]http://www.omg.org/[/url] |
UML | 其中的Activity diagram 可用来描述企业流程的部分构面 |
| BPMN | Business Process Modeling Notation | ||
| BPRI | Business Process Runtime Interfaces | ||
| BPDM | Business Process Definition Meta-model | ||
| BSBR | Business Semantics of Business Rules | ||
| OSM | Organization Structure Metamodel | ||
| BRM | Business Rules Management | ||
| BPMI | Business Process Management Initiative [url]http://www.bpmi.org/[/url] |
BPMN BPML BPQL |
(2005年6月已并入 OMG) |
| W3C | World Wide Web Consortium [url]http://www.w3.org/[/url] |
WS-CDL | WS-CDL Web Services Choreography Description Language |
| WSDL | Web Service Definition Language | ||
| SOAP | Simple Object Access Protocol | ||
| HTTP | Hyper Text Transfer Protocol | ||
| OAGi | Open Application Group [url]http://www.openapplications.org/[/url] |
OAGIS -- BODs | Open Applications Group Integration Specification ? Business Object Documents |
| RosettaNet | RosettaNet [url]http://www.rosettanet.org/[/url] |
RosettaNet -- PIPs | RosettaNet ? Partner Interface Processes |
| Supply Chain Council | Supply Chain Council [url]http://www.supply-chain.org[/url] |
SCOR model | Supply-Chain Operations Reference Model |
WfMC 是比较专注于工作流程的组织，它的WfMC workflow reference model是最常被引用的工作流程管理系统的参考模型。虽然WfMC的工作小组数目较少，但因为起步较早，旗下的 XPDL与WfXML标准，有相当多的工作流程厂商支持。WfMC替工作流程的技术发展奠定了早期的基础，它界定了BPM与工作流程领域的大框架，也持续不断的推广BPM与工作流程，让众人清楚这个领域的体系与架构。
OASIS与OMG的技术小组数目比较多，工作焦点也不仅限于狭义的工作流程技术。因为涵盖的范围较广，而且背后的支持厂商规模较大，所以整体影响力也较大。OASIS旗下的BPEL取自IBM、微软等公司，而ebXML则是OASIS与UN/CEFACT这两个组织共同成立的工作小组。OASIS藉由充沛的技术发展动能，为工作流程技术领域开拓更大的视野，在流程定义格式、流程运行层面，以及复杂的流程交互机制等领域，提供了宝贵的技术解决方案。
OMG在BPM领域掌握了标准记号(notation)，包含UML，以及从BPMI并进来的BPMN。同时，OMG也积极以塑模(model)的角度，切入工作流程定义的其他构面，如共通模型表示法BPDM[ ]、流程语意BSBR、组织架构OSM、业务规则BRM等等。OMG的强项之一就是在塑模(model)技术，它的UML广受软件领域接受；在BPM与工作流程的领域，OMG持续发展BPMN与等其他BPM各构面的塑模技术，未来将使BPM的其他构面(如业务规则，或组织架构)也能使用像UML或BPMN这种等级的表示记号来进行塑模，让复杂企业流程的塑模工作更加容易而清楚明确。
W3C的强项在于 Web 领域，HTTP是最知名的代表作。而XML与Web Services 是BPM在SOA领域的基础建设。其它相关的BPM技术，如 WS-CAF, WS-RM, WS-CDL等等，都奠基于W3C的 Web Services技术。
OAGi、RosettaNet，以及 Supply Chain Council，则是特定产业领域的代表。它们的贡献在于替特定产业界定共通的BPM运作规范，也就是说，定义属于他们产业特色的应用流程参考模型与共通的术语，让这个特定产业在推展BPM时，就有基本的需求大纲与基础架构，也让同产业体系内的厂商可以透过共通的产业模型与共通术语沟通，避免不同BPM应用系统之间生成各自为政而无法互通的障碍。如同前文所述，RosettaNet在电子商务领域已经广为人知，SCOR模型则在于物流领域。虽然OAGi在国内的能见度没有 RosettaNet高，但它涵盖的范围相当深远，号称涵盖电子商务、制造、物流、航太、汽车、医药、零售、能源等32种产业。以OAGi 9.0版为例，就涵盖61种流程情境(scenario definitions，像是订单管理、应收帐款、供应链集成、销售管理、客户服务)与434种商业文档(BODs, 像是订货单、维修单、捡货单、零件物料列表等，在流程当中传递的文档)的正规定义。
表一列出的各项技术标准，是以标准组织为分类依据，我们再以其他观点来呈现其中几个重要技术标准，以便读者能够更清楚了解这些标准的定位。
| 功能类别 | 功能目的 | 技术标准 |
| 流程查询 Discovery |
透过查询机制，取得服务流程的基本资料 |
UDDI LDAP DISCO |
| 产业间流程交互机制 B2B collaboration |
使同一个特定应用产业的流程具备基础的参考模型与术语 | RosettaNet 的PIPs ebXML的CPA OAGIS的BODs EDI，SWIFT |
| 塑模方式与记号 Modeling |
提供标准记号(notation)与塑模技术 | OMG的UML、BPMN |
| 流程定义的语意与格式 Process Definition |
提供结构化的流程定义保存格式，并且明确解释每一个流程定义项目所代表的语意 | WfMC的 XPDL、WfXML OASIS的 BPEL，以及ebXML BPSS，ASAP, WS-CAF W3C的WS-CDL |
| 服务界面描述 Services |
定义结构化的格式，供软件组件描述它所提供服务的内容与调用方式 | W3C的WSDL OASIS的ebXML CPP |
| 传输界面 Transport |
提供消息的传输机制 |
W3C的HTTP/SOAP OASIS的WS-RM |
图一: WfMC技术小组提供的工作流程相关标准堆栈图，2003年版本
服务导向的企业
过去几十年间，企业经营的焦点随着市场趋势而演化，60年代谈的是提升量产，70年代谈的是降低成本，80年代谈的是提升质量，90年代谈的是产品推出速度，而跨入21世纪，谈的是如何给客户更多样的服务。不管重心怎么改变，在21世纪之前，改善的重心仍落在产品实体；直到21世纪，重心已开始从产品延伸到购买产品的顾客，强调顾客是怎么样获得产品与服务。
| 年代 | 经营管理重心 | 解决方案 | |
| 1960~ | 提升产量 |
Quantity: Make more | 自动化生产 |
| 1970~ | 成本与价格 | Cost: Make it cheaper | 采购与供应链 ERP，SCM |
| 1980~ |
产品质量 | Quality: Make it better | 品管技术 TQM |
| 1990~ | 产品推出速度 | Lead Time: Make it quicker | 产品开发管理 PLM，PDM |
| 2000~ | 服务内容多样化 | Service: Offer more | 服务内容与流程 BPM，SOA |
为了提供多样化的服务，许多企业活动将被解构后再重组为新的营运模式，而这代表位居幕后支持的IT技术，必须能迅速配合这样的营运模式改变。也就是说，所有的IT技术与信息系统，都能够像变形虫一样，随时解构后再重组，在短时间内提供新营运模式所需的信息服务，这包括企业后台营运所需的信息系统，以及面对客户所需的前台服务界面。
在十倍速的时代，企业无法等待。常规为了新营运模式而大规模更改 (而非重组) 信息系统的方式，过于牛步化无法满足要求。下一节提到的SOA架构，替服务导向的企业，提供了很好的解答。
天生一对的企业流程管理(BPM)与服务导向架构(SOA)
SOA的IT技术本质单纯而不难理解，个别的技术元素分别理解还算容易。对于SOA，大家联想到的就是 Web Services，谈到Web Services，我们就直接脱口而出：WSDL、UDDI，以及SOAP，然后就是一系列的WS-＊ 的技术标准。对很多人来说，只了解个别技术单元，并无法领会到SOA世界的美好。就好像只看得到调色盘的每个颜色，却看不到美丽动人的画作。所以，让我们先把无趣的技术名词摆一边，这无助于我们了解SOA的美好世界。
首先，我们需先认识SOA世界里的企业流程运作方式，以及SOA的技术元素可以互相彼此串接而形成丰富的生态；如此，就可知道为什么BPM与SOA是天生一对 -- SOA 架构总存在美妙的答案来满足BPM变化多端的环境。
一般来说，真实世界的BPM，具有以下的IT需求特征：
- 它的运作是分布式的：多数企业流程都是由多个参与者共同运行，参与者可能来自不同办公室，甚至不同的地域区域，打破部门藩篱，甚至跨越公司的疆界；因此，跨因特网环境的应用系统支持，以及网络环境下的安全性，都必须列入考量。
- 它可以进行工作协调与应用程序集成：大部分的企业流程并不只是运行单一业务功能，而是多个业务功能互相协调后的成果；因此，原本独立支持某项业务运作的应用系统，也必须跟其他业务的应用系统相互集成。
- 它是动态的系统：企业流程中的各项元素经常动态改变。工作串连方式会随着环境改变、人员角色扮演会异动，工作的运行地点也会改变。因此，BPM环境中的应用程序模块，必须演化成快速适应变动的动态系统，可以轻易透过设置或配置的改变行为模式，甚至调整运行地点，以因应企业流程的变动。
- 它的构成元素种类繁多而复杂：BPM系统内含分布于各模块的企业逻辑与规则、各种不同安装与监管模式的应用模块，以及众多模块之间的串联与相依关系设置。因此，BPM环境中的软件模块，需要让模块变得可以被BPM配置机制管理，这包含模块的启用停用、健康状态回报，以及系统安全政策，都应有一致的管理方式与技术标准。如此，整个复杂的BPM环境运作才可列入掌握而不致失控。
- 它可以渐进式地成长：企业可以从最简单的BPM活动开始着手，再演进到成熟复杂的BPM系统；因此，整个系统架构必须能提供清楚的进步蓝图，允许企业按部就班投入IT资源，并逐渐提升BPM成熟度来运行BPM。
以上五个特征，刚好可用来陪同我们探索SOA的技术世界。
针对特征一，SOA 技术架构可提供安全的网络传输与运行环境。主要技术有二：一是软件模块互相通讯时，所需的保密需求，这可由WS-Security来达成。另一个则是组织成员在环境中的权限控管方式，这可在SOA架构内，采用LDAP、集成单一帐号登录、PKI架构与数位签章等机制来配合。
第二个特征引发的议题是SOA工作协调与应用系统集成。常规应用模块在SOA的世界里，可以采用SOA规定的服务界面(Services Interfaces)对外开放模块的功能。应用模块之间，透过SOA的服务界面标准互传资料，就是最简单的Web Services应用案例。此机制的主要意义在于：所有SOA内的应用模块，只要提供SOA的标准服务界面，就可以不受开发语言限制，互相调用或传递资料。这里的服务界面，讲的就是WSDL(Web Service Description Language)；而SOAP(Simple Object Access Protocol)则是规定应用模块之间互相调用或互传资料时的封包格式。至于WSDL或SOAP的内容与格式应该长怎样，大部分技术人员可以让中介软件或者EAI系统代劳，透过service adaptor 直接把常规应用模块包成 Web Services模块，并不需烦恼内容的细节。
第三个特征引发的议题是 SOA的服务组合弹性与松散耦合（loosely couple）的特性。SOA内的应用模块若要能轻松改变组合方式，或者改变运行位置，就要藉助SOA的两个技术特性：松散耦合，以及UDDI(Universal Description, Discovery, and Integration)机制。因为松散耦合，所以某一模块抽离或添加系统，并不影响其他模块；因为有UDDI机制，所以新应用模块添加时，只需跟UDDI服务器登记新服务的界面与所在地点，即可被其他应用模块搜寻到，并且开始交互。因为有UDDI，所以当某项应用模块迁离位置，原有使用此应用模块的其他模块，可以透过UDDI查×××的新位置，然后用新位置连结即可。这种特性满足「经常需要把服务节点拆解再重组」的BPM服务导向经营模式。
第四个特征谈到的是可管理的SOA Web Services。这是系统管理与软件管理的议题，虽然当前没有统一的标准来规范管理软件与被管理模块的行为，但当前稍具知名度的SOA环境（特别是application server）多半会提供系统管理工具给系统管理员使用，协助管理SOA架构下所有列管模块的安装、移除、启动、停用，以及应用模块的状态监控与安全机制。
第五个特征，谈的是SOA 技术架构是模块化又可弹性串接的特性，在原有SOA环境添加新的技术模块，即可渐进式提升BPM技术的成熟度。我们从ZapThink [ ]整理的SOA蓝图中，可以得知达到不同SOA成熟阶段所需具备的SOA技术。举例来说，假设SOA有阶段实施的计画，那中间过程可以从「点对点集成」开始，进步到「提供松散耦合的服务」，再来是「稳定而可搜寻发现的服务」，接着「提供可组装与再利用的服务」，进而达到最终目标－「全公司的SOA」。当然，也可从蓝图中得知，不同SOA阶段所能获得的投资回报(ROI)，刚开始只能是「降低应用程序的维护成本，达成点对点的集成」，接着是「透过服务再利用提升效率」，再来是「提升管理能见度与控制力」，最后才是「改善组织的敏捷度」。
结语
其实，即使是资深的BPM/SOA规划者，想要跟决策主管解释清楚SOA的博大精深以及其效用，都是很大的挑战。主要原因在于其中大大小小的技术条目，以及其相当复杂的关联。虽然大家都知道，画出一张易懂的图解，胜过千言万语，然而好图难求，幸好今年(2005)十月ZapThink公司推出一张令人深刻的SOA蓝图海报。这张呕心沥血之作，让人能从各个构面、由入门到高级，逐步探索SOA的世界，而且过目难忘，却又能够不失BPM/SOA技术的深度与完整度，实在非常难得，在此推荐这张海报作为延伸阅读，也当作本文的尾声。
附注
1. T.H. Davenport and J.E. Short, "The New Industrial Engineering: Information Technology and Business Process Redesign,", Sloan Management Review, pp. 11-2, Summer 1990.
2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990.
3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993.
4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997.
5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003.
6. 参阅 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005.
7. Web Services Orchestration，简单说法：使用流程技术来描述并控制Web Services的调用顺序，使多个?eb Services依序发生，运行事先安排的工作顺序。
8. Web Services Choreography，简单说法：在跨流程的情境中，以Web Services技术，描述流程个体之间的消息传递关系(多半是网状结构)，以及流程状态的控制与查询方式。
9. 参阅本文「天生一对的BPM与SOA」小节
10. BPDM的目的在于提供可通用于多种流程塑模方法的中介模型(meta-model)，以便不同塑模方法生成的流程定义可以互相转译。如UML、BPMN，或者其他厂商的专属表示法，能够对照到此中介模型，然后互相转译；或者让流程定义转译成底层的可运行格式，如BPEL原始码，乃至于J2EE或 .NET的运行码。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: [url]http://www.zapthink.com/report.html?id=ZTS-GI103[/url]
2. Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate ”, Harvard Business Review, Jul 1990.
3. Michael Hammer and James Champy, Reengineering the Corporation : A Manifesto for Business Revolution, Harpercollins, 1st ed.,May 1993.
4. Michael Hammer, Beyond Reengineering : How the Processed-Centered Organization is Changing Our Work and Our Lives, Collins, Sep 1997.
5. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kiffer Press, 1st edition, Jan 2003.
6. 参阅 Derek Miers, “BPM -- Too much BP, not enough of the M,” WfMC Workflow Handbook 2005, Future Strategies, 2005.
7. Web Services Orchestration，简单说法：使用流程技术来描述并控制Web Services的调用顺序，使多个?eb Services依序发生，运行事先安排的工作顺序。
8. Web Services Choreography，简单说法：在跨流程的情境中，以Web Services技术，描述流程个体之间的消息传递关系(多半是网状结构)，以及流程状态的控制与查询方式。
9. 参阅本文「天生一对的BPM与SOA」小节
10. BPDM的目的在于提供可通用于多种流程塑模方法的中介模型(meta-model)，以便不同塑模方法生成的流程定义可以互相转译。如UML、BPMN，或者其他厂商的专属表示法，能够对照到此中介模型，然后互相转译；或者让流程定义转译成底层的可运行格式，如BPEL原始码，乃至于J2EE或 .NET的运行码。 R. Schmelzer and J. Bloomberg, ZapThink's Service-Oriented Architecture Roadmap, URL: [url]http://www.zapthink.com/report.html?id=ZTS-GI103[/url]
自由、创新、研究、探索……
