業(yè)務過程執(zhí)行的7個謬誤

申請免費試用、咨詢電話：400-8352-114

經(jīng)過8年多的認真研究之后，軟件行業(yè)和它的客戶正頭撞南墻。由DotCom時代BPM初創(chuàng)者提出的愿景依舊沒有得到實現(xiàn)：我們遠沒有能力使用業(yè)務分析師設計出的業(yè)務過程模型來創(chuàng)建完全可行的解決方案（即使通過開發(fā)人員最低程度的干預）。過程驅動應用模型的需求確實存在：業(yè)務過程改進項目在G2000公司內(nèi)隨處可見，但是盡管持續(xù)改進過程的需求十分強烈，可BPM的市場在2007年仍然很貧瘠（相比它能夠達到的程度），和那些迅速包裝自己的廠商言語形成鮮明對比的是，在2000年，Oracle業(yè)務過程管理系統(tǒng)的空白……

到底發(fā)生了什么？這其實非常容易理解。這就是通常的“你要什么，我就給你什么”的故事。在這些情況下，一系列的誤解常常導致非最優(yōu)解決方案。如果你加入到一個大多數(shù)產(chǎn)品經(jīng)理、架構師和開發(fā)人員從不與業(yè)務分析師進行交流的團隊，由他們自己獨立設計超越一些方塊和箭頭的業(yè)務過程，任何人都不會對當前的這種情形感到驚訝。

11月底，Bruce Silver在“再談雙向工程（Roundtripping Revisited）”中提出了一個關鍵問題。Bruce抱怨兩個關鍵的標準：BPM:BPMN（業(yè)務過程建模符號）和BPEL（業(yè)務過程執(zhí)行語言）之間存在嚴重的失配。他提到了一個研究者（Ouyiang、Dumas、van der Aalst和ter Hofstede）團隊的杰出工作，他們提出創(chuàng)建一個BPMN到BPEL的編譯器，因為它是經(jīng)常提到的在當前的BPMS架構中缺失的一環(huán)。在解決這個問題上他們已取得很大的進展，但是他們的工作仍然尚未完工。他也宣稱我們應該完全放棄BPEL，而將精力放在有可能成功的方向：在符號之下再創(chuàng)建一個可執(zhí)行的BPMN標準層。

我從1997年就一直在這個問題上工作，在2002年我還寫了兩篇文章，它們都被OMG BPMN 1.0 規(guī)范所引用。我將重申我在這些文章中的一些觀點，可能更清楚一些，使用不同的例子。這里，我的目的是探討作為當前BPMS架構基礎的一些誤解，同時給出一個新的架構藍圖，在此基礎之上可以構建一個新型的業(yè)務過程管理系統(tǒng)。

謬誤 1：業(yè)務分析師從系統(tǒng)的視角建模他們的過程。

如果你跟從業(yè)者談過的話，他們會告訴你他們從用戶的視角建模過程，而不是從執(zhí)行的視角或系統(tǒng)的視角。這意味著他們的過程指導用戶做什么，他們從不建模系統(tǒng)對用戶輸入的響應。這么做有充分的理由：業(yè)務連貫性。如果系統(tǒng)失敗了，用戶需要知道該做什么才能使業(yè)務繼續(xù)下去。這也是業(yè)務分析師思考，以及他們?nèi)绾味x和獲取過程指標的方法。這個用戶視角對于業(yè)務非常重要，因為它直接關聯(lián)創(chuàng)造價值的工作流活動。業(yè)務分析師從不根據(jù)系統(tǒng)邊界、執(zhí)行、消息或業(yè)務對象進行思考（開發(fā)人員是）。業(yè)務分析師所理解的系統(tǒng)至多就是一個等價于紙制格式電子版本的屏幕（閱讀或輸入信息）。

謬誤 2：業(yè)務用戶可以很容易的學會BPMN并使用全部特性。

BPMN是一份超過300頁的規(guī)范。即使你的若干業(yè)務分析師決心去掌握所有這些概念，它也是難以思考的。Michael zur Muehlen對BPMN中最常用的結構進行了一次調(diào)查，他的結論是日常使用的大約是25個結構。我個人就為業(yè)務分析師寫過一份教程，它基于10個關鍵概念，同時附有相應的BPMN。說服與我一起工作的精益六西格瑪（Lean Six Sigma）黑帶接受BPMN不是件易事。

Bruce Silver根據(jù)他的經(jīng)驗（因為他教過BPMN課程）進行了評論：

BPMN有大量的只是用于產(chǎn)生BPEL的屬性，這些一般都可以被忽略。

謬誤 3：業(yè)務分析師應該能從過程模型創(chuàng)建可執(zhí)行的解決方案。

我并不是說BPMS廠商毫無誠意地試圖向你推銷一個說得比唱得好聽的BPMS。BPM的出發(fā)點是好的：更好地靠齊業(yè)務/IT、更快的開發(fā)周期……其中蘊含的思想是：業(yè)務的確可以產(chǎn)生一個能轉換成可執(zhí)行代碼的模型。這本無可厚非，它和一些CASE工具、MDA、MDD、DSL……處于同一戰(zhàn)線上。這個愿景道出了我們最想實現(xiàn)的夢想：快、易、省。每次我聽到廠商在這個話題上大噴口水之際，我就會想到John Lennon的那首Imagine（即I want to live in this world, but it is not going to happen in my lifetime）。廠商覺得基于一個堅實的想法有一個真實（并且巨大）的市場。當你將之與來自風險投資幾乎無限的資金量結合起來的時候，那樣，你就得到了我們目前的情形。在交付那個愿景的片斷上，一些廠商要比其它的好一些，但是我們不得不承認這還不是愿景。沒有人可以大聲說他們已經(jīng)提供了一個通用的引擎，業(yè)務分析師可以用來（甚至通過IT的最小干預）從過程模型創(chuàng)建一個解決方案。 大項目失敗，BPMS使用的邊緣化，給組織帶來極少的益處。

我經(jīng)常告訴那些想讓他們的業(yè)務用戶“打造”解決方案的人們的一個笑話是：好消息是你剛剛給你的組織增加了2000名開發(fā)人員，而壞消息是你只是增加了2000名開發(fā)人員。你想讓你的用戶不用構建或者甚至客戶化解決方案，就能個性化它們。注意，在一些好的約束條件下，讓業(yè)務用戶自定義一些業(yè)務邏輯（如規(guī)則）是可行的。

謬誤 4：如果我們增加了一個可以從業(yè)務分析師的輸入直接創(chuàng)建解決方案的魔力BPMS，我們就不需要開發(fā)任何與現(xiàn)有系統(tǒng)的集成，無需改變現(xiàn)有系統(tǒng)的記錄，也不用進行任何QA工作。

這樣說吧，我期望到現(xiàn)在為止所有人都同意：至少在下個10年，我們不會在市場上看到這樣一個魔力BPMS。而且廠商的確完全放棄了將開發(fā)人員排除在外的做法。但是，Bruce寫道：

通過完全忽略BPEL，一些更小的公司開始示范了BPM購買者和行業(yè)分析師的成功做法。像Lombardi、Appian和Savvion這樣的廠商，把精力放在以人為中心的過程而不是集成。這樣導致了一種新風格的BPMS，其中可執(zhí)行的設計直接建立在過程模型之上，以BPMN活動的實現(xiàn)的屬性的形式。

這種工具本身鼓勵整個實現(xiàn)周期中業(yè)務-IT的協(xié)作。并且非常適合敏捷迭代方法論，這種方法顯著地縮短了從模型到已部署的解決方案的周期時間。

Marlon Dumas對Bruce的反應和我的一致：

你不能僅僅因為從來沒有業(yè)務分析師愿意書寫一些類似XPath表達式或其它表達式語言，就將開發(fā)人員排除在BPM生命周期之外。

和我前面所說的一樣，我會證明這些廠商的成功經(jīng)驗是有限的。正如Bruce指出他們關注以人為中心的過程，在很大程度上，我同意它非常適合由這些廠商開發(fā)的業(yè)務過程引擎的集中化視圖，尤其是需要對現(xiàn)有系統(tǒng)集成和進行有限的定制時。

謬誤 5：業(yè)務過程執(zhí)行必須是集中化的。

讓我們在這個謬誤上花點時間。Bruce解釋了他面臨的一個新問題：

事實上，如果[他的BPMN使用者]已經(jīng)做出了他們BPM運行時的決策，那么它通常就是BPEL。它是一個標準、一個日用品，而且可以找到開源實現(xiàn)。它被IBM和 Oracle用在他們的BPM運行時中。因此，在選擇BPEL時有強制性因素。但是BPMN和BPEL不是都在進行標準化嗎？不，這當然不合邏輯。

    在“雙向工程已死”營地（roundtripping-is-dead camp）待了大約一年之后，我現(xiàn)在發(fā)現(xiàn)自己不得不再次面臨這個問題。在我的BPMN培訓中，例如，學生想要知道在他們的BPMN圖中使用什么策略或模式才能非常匹配他們期望的BPEL實現(xiàn)。這并不是我一開始期望去考慮的問題。

BPMN/BPEL雙向工程已經(jīng)成為這個行業(yè)的圣杯。這最初本是由BPMI.org提出的愿景，該組織締造了BPML和BPMN。這兒發(fā)生了什么？在一些公司給BPMN增加執(zhí)行語義的時候連一個中介編制語言都沒有，他們怎么可能為以人為中心的過程創(chuàng)建一個成功的市場？其他人認為這個問題來自于我們沒有找到合適的協(xié)調(diào)語言這一事實。例如，Arzul Hasni認為在雙向工程上GRAFCET會是比BPEL更好的候選。GRAFCET是工業(yè)自動機的專用編程語言（Arzul在他的帖子中給出了細節(jié)）?；旧希浅＝咏麭PEL。

Ouyiang、Dumas、van der Aalst和ter Hofstede在創(chuàng)建BPMN/BPEL映射上做了卓越的工作。對于那些像我一樣早就忘記了大學數(shù)學的人，我發(fā)布了BPMN和BPEL的UML圖，它們可能對于你理解兩個規(guī)范的語義（即，它們可以表達的事物）分歧有所幫助。來自這個研究組的結論非常的清楚：

未來工作的一個可能方法是擴展提議的技術，覆蓋BPMN模型更大的子集，如對相關的異常處理和其它高級結構（如OR-joins）建模。不幸的是，BPMN的許多高級結構并沒有細化，依舊處于由相關標準化團體改進的過程中。

集中化過程引擎的概念并不新鮮。這是自90年代早期以來該領域已取得成果的99.99%的幕后基礎。通過這個優(yōu)秀的介紹可以很好的理解對集中化架構的關注，它由Fujitsu Computer Systems（該公司也在XPDL上投資，為BPMN創(chuàng)建一個可交換的格式）的研發(fā)副總裁Keith Swenson撰寫。

不幸的是，這種觀點是有缺陷的，我非常愿意花些時間解釋這一點。使用這種思考方式，我們完全忽略了業(yè)務過程本來的天性：通過轉換資源給組織增加價值。像Source-to-make、Quote-to-cash……這樣的過程都沿著工作流活動移動“東西”，這些活動最終（且有望）給轉換中或消費中的資源增加價值。信息系統(tǒng)在此只是推進、捕獲和報告這些資源和活動的狀態(tài)。是的，你可以攜帶任何一個描述物理概念的業(yè)務對象：購買訂單、發(fā)票、庫存項、員工、客戶……它們都有生命周期（可用狀態(tài)圖描述--參見圖2）。

我愿意舉一個工作申請業(yè)務過程（即Candidate-to-Employee過程）的例子，它抽取一個候選者的申請，并將它處理到候選者要么被雇用要么申請被拒絕的位置。

以下就是典型的工作申請信息模型。

圖1 工作申請數(shù)據(jù)模型

這個工作申請有一個生命周期（請記住工作申請的數(shù)據(jù)模型——內(nèi)容——獨立于它的生命周期，反之亦然）：

工作申請生命周期本身獨立于任何Candidate-to-Employee業(yè)務過程。這是一塊很少變化的業(yè)務邏輯，即使與之交互的過程可能經(jīng)常變化。一家公司可能有幾個這樣的過程為這個相同的生命周期服務：例如，一個用于副總裁職位，一個用于經(jīng)理，一個用于其它所有的員工。另一種情況可能是因為規(guī)章制度，一些過程可能涉及額外的活動（檢查背景……）。這些過程變體是非常平常的。但是，在很大程度上一個工作申請就是一個工作申請，即使也存在一些工作生命周期變體，它們在很大程度上與它們的過程變體沒有瓜葛。

現(xiàn)在的問題是，你將如何動手實現(xiàn)這個工作申請生命周期組件？我要使用的方法是創(chuàng)建一個實現(xiàn)所有動作的服務，這些動作將導致狀態(tài)轉換：

圖3 工作申請服務

所有這些服務操作將有效執(zhí)行一些會導致狀態(tài)轉換的業(yè)務邏輯。什么是實現(xiàn)這個服務的最好的語言？Java/C#？BPEL？GRAFCET？

我的偏好是如BPEL這樣的一門面向消息的編制語言，因為這些資源生命周期是長期運行的（日、周、月、年）。為了說明這點，讓我們舉一個客戶資源的例子：作為一個客戶，我這周剛剛取消了一個與信用卡公司12年的關系，（這使得我的客戶生命周期實例遷移到了它的最終態(tài)）因為必須支付額外的費用，我覺得違反了計費過程……是的，過程確實麻煩，他們可以完全無需改變我所喜歡的賬單生命周期就能給他們的過程增加一個活動，但是他們沒有，相反他們選擇了最大化費用。對于這種長期運行的生命周期（不是過程），BPEL是一個理想的實現(xiàn)語言，因為它理解消息（接收、發(fā)送、調(diào)用）、關聯(lián)消息，它可以處理并行流程（是的，一個資源可以有組合狀態(tài)）。此外，BPEL引擎被設計來自動處理過程實例狀態(tài)數(shù)據(jù)的持久化（dehydration/hydration），這個工作的麻煩相對少些。

我知道很多人會告訴我它是一個過程，但是它不是。它是一個實現(xiàn)了工作申請生命周期的服務，它獨立于那些推進工作申請狀態(tài)的過程和活動。一個過程是推進它的狀態(tài)的活動的集合。資源生命周期和過程是解耦的，我認為這是無庸置疑的，然而每個人還是試圖在沒有清晰的理解資源生命周期的前提下建模和實現(xiàn)過程，它們或多或少“內(nèi)建在”過程模型中。

因此，大多數(shù)人將BPEL引擎作為標準選擇是正確的……目前為止是這樣。注意，由于SCA，你鐘愛的編程語言可以很容易地被擴展結合BPEL語義。過去，我喜歡BPEL-J over BPEL，但是現(xiàn)在如果你需要在傳統(tǒng)語言中表達一些業(yè)務邏輯，SCA使得在你鐘愛的語言中使用編制能力這一工作真的變得非常簡單（Java、C++、COBOL、PHP、ABAP……）。

資源生命周期和編制語言之間存在如此強的關系，以致于一些領先的編制引擎提供了一個狀態(tài)機范式作為創(chuàng)建你的編制定義的一種方法。IBM Process Server和微軟Workflow Foundation就是例子（如果我還忘了哪些產(chǎn)品，我要在此說聲抱歉。如果你知道的話，請告知我）。

請注意，到目前為止我一直在建議使用一個編制引擎去實現(xiàn)那些管理資源生命周期的服務，我還沒有說到業(yè)務過程或業(yè)務過程引擎。

在了解生命周期和過程之間的關系之前，我們需要注意的是生命周期是一個非常直觀的概念。大多數(shù)業(yè)務分析師隨時可以輕易地描述這些生命周期（比方說使用UML符號）?？梢赃@么說，不論他們是什么角色，組織中的任何人都可以理解這些生命周期。但是，我也要強調(diào)一下它的另一極端，幾乎沒有人有能力設計（使用BPMN進行圖形化設計）滿足涉及的所有資源生命周期的業(yè)務過程。假如你創(chuàng)建了這樣一個模型，我們就說你現(xiàn)在創(chuàng)建了一個過程的變種。你如何能保證資源生命周期不受影響？你需要進行多少Q(mào)A工作來驗證它？

過程和資源生命周期只能在過程實現(xiàn)時是一致的，而且可能要向過程“妥協(xié)”以確保它符合生命周期。這種活動只能由開發(fā)人員仔細地將業(yè)務分析師畫出的BPMN進行映射，并重用那些管理他或她組織的核心資源生命周期的企業(yè)類服務來做到。

現(xiàn)在，讓我們看看業(yè)務分析師是怎樣使用BPMN創(chuàng)建一個工作申請業(yè)務過程定義的：

圖5 工作申請過程（藍組代表人工任務邊界）

首先，BPMN連表示“資源”的符號都沒有，更別提“生命周期”了。人們最多可以在過程的某一點（如上圖）使用期望的狀態(tài)對它的BPMN定義進行注解。這非常好，BPMN就應該是這樣。其次，業(yè)務分析師完全不關心工作申請會調(diào)用哪些操作來推進它的狀態(tài)。它們屬于系統(tǒng)視角。期望業(yè)務分析師在他或她描述的用戶活動間加入“調(diào)用”活動簡直是癡人說夢。不幸的是，人們著手去建立的BPMN和BPEL之間的關系就是一個錯誤的例子。他們最終在過程符號中加入了核心BPEL操作語義，發(fā)送、接收和調(diào)用。這完全是畫蛇添足，不應該被使用，除非被接收或發(fā)送的消息是一個業(yè)務消息而不是一個被調(diào)用的操作（如一份工作申請到了一個招募者的桌上）。

怎樣實現(xiàn)業(yè)務過程？一個業(yè)務過程執(zhí)行環(huán)境是一個彼此（非集中編制的服務集合）交互的服務的裝配（圖6）。它描述了實現(xiàn)資源生命周期的編制，以及人工任務執(zhí)行、事件和推進過程的簡單服務調(diào)用的交互。

好消息是我們完全擁有了實現(xiàn)這一愿景的必需技術，包括裝配技術：服務組件架構。你在圖中看到的一切可以結合SCA 1.0、BPEL 2.0、Web Services（XSD和WSDL 1.1——因為BPEL 2.0）、BPEL4People 1.0 and Human Tasks 1.0來完成。

Bruce先前宣稱：

使用BPEL你沒有忽略你不支持的元素的自由。BPEL就是BPEL，你必須支持規(guī)范中的一切。剩余的被稱為私有擴展。它們只存在于它們自己的名字空間，BPEL 1.1的一個有根據(jù)的批評就是一個真正的過程需要太多的元素。BPEL 2.0要好一些，但是人工任務、子過程和其他的基本的東西仍需要2.0中的擴展，如，近乎神話的BPEL4People。

在這個BPMS架構藍圖中，他的言論不再有效。WS-HumanTask和BPEL4People屬于任務容器并且確實與BPEL本身隔離開。現(xiàn)在，你可以爭論BPEL是否需要“子過程”，但是我會說作為一門資源生命周期服務的實現(xiàn)語言，它并不迫切：狀態(tài)機元素極少可被重用，它們完全屬于它們的資源。

在這一點上——不幸的是——微軟并沒有參與SCA或BPEL4People，因此你不能將Workflow Foundation作為BPEL引擎的替代品，即使它能很好的完成工作。但是，你可以將WCF當作服務容器實現(xiàn)服務，你可以從SCA和你喜愛的BPEL引擎中調(diào)用這些服務。微軟本身并沒有裝配機制，因此你甚至不能在.Net中實現(xiàn)這個架構藍圖。在開源方面，你可以找到大多數(shù)組件（SCA、BPEL和服務容器），但是BPEL4People容器除外。這并不要緊，基本的人工任務容器并不是太難構建（但是還沒到BPEL4People和WS-HumanTask級別）。

為了理解開發(fā)人員在這個新架構中的角色，讓我們仔細看看過程模型的“面試安排（Schedule Interview）”活動（圖5）。如你所見，這個活動在過程模型中被進行特別對待（這是有意義的，這是因為，如果工作申請系統(tǒng)宕機了，用戶就不得不這么做），但是作為優(yōu)化，它由業(yè)務來決定，例如，任務安排在Exchange Server上自動進行。工作申請應用生命周期提供了在候選人的申請被保留后安排面試的鉤子（即，必需品）。記住工作申請服務并不知道這是如何實現(xiàn)的。它是人工任務也沒有關系。在這一點上我認為，自動解決這種設計決策完全是不可能的。這就是過程模型必須完全和任何執(zhí)行語義分離的原因。另一個不會影響過程定義的設計決策是這樣一個事實：候選人申請能發(fā)生在一個不同的人工任務容器。我們能很好地將這個過程和發(fā)生在一個流行的求職站點的候選人申請“裝配”在一起。一旦申請被批準面試，一個活動將給候選人發(fā)送一封郵件，告訴他或她下一步過程任務（復查錄用通知，輸入員工信息）。我打賭你現(xiàn)有的BPMS系統(tǒng)做不了（容易地）這件事。

作為一個附注，你現(xiàn)在可以看到任務引擎并不是一個業(yè)務過程引擎真正的子組件。當然，當今的BPMS系統(tǒng)就是這么設計的，但是事實上它確實不是，它是架構的獨立組件，管理人工任務（圖6）。這些人工任務本質上總是關聯(lián)一個或更多的業(yè)務過程，但是它們有它們自己的生命周期，而且直接和資源生命周期服務交互。正如Dominique Vauquier[1]在他文中所說的：“人工任務嫁接了資源生命周期”。此外，我們在前一段落看到，為了使“業(yè)務過程”能和幾個任務容器進行交互，它至關重要。

在此，我并不想描述規(guī)則或主數(shù)據(jù)管理的角色（對不住了，James），但是它們的確扮演了關鍵角色并且需要特殊的服務容器，這就是眾所周知的BRMS（圖6）。Michael zur Muehlen或Mark Proctor問的問題就變得完全不相關了，因為SCA使這變得不相關（從運行時的角度）。SCA會讓你選擇決策服務的最佳調(diào)用機制（技術上可行的話，它可以和你的BPEL引擎一起運行在過程中）。SCA很大程度解耦了這個架構的元素，這使得它們可以在不同的過程中被重用，同時為每個過程選擇可能的最佳運行時配置。

我也不會談到B2B的角色，在我最初的兩篇文章中，關于它們我說了很多。通過支持定義裝配內(nèi)的任意邊界，這個架構藍圖支持B2B。例如，我能“裝配購買訂單生命周期的兩個視角（買者和賣者）”。這是一個巨大的進步。傳統(tǒng)的“集中化”執(zhí)行模型在B2B邊界強加了一個人工的斷層，被迫使用兩個不同的執(zhí)行模型：在每一端的一個集中化編制，以及中間的一個裝配。在某些方面，我的提議完全是基于OASIS ebXML Business Process最初的B2B過程定義，但是應用在了資源級別，而不僅僅是業(yè)務伙伴級別。這就是執(zhí)行模型在組織內(nèi)外都連續(xù)的原因，因為它和它的業(yè)務伙伴交互。

謬誤 6：業(yè)務過程執(zhí)行語義可以簡單地從現(xiàn)有編程概念中派生出來。

我在“執(zhí)行”標準工作組（如BPML、BPEL、WS-CDL）中碰到的每個人（包括我在內(nèi)）幾乎都不是從業(yè)者。他們是開發(fā)人員和架構師。他們經(jīng)常關注復雜的數(shù)學理論（如Pi-Calculus），從來不去驗證這些理論的語義是否真的足夠支撐一個業(yè)務過程執(zhí)行。一般來說，這些技術提交者會關注3~5個用例來書寫他們的需求。這些用例通常比較簡單，很少反映“現(xiàn)實世界”業(yè)務過程的復雜性。

業(yè)務過程執(zhí)行語義很難概念化。這個過程是實際上是如此的困難，以致在我們的解決方案中絕大多數(shù)的可執(zhí)行過程依舊是痛苦的硬編碼，一次一行。如果有更好的方法，我確定它能很快被每個人接受。我被推薦去閱讀“Java開發(fā)者為什么憎恨BPM”的討論。沒有一個評論抱怨抽象的有效性。即使是代碼大仙（code Kahuna），如JBoss的首席架構師，Bill Burke（在他加入JBoss之前，我和他有過短暫的共事，當時我們一起在做一個人工任務容器）如此評論：

我認為BPM也一樣。只不過是編寫XML腳本，開發(fā)人員并不把它放在眼內(nèi)。直到我確實開始深入BPM框架……我并不認為必須提供這些增值框架。當我開始把它們當作一個可靠的和容錯的狀態(tài)機思考的時候，我開始真正意識到BPM框架的潛力。然后，當你結合你的過程和事務管理與補償使用時，你就得到了一個真的好的抽象，這在你開發(fā)你的應用時可以派上用場。

根據(jù)我在前一節(jié)的解釋，他和其他人言論的方向是正確的。開發(fā)人員現(xiàn)在看到了一遍又一遍不得不編寫狀態(tài)機的困難，以及一個通用的引擎可以減輕他們的工作（大多數(shù)情況下如此）。

謬誤 7：Bruce Silver這樣總結他的帖子：“一個協(xié)作實現(xiàn)范式，其中可執(zhí)行設計位于BPMN模型之上的層級，這是正確的道路?！?/STRONG>