封面
版權(quán)信息
O'Reilly Media Inc.介紹

前言

流程自動化工具與技術(shù)

不過流程自動化有其獨特的特征和需求，有些軟件專門為了解決這些問題而設(shè)計。分析師依此定義了與流程自動化相關(guān)的細(xì)分軟件市場:數(shù)字流程自動化( DPA)、智能業(yè)務(wù)流程管理套件(iBPMS)、 低代碼平臺、機器人流程自動化(RPA)、微服務(wù)編排、流程編排、流程監(jiān)控、流程挖掘、決策支持和自動化。

架構(gòu)師總有實現(xiàn)方案

如果你無法展示具體的示例代碼，只討論概念，那樂趣會減少一半。可運行的代碼迫使你變得精確，去思考那些概念層面可能忽略的細(xì)節(jié)——最重要的是，它通常能更好地解釋概念。我個人很喜歡一個座右銘:“架構(gòu)師總有實現(xiàn)方案。”

配套網(wǎng)站和示例代碼

https://processautomationbook.com/
https://bpmn.io/

第1章 簡介

• 流程自動化是什么
• 流程自動化的具體技術(shù)難點。
• 工作流引擎的作用及其重要性。

1.1 流程自動化

本質(zhì)上，流程(或工作流)僅指為實現(xiàn)預(yù)期結(jié)果而需要執(zhí)行的一系列任務(wù)。
流程自動化有不同的級別。主要區(qū)別在于是人工控制流程還是計算機控制流程。
任務(wù)間控制流的自動化與任務(wù)本身的自動化，兩者有重要的區(qū)別。

• 控制流的自動化。假如由人來完成任務(wù)，則計算機控制流程，并且在必要時讓人參與進來。
• 任務(wù)的自動化。任務(wù)本身是自動化的。在前面的例子中，就是將烹飪的任務(wù)交由機器完成。

如果你結(jié)合使用控制流的自動化和任務(wù)的自動化，則可以實現(xiàn)完全流程自動化，也稱為直通式流程(STP)。

推動自動化的具體原因如下:

• 重復(fù)次數(shù)多。只有當(dāng)潛在的收益超過了開發(fā)成本時，在自動化中投人的努力才是值得的。具有超高執(zhí)行量的流程是進行自動化的候選者。
• 標(biāo)準(zhǔn)化。流程需要結(jié)構(gòu)化和可重復(fù)，以便于自動化。雖然在流程自動化中實現(xiàn)一定程度的變化和靈活性是可行的，但它增加了自動化的開銷，并削弱了一些優(yōu)勢。
• 合規(guī)的一致性。可審計性，甚至規(guī)定在授權(quán)時要以可重復(fù)和可修訂的方式記錄步驟。
• 質(zhì)量需求。你可以承諾為用戶提供以特定的速度交貨的訂單。
• 信息豐富。包含大量數(shù)字化信息的流程更適合自動化。

利用Microsoft Office、Slack或Zapier等工具來自動化某些基于事件觸發(fā)的任務(wù)。

1.2 荒野大集成

下面是荒野大集成的一些特點:

• 通過數(shù)據(jù)庫集成。服務(wù)直接訪問共他服務(wù)的數(shù)據(jù)庫來進行通信，其他服務(wù)通常并不會被通知。
• 簡單的點對點集成。兩個組件之間會直接通信，通常是基于REST、SOAP或消息協(xié)議，但沒有充分描述遠(yuǎn)程通信的所有內(nèi)容。
• 數(shù)據(jù)庫觸發(fā)器。每當(dāng)你向數(shù)據(jù)庫寫人內(nèi)容時，數(shù)據(jù)庫都會再調(diào)用其他邏輯。
• 脆弱的工具鏈。

1.3 工作流引擎和可執(zhí)行流程模型

藍(lán)圖是以特定建模語言描述的流程定義。
如果你下定決心要整理荒野大集成的項目，也許還能復(fù)用大部分代碼，只需利用工作流引擎進行狀態(tài)處理和調(diào)度即可。

1.4 一個業(yè)務(wù)場景

流程建模語言（BPMN）都是通用的。

1.5 長期運行的流程

從另一個視角看每當(dāng)邏輯跨越邊界，就需要長期運行的行為。邊界有很多不同的含義。
如果你調(diào)用其他組件或資源，就跨越了技術(shù)事務(wù)的邊界。如果你的流程包含了人，則跨越了可自動化任務(wù)與不可自動化任務(wù)之間的邊界。

1.6 業(yè)務(wù)流程、集成流程和工作流

1.7 業(yè)務(wù)-IT協(xié)作

遺憾的是，不同的角色表達(dá)和理解事物的方式往往不同。
將業(yè)務(wù)流程作為討論的中心是有益的。它使得大家在大背景下更容易理解需求，同時避
免了在單獨討論功能時可能產(chǎn)生的誤解。

1.8 業(yè)務(wù)驅(qū)動及流程自動化的價值

組織通常將流程自動化應(yīng)用于:

• 構(gòu)建更好的用戶體驗。
• 快速跟進市場(使用已修改或全新的流程、產(chǎn)品或商業(yè)模式)。
• 提高業(yè)務(wù)靈活性。
• 降低運營成本。

一些商業(yè)模式甚至依賴于流程完全自動化的可能性，這對于公司的盈利、提供可預(yù)期的
快速反饋或者擴大業(yè)務(wù)規(guī)模至關(guān)重要。

1.9 當(dāng)代流程自動化工具

1.9.1 流程自動化簡史

當(dāng)時的想法是將功能分解為服務(wù)，以或多或少標(biāo)準(zhǔn)化的方式提供給企業(yè)。

低代碼的局限性

低代碼（是什么？）方案需要非常重的工具，才能讓非開發(fā)者通過拖放預(yù)置的元素來構(gòu)建流程。

缺點：

• 你無法使用行業(yè)中的最佳實踐來開發(fā)軟件，例如，實現(xiàn)自動化測試、集成你需要的框架、完善用戶界面。
• 開源或者社區(qū)提供的知識和工具改進，你通常是用不了的。
• 這些工具常常很重，很難在現(xiàn)代的虛擬化或云原生架構(gòu)上運行。

與其用低代碼流程自動化取代軟件開發(fā)，不如將軟件開發(fā)和流程自動化結(jié)合起來!

1.9.2 Camunda的故事

也是在當(dāng)時，我們合作開發(fā)了業(yè)務(wù)流程模型和標(biāo)記法( Business
Process Model and Notation, BPMN)標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)定義了一種可視化并且可直接執(zhí)行的流程建模語言。
從技術(shù)上講，Camunda 工作流引擎的工程實現(xiàn)是2013年的工程實現(xiàn)。它本質(zhì)上是一個用Java構(gòu)建的庫，使用了關(guān)系數(shù)據(jù)庫來存儲狀態(tài)。這個引擎可以嵌入你自己的Java服務(wù)中，也可以獨立運行，對外提供REST API。當(dāng)然了，我們還提供了一些額外的工具來建模或運維流程。

1.10 結(jié)論

第一部分 基礎(chǔ)知識

第2章 工作流引擎和流程解決方案

2.1 工作流引擎

2.1.1 核心功能

工作流引擎技術(shù)層面的核心功能如下:

• 持久狀態(tài)/持久化。引擎會持續(xù)追蹤所有正在運行的流程實例的當(dāng)前狀態(tài)和歷史審計數(shù)據(jù)。
• 調(diào)度。必須有一個調(diào)度機制，使引擎在需要執(zhí)行某個任務(wù)時能夠及時響應(yīng)。
• 版本化。大多數(shù)工作流引擎支持多個版本的流程定義并行存在。

2.1.2 工作流平臺的其他功能

除了核心功能外，大多數(shù)工作流引擎還提供了些附加功能。 優(yōu)秀的工具會將這些功能設(shè)計成可選的或者插件化的，讓你既可以用上超精簡的工作流引擎，也可以用上一些額外的工具。當(dāng)你看到使用這些功能的需求時，也能逐步將其添加進來。

常見的附加功能如下。

• 可視化。切實看到流程是如何實現(xiàn)的，既有利于溝通，也有利于不同角色的參與者理解當(dāng)前流程，包括開發(fā)者( “我去年怎么做的這個?")、運維(“當(dāng)時為什么要這么做?")和業(yè)務(wù)利益相關(guān)者(“現(xiàn)在這個流程是怎么實現(xiàn)的?能不能改?")
• 審計數(shù)據(jù)。工作流引擎會記錄大量關(guān)于當(dāng)下事件的審計數(shù)據(jù)，包括時間戳(例如，流程實例何時啟動和何時結(jié)束)。

2.1.3 架構(gòu)

使用工作流引擎有兩類基本的方法可供選擇，

• 將工作流引擎作為單獨的服務(wù)來運行，也就是說你的業(yè)務(wù)應(yīng)用程序與工作流引擎需要進行遠(yuǎn)程通信。
• 將工作流引擎當(dāng)作庫嵌人服務(wù)，也就是作為你的業(yè)務(wù)應(yīng)用程序的部分運行。

2.2 流程解決方案
2.3 一個可執(zhí)行的示例

2.4 服務(wù)、流程和工作流引擎

服務(wù)、工作流引擎、流程定義和流程實例之間的關(guān)系是什么?
如果你以服務(wù)的形式啟動工作流引擎，則可以在這個工作流引擎上:部署許多流程定義。對于每個流程定義，你可以啟動任意個流程實例。你還可以讓其他服務(wù)或微服務(wù)調(diào)用這個工作流引擎。

2.5 項目生命周期中常用的工作流工具

2.5.2 協(xié)作工具

在協(xié)作工具實用的功能中有一個很好的例子，就是可以把圖表分享給別人，讓他們能夠在上面評論。

2.5.4 任務(wù)清單應(yīng)用

流程模型中是可以引入一些需要人工處理的任務(wù)的。當(dāng)需要工作人員進行操作時，必須要有一些機制能夠通知他們。

2.6 結(jié)論

第3章 開發(fā)流程解決方案

3.1 BPMN

對象管理組織(Object Management Group)的網(wǎng)站

3.1.2 token:控制流的實現(xiàn)

你可以將每個流程實例當(dāng)作在流程模型中運行的token。流程啟動時，在開始事件處生成一個token。每完成一步， 它都會沿著流程路徑流向下一個任務(wù)。當(dāng)token到達(dá)結(jié)束事件時，流程實例的生命周期就到達(dá)了尾聲。
你可以將token類比成路上行駛的汽車。在每個十字路口，司機必須決定要繼續(xù)直行，還是左轉(zhuǎn)右轉(zhuǎn)。道路系統(tǒng)可以對應(yīng)為流程模型，車輛所選的任意條具體的路徑可以類比成流程實例。

3.1.3 順序流:控制執(zhí)行流

BPMN順序流( sequence flow)定義了流程中每一個步驟發(fā)生的順序。在BPMN的可視化定義中，順序流是兩個節(jié)點的連線，箭頭的方向體現(xiàn)了它們的執(zhí)行順序。

3.1.4 任務(wù):工作單元

在BPMN流程中，任務(wù)是一個原子的工作單元。每當(dāng)token到達(dá)任務(wù)的位置時，token 都會停下，直到任務(wù)完成。之后，它才會沿著順序流流出。
任務(wù)粒度如何選擇取決于建模流程的人。例如，處理訂單的動作可以建模為一個任務(wù)，也可以分為支付確認(rèn)、提取貨物和發(fā)出貨物三個獨立任務(wù)。
通常最困難的部分是定義你的任務(wù)及其順序。一旦這些清晰了，你可能會先從人工任務(wù)開始制作原型(一個只能“點點點”的模型)，也可能在生產(chǎn)環(huán)境中發(fā)布第一個迭代。

3.1.5 網(wǎng)關(guān):流程方向盤

并行網(wǎng)關(guān)為了激活多個順序流會生成新的token。
流程是與等待相關(guān)的，所以” 并行”的含義基本上是說，你可以在某條路徑等待時在另一條路徑上做些什么。

3.2 關(guān)聯(lián)流程模型與代碼實現(xiàn)

關(guān)于如何關(guān)聯(lián)流程模型與代碼實現(xiàn)，但添加這些邏輯有三種常見的思路:訂閱流程、引用代碼和使用預(yù)建的連接器。

3.2.1 發(fā)布/訂閱流程

消息代理提供隊列。消息發(fā)送方可以將消息發(fā)布到隊列，接收方可以訂閱隊列，然后就可以接收到消息。接收方無須了解發(fā)送方。

3.2.4 模型還是代碼

細(xì)節(jié)太多的模型不僅變得難以維護，而且圖形化的價值也不復(fù)存在。
以下三個問題可以幫助你決定放在哪里。

你需要在哪里(隱式地)停下

參與者需要定期討論什么

你需要定期與其他參與者討論，過去的經(jīng)驗告訴了我一條重要的規(guī)則:所有討論的內(nèi)容都應(yīng)該放在圖形模型中。
你可能還想發(fā)掘不同的人群對哪些關(guān)鍵效能指標(biāo)(KPI)感興趣。

什么在跨越邊界

如果你想調(diào)用兩個軟件或服務(wù)，而這兩個軟件又不能在一個技術(shù)事務(wù)中， 這時你應(yīng)該將這兩個調(diào)用分離到它們自己獨立的任務(wù)中。

3.3 測試流程

3.4 流程解決方案的版本管理

系統(tǒng)中總是有正在運行的流程實例，如果你要更新流程模型，就必須直面這樣的狀況。
因此工作流引擎提供了版本管理功能:

• 流程模型修改后一旦部署，就會創(chuàng)建一個新版本。
• 活躍的流程實例將繼續(xù)以它們啟動時的版本運行。
• 新創(chuàng)建的流程實例將使用新版本的流程模型運行(除非你明確指定啟動舊版本)。

多版本并行運行

膠水代碼和數(shù)據(jù)定義的版本化

或者，你可以修改代碼，確認(rèn)有新字段時才使用它。雖然這會讓代碼更復(fù)雜，但卻有一個明顯的優(yōu)勢:如果你將流程實例遷移到新版本，它什么都不需要做就能正常運行。缺點是，隨著時間的推移會積累無效代碼，為了避免這樣，你應(yīng)該定期檢查是否有任何版本依然需要這些代碼，如果不再需要，就進行清理。

3.5 結(jié)論

第4章 萬物皆可編排

來看看流程自動化可以為你解決哪些問題。工作流引擎是可以編排任何事物的，

• 軟件組件
• 決策
• 人
• RPA機器人及物理設(shè)備

什么是編排(orchestration)。 在云原生社區(qū)中，編排通常指的是容器管理，是Kubernetes等工具所做的工作。在流程自動化領(lǐng)域，編排實際上是指協(xié)調(diào)配合(coordination) 。

4.1 編排軟件

4.1.2 微服務(wù)

這樣你就可以自行決定如何實現(xiàn)或修改服務(wù)(只要你不破壞API)。不必要求別人為你做任何事情，也不必踏上發(fā)布列車。團隊能夠快速交付修改，在事實上提高了行動力，團隊成員會因為掌控著服務(wù)而真正感到被賦予了權(quán)利。

4.1.4 模塊化的單體架構(gòu)

工作流引擎可以作為依賴庫嵌人你的單體架構(gòu)中。流程定義只是所有源代碼中的一個附加資源。

4.1.5 解構(gòu)單體架構(gòu)

4.2 編排決策

這個領(lǐng)域名為決策自動化。其核心組件是決策引擎，你可能發(fā)現(xiàn)這和工作流引擎有一些相似之處， 但不同的是決策不會長期運行，決策可以在一個原子步驟中進行。

4.2.1 DMN

決策也有一個全球通用的標(biāo)準(zhǔn):決策模型和標(biāo)記法（DMN）。
讓我們簡單看看DMN能做什么。我想在本書中重點闡述兩個概念:

• 決策表。表格（各種情況類別與決策結(jié)果的匯總表）非常適合表達(dá)決策邏輯和業(yè)務(wù)規(guī)則。
• 表達(dá)式語言。所以DMN定義了FEEL (Friendly-Enough Expression Language)。

但使用FEEL也能創(chuàng)建更復(fù)雜的邏輯表達(dá)式。下面這些表達(dá)式都是可行的:

Party.Date < date( "2021-01-01")
Party.NumberOfGuests in [25..100]
not( Party.Cancelled )

在實際存儲時，DMN決策表存儲為XML文件，下面是偽代碼實現(xiàn)的例子:

input = Map 
	.putValue("paymentType", "invoice")
	.putValue("customerRegionScore", 34) 
	.putValue("monthlyPayment", 30);

decisionDefinition = dmnEngine.parseDecision('automaticProcessing.dmn')
output = dmnEngine.evaluateDecision(decisionDefinition, input)

output.get('manualCheckNecessary')

4.3 編排人

4.3.1 任務(wù)分配

一個重要的問題是某個任務(wù)應(yīng)該由誰執(zhí)行。
你可以對候選人和執(zhí)行人進行區(qū)分。任何一個候選人都可以被分配任務(wù)。在工作開始的時候會聲明第一個候選人是執(zhí)行人，之后任務(wù)才會進入個人清單中。

4.4 編排RPA機器人

RPA工具能自動控制現(xiàn)有的圖形化用戶界面。其核心主題是屏幕抓取、圖像處理、OCR 和機器人操作GUI。

當(dāng)然，機器人總是比真正的API調(diào)用更加脆弱，因此無論何時，你都應(yīng)該優(yōu)先使用API。但現(xiàn)實世界總是充滿了阻礙。系統(tǒng)可能井不提供你需要的API。

4.5 編排物理設(shè)備和其他事物
4.6 結(jié)論

第5章 選擇工作流引擎和BPMN

5.1 其他實現(xiàn)方式的局限性

5.1.2 批處理

在這個例子中，客戶在線請求更新信用額度。此請求不會立即被處理(一般叫在線處理)，而是在隊列中等到下一次批處理時運行。觸發(fā)后，這一批次中 正在等待的所有事項都會被立刻處理。
批處理在流程自動化方面的缺陷：

• 批處理增加了每個獨立工作單元的處理時間，拉長了流程周期。
• 流程不可見，因為它隱藏在一個個批處理作業(yè)的交替中。

5.1.3 數(shù)據(jù)流水線和流式處理

流式數(shù)據(jù)(data streaming)背后的思想是從靜態(tài)數(shù)
據(jù)轉(zhuǎn)向動態(tài)數(shù)據(jù)。
市場上的一些工具指的是data pipeline (數(shù)據(jù)流水線)或data flow,而不是data stream,而另一些工具是指事件流也不是數(shù)據(jù)流。

缺陷：
流程實例并不真實存在，因為只有數(shù)據(jù)流經(jīng)隊列。你無法審視整個流程的真實運行方式。最近我聽說了尼爾.福特發(fā)明的彈球機架構(gòu)（pinball machine arhitecture）一詞，我覺得他抓住了這個架構(gòu)的精髓。
你修改流程的能力也有限，主要是因為修改你不理解的內(nèi)容確實很難。

常見的工具只允許創(chuàng)建無環(huán)模型，也就是說你無法實現(xiàn)回環(huán)(loop back)。通常，在許多流程中你都會操作循環(huán)。例如，用戶可能會修改訂單，可能會撒銷付款.叉車可能會略過漂亮的小包爽。現(xiàn)實世界可能會發(fā)生很多事情，令你不得不回到流程的開始階段。

5.1.4 actor模型

actor 模型是處理并發(fā)計算的一種方法。 它基于消息傳遞：基本概念是有一個單一職責(zé)的軟件組件，即所謂的actor。actor之間以及actor 和自己只能以消息的方式通信。由于并行處理通常被限制在單一的actor中，因此你不僅可以使用隊列，還可以讓整個系統(tǒng)進行擴縮容。

缺陷：

• 因為沒有建模語言，所以無法支持長期運行所需的那種模式。
• 流程邏輯隱藏在源代碼中，不可見，這使得所有關(guān)心流程的人都難以理解流程。

5.1.5 有狀態(tài)函數(shù)

缺陷：

• 因為沒有建模語言，所以無法表達(dá)長期運行所需的那種模式。
• 流程邏輯沒有圖形化的形式，這讓業(yè)務(wù)人員、開發(fā)人員和運維人員之間很難協(xié)作。
• 調(diào)度和版本控制相關(guān)的支持非常有限。

5.2 流程建模語言

總的來說，反對XML的兩個觀點(它太古老，并且很難合井)經(jīng)不起推敲。
不過讓我們退后一步，談?wù)勗谶x擇流程建模語言時審視真正重要的方面:

• 這種語言支持什么樣的行為?這個問題定義了語言整體的成熟度，決定了你選擇的語言是否會遇到無法建模的情況。
• 圖形化展示給表格帶來了什么價值?應(yīng)該使用基于圖形化的建模語言嗎，還是說基于文本的語言就足夠了?

5.2.1 工作流范式

為了判斷流程建模語言是否提供了你所需的功能，可以參考Workflow Patterns主導(dǎo)定義的范式，他們主導(dǎo)的研究已經(jīng)完成:
對于工作流語言或業(yè)務(wù)建模語言需要支持的各種方向(控制流、數(shù)據(jù)、資源和異常處理)，這個網(wǎng)站都提供了全面的檢查項，可用于檢查某個工作流語下和工作流系統(tǒng)是否適合某一項目。

工作流范式及BPMN中的映射
http://www.workflowpatterns.com/patterns/

范式名稱	BPMN元素	描述
順序流（sequence）	A->B	一個任務(wù)在流程中的另一個任務(wù)完成后啟動
并行分支（parallel split）	<+>	一個分支分為兩個或多個并行的分支， 每個分支并發(fā)執(zhí)行
同步（synchronization）	<+>	兩個或多個輸入分支匯聚為一個后續(xù) 分支，當(dāng)所有的輸入分支都到達(dá)時， 線程才會將其傳遞給后續(xù)分支
排他選擇（exclusive choice）	<×>	分支分為兩個或多個不同的分支，當(dāng) 輸入分支到達(dá)時，控制線程會根據(jù)某 種傳出分支選擇機制立刻選出一個分 支進行后續(xù)操作
簡單匯聚（simple merge）	<×>	將兩個或多個分支匯聚到一個后續(xù)分 支中，輸入分支中的任意一個到達(dá)都 會觸發(fā)控制線程的向后傳遞

5.2.2 圖形流程可視化的優(yōu)勢

圖形流程可視化的好處很明顯:模型的可見性和可理解性，以及和不同干
系人討論時的易用性。
運營人員也能利用圖形模型，例如可以在流程實例中標(biāo)記遇到的問題。
圖形模型能在開發(fā)者之間進行對齊。解釋某個流程、算法或其他復(fù)雜軟件實現(xiàn)。他們真的給你看了一堵寫滿代碼的墻嗎?他們帶你瀏覽了一份長篇累牘的文檔嗎?還是說，他們在白板上畫了一幅圖來解釋核心概念? 我打賭是后者。
BPMN等語言的核心元素是一些方框和箭頭，大多數(shù)人都能直觀地理解它
們。
實現(xiàn)圖形流程可視化有兩種方法。最簡單的方法是像BPMN那樣創(chuàng)建一個包含圖形信息的流程模型。記住，專有的符號限制了可視化在與其他角色協(xié)作時的價值。
另一種方法是基于流程模型自動生成可視化內(nèi)容，這種模型甚至只能以文本形式使用。

5.2.3 純文本流程建模方案

最常見的方法是使用JSON或YAML來定義流程模型:

{
  "name": "sample-workflow",
  "version": 1,
  "tasks": [
    {
      "name": "task_1",
      "type": "SIMPLE"
    },
    {
      "name": "someDecision",
      "type": "DECISION",
      "decisionCases": {

5.2.4 關(guān)于圖形化建模的常見問題

一些開發(fā)者不太喜歡圖形化建模語言。下面是一些常見問題的概要:

• 其中隱藏著魔法。由于圖形化建模工具通常將某些邏輯和配置隱藏在屬性面板或向?qū)е校恢肋@些工具存在的用戶會感覺他們遺漏了關(guān)鍵的事物。另一個可行的策略是在開始時使用代碼對流程進行建模，并在流程模型變得更加復(fù)雜后立刻切換到圖形化建模方法。

另一個擔(dān)憂是，一旦你擁有了可理解的圖形模型，業(yè)務(wù)利益相關(guān)者能隨時干預(yù)開發(fā)過程，并且希望加入與解決方案設(shè)計有關(guān)的所有對話。這主要與項目中的不同角色互相尊重有關(guān)。

5.2.5 圖形化與文本化

請記住，只在流程模型中以圖形方式表達(dá)任務(wù)本身的順序，然后將其他邏輯的代碼與它關(guān)聯(lián)。這樣在兩個方向上，你都能獲得最佳的體驗。

5.3 區(qū)塊鏈上的流程自動化

劇透警告:對于公司內(nèi)部流程的自動化來說，它不會有太大影響。它只影響多方合作。
這是一個無解的情況，我不想在拿到汽車的產(chǎn)權(quán)憑證之前轉(zhuǎn)賬，經(jīng)銷商也不想在收到錢之前發(fā)送產(chǎn)權(quán)憑證。
與互不信任的合作伙伴做生意是區(qū)塊鏈方案的最佳使用場景。在這種情況下，解決信任缺失問題的經(jīng)典方法是引入值得信賴的第三方，如銀行、公證人或一些專門服務(wù)。
智能合約能讓汽車購買流程的公共部分自動化——只限于雙方都達(dá)成一致的部分。

5.4 結(jié)論

第二部分 企業(yè)級流程自動化

如果你的組織非常成功，就會有規(guī)模化的需求。為了更快地開發(fā)出更多功能，企業(yè)需要增加開發(fā)團隊。為了能順利地擴張團隊，就需要將服務(wù)拆分并分配給各個團隊。
但所有的這些用戶都不關(guān)心，用戶只關(guān)心端到端的業(yè)務(wù)流程(比如，盡快發(fā)貨的訂單)。

第6章 解決方案架構(gòu)

6.1 何時使用工作流引擎

工作流引擎有兩個主要的優(yōu)勢:它為你的應(yīng)用程序或服務(wù)增加了長期運行的能力，井且使你的流程邏輯可視化。
一旦價值(回報)超過引人工作流引擎的努力(投人)， 工作流引擎就會對你的架構(gòu)產(chǎn)生積極影響。確切的閾值很大程度上取決于所選工具引入的難易。我推測，隨著工具變得越來越輕量級或者直接作為托管服務(wù)提供，引人的難度將在未來幾年進一步下降。
也有一些使用方法沒什么意義。例如，使用BPMN進行圖形化編程，也就是說，你只是簡單地用圖形模型表達(dá)代碼邏輯，而不是控制狀態(tài)或者與其他角色進行協(xié)作。

6.2 架構(gòu)權(quán)衡

6.2.1 運行工作流引擎

第一個也是最重要的問題是:你如何運行工作流引擎本身?

1. 確保你選擇的引擎適合你的現(xiàn)狀。
2. 你還需要了解工具的靈活性程度。

6.3 評估工作流引擎

最重要的是工具要符合本書中使用的定義，即它們可以處理持久狀態(tài)以實現(xiàn)長期運行的流程，我把它們分類為：

• 開發(fā)者友好的工作流引擎或工作流自動化平臺(例如 Camunda)，本書對這類工具進行了非常詳細(xì)的討論。
• 托管的編排工具或工作流引擎，例如AWS Step Functions或Camunda Cloud。
• 提供開源代碼的自研編排工具和工作流引擎(例如Netflix Conductor)。 這些開源項目接近輕量級工作流引擎，但它們通常很難修改，并且沒有任何保障。
• BPM套件(例如Pega)。
• RPA工具(例如UiPath)。
• 低代碼平臺(例如Zapier,其目標(biāo)用戶希望在不需要任何軟件開發(fā)的情況下在類似Office的工作流內(nèi)自動化任務(wù)。

其他工作流工具：

• 數(shù)據(jù)流水線工具(例如Apache Airflow)能以圖形化方式建模數(shù)據(jù)流水線。
• 集成工具(例如Apache Camel)能很好地解決集成問題。

最后，有一些類別的工具屬于流程自動化領(lǐng)域，但更側(cè)重于可見性方向。例如:

• 分布式追蹤工具(例如Jaeger)能可視化請求如何在技術(shù)層面流過系統(tǒng)。
• 流程挖掘工具(例如Celoni) 可以幫你了解遺留系統(tǒng)是如何實現(xiàn)的。

評估標(biāo)準(zhǔn)包括：

• 集成的可能性。如何關(guān)聯(lián)流程模型與代碼？能使用自己選擇的編程語言嗎？
• 部署選項和支持的環(huán)境。引擎本身如何運行？
• 工具。它是否擁有你需要的所有工具？
• 流程建模語言。支持BPMN嗎？
• 許可證和支持。你能訪問源代碼嗎（以防萬一）？

6.4 結(jié)論

第7章 自治、邊界和隔離

7.1 高內(nèi)聚低耦合

正如Sam Newman在他的Monolith to Microservices (O'Reilly) 一書中所說，” 需要起修改的代碼，就要放在一
起。”其理念就是，業(yè)務(wù)功能預(yù)期中的一個變更(理想情況下)僅應(yīng)該更改一個組件。
Sam Newman定義的4種類型：

• 實現(xiàn)耦合。如果有別的組件使用了你組件內(nèi)部的實現(xiàn)知識你將遇到實現(xiàn)期合，一個非常常見的例子是，若另一個組件會查詢你的數(shù)數(shù)據(jù)庫表，那么之后你就很難修改這個表結(jié)構(gòu)。
• 時間耦合。在分布式系統(tǒng)中的同步通信中，你依賴于對端服務(wù)的可用性。這就是時間耦合。
• 部署耦合。為了運行軟件，你必須構(gòu)建一個部署單元，其中可能會包含其他的庫、資源或流程模型。即使大多數(shù)制品保持不變，部署單元也必須整體重新部署。部署耦合的另一個例子是發(fā)布列車(release train)。
• 領(lǐng)城耦合。在為最終用戶創(chuàng)建有意義的業(yè)務(wù)功能時，組件之間的一些耦合是不可避免的。

7.2 領(lǐng)域驅(qū)動設(shè)計、限界上下文和服務(wù)

基本概念是，你需要對任何模型界定清晰的邊界，使其集中和統(tǒng)一。這使模型更有可能正確且有效。

DDD著重確保術(shù)語在單個限界上下文中是統(tǒng)一的，即使它們在不同上下文中可能表示不同的事物。
另一個例子是消費者。大多數(shù)上下文都與這個概念相關(guān)，但它們著重于不同的方面:在訂單履約中只需要知道消費者的身份，在發(fā)貨時只需要地址，在支付時只需要知道支付
的詳細(xì)信息。因此，不同的上下文可能對消費者和訂單有不同的定義,即使它們使用了相同的術(shù)語。

7.3 邊界和業(yè)務(wù)流程

但我為什么要在流程自動化的書中寫這些?好問題!上下文和邊界極大地影響了你的業(yè)務(wù)流程設(shè)計，反過來說也是一樣，原因如下：

• 許多端到端的業(yè)務(wù)流程在其生命周期內(nèi)會觸及多個上下文。
• 建模和討論業(yè)務(wù)流程，特別是在端到端層級上，可以幫助你發(fā)現(xiàn)邊界的蹤跡。
• 在上下文中使用工作流引擎，能讓你看到許多問題其實具有長期運行的特性。

7.3.1 維護邊界，避免單體架構(gòu)流程

Real-Life BPMN
如何劃分事物，其本質(zhì)是如果出現(xiàn)問題應(yīng)該歸咎于誰。劃分服務(wù)表達(dá)了責(zé)任和問責(zé)的本質(zhì)。

7.3.2 加強對職責(zé)的理解

你必須思考組織中每個服務(wù)的業(yè)務(wù)職責(zé)。其中最重要的問題是:

• 這個服務(wù)負(fù)責(zé)的業(yè)務(wù)產(chǎn)出是什么?
• 它需要保證哪些SLA ?

7.4 流程間通信如何跨越邊界

流程間通信有兩個基本選項:

• 調(diào)用活動。使用BPMN的結(jié)構(gòu)以利用工作流引擎的功能調(diào)用其他流程。
• API調(diào)用。向另一個服務(wù)發(fā)起普通的API調(diào)用，調(diào)用的服務(wù)在內(nèi)部啟動一個流程實例。

7.5 分散式工作流工具
7.6 結(jié)論

第8章 平衡編排與編制

微服務(wù)的興起與事件驅(qū)動架構(gòu)(event-driven architecture)相關(guān)。在這種架構(gòu)中，每當(dāng)有實質(zhì)性的事情發(fā)生時，服務(wù)就會發(fā)出(emit) 事件，其他服務(wù)可能會對這些事件做出響應(yīng)。這就是編制。

8.1 事件驅(qū)動系統(tǒng)

在事件驅(qū)動的替代方案中，庫存服務(wù)將庫存商品數(shù)量的任何變更都作為事件發(fā)布。結(jié)算服務(wù)可以監(jiān)聽這些事件，并使用這些信息計算和存儲庫存商品的剩余量。這避免了時間偶合，甚至還為庫存服務(wù)分散了壓力。

8.1.2 事件鏈

支付服務(wù)可以監(jiān)聽結(jié)算服務(wù)發(fā)出的下單事件，收到后處理每個訂單的支付結(jié)果。處理完支付后會發(fā)出收到付款事件，而庫存服務(wù)監(jiān)聽這個事件。
但這個場景有所不同，事件訂閱之間存在某種關(guān)系，從而導(dǎo)致了事件鏈的產(chǎn)生。

缺乏可見性

事件散落在各個代碼庫中，因此你必須對所有的代碼庫進行推敲才能了解整個系統(tǒng)。

8.2 編排和編制的對比

8.2.1 命令簡介

回顧一下：事件是已發(fā)生的事情，是事實。組件A發(fā)布事件來通知所有人，但它對這個事件產(chǎn)生的影響沒有任何期望。組件B決定是否對這個事件做出反應(yīng)。
與此相對地，組件A也可以向組件B發(fā)送命令。這表示A想讓B做些什么，有一個明確的意圖，B不能輕易忽略這個命令。

8.2.3 術(shù)語和定義

• 命令驅(qū)動通信=編排
• 事件驅(qū)動通信=編制

8.2.5 依賴的方向

兩個服務(wù)之間每增加一次通信都會增加 定程度的期合。 但這里有一個很有趣的點，你可以選擇依賴的方向，以此來決定哪些組件之間產(chǎn)生耦合。
當(dāng)服務(wù)監(jiān)聽事件時，作為接收方與這事件“領(lǐng)城耦合"。或者說它知道要在哪個通道接受這個事件，知道這個事件的含義，以及可能會有的附加數(shù)據(jù)是什么結(jié)構(gòu)。依賴的方向是從接收方到發(fā)送方。正如你在本章前面所看到的，并非在所有情況下都是好選擇。
與事件相對的，一個服務(wù)還可以向另一個服務(wù)發(fā)送命令。為此，發(fā)送方必須知道命令的含義，要發(fā)送到哪個通道，以及可能會有的附加數(shù)據(jù)是什么。依賴的方向是從發(fā)送方到接收方，發(fā)送方與接收方“ 領(lǐng)域耦合”。

8.3.1 選擇使用命令還是事件

如果一個事件被忽略，導(dǎo)致組件遺漏了一件事，這種情況是可接受的嗎?這個問題是個不錯的試金石。如果回答是，那么它就真的是一個事件：如果回答不是，那你面對的可能是一條命令。

8.3.3 設(shè)計職責(zé)

在設(shè)計通信鏈路時，你需要充分考慮每個組件的職責(zé)。在發(fā)送方無須對接下來發(fā)生的事情負(fù)責(zé)的情況下，應(yīng)該使用事件。在發(fā)送方需要確認(rèn)某些事情會發(fā)生的時候，應(yīng)該使用命令。
如果你忽視了職責(zé)的劃分，最終會發(fā)現(xiàn)團隊無法控制所要負(fù)責(zé)的范圍。這會導(dǎo)致團隊相互指責(zé)，情緒沮喪。
如果你沒有正確設(shè)計職責(zé)，將構(gòu)建出需要團隊之間大量討論和協(xié)作的系統(tǒng)，因為你通常不得不一起更改多個部分。 ^1b708a

8.4 澄清常見的誤解

8.4.1 命令不需要同步通信

命令(及事件)獨立于通信協(xié)議。
重要的是要理解，時間耦合是由同步通信本身產(chǎn)生的，而不是由選擇使用命令產(chǎn)生的。

8.4.2 編排并不一定是集中式的

編排只是意味著指揮(或協(xié)調(diào))另一個組件。 每個組件都可以做到這一點，這不需要擁有一個集中式的編排器。

8.5 工作流引擎的作用
8.6 結(jié)論

第9章 工作流引擎與集成挑戰(zhàn)

9.1 服務(wù)間調(diào)用的通信模式

9.1.1 同步請求/響應(yīng)

正如Peter Deutsch及Sun Microsystems公司的其他人提出的分布式計算謬誤中所說的，遠(yuǎn)程通信本質(zhì)上是不可靠的。

9.1.1 異步請求/響應(yīng)

假設(shè)有這樣一個業(yè)務(wù)需求，你的服務(wù)需要等待某些請求的答復(fù)才能真正繼續(xù)。而這個響應(yīng)過程可能需要一定的時間，并且是異步送達(dá)的。

為了支持異步通信，工作流引擎提供了一些機制來尋找處于等待中對應(yīng)的流程實例。假設(shè)實例發(fā)出了一條消息來做支付確認(rèn)，其中包含了一個事務(wù)ID。當(dāng)響應(yīng)到達(dá)時也會帶有這個事務(wù)ID，工作流引擎就能夠依靠ID識別正在等待這個響應(yīng)的實例。

9.1.4 聚合消息

聚合器：
使用一個有狀態(tài)的過濾器(聚合器)來收集和存儲單條消息，直到收到完整的相關(guān)消息集。然后，聚合器會發(fā)布一條從單個消息中提煉出來的消息。

9.1.5 毒丸與死信

毒丸消息( poisoned message)。當(dāng)前端出現(xiàn)錯誤，把一些破損的數(shù)據(jù)放入該消息，使消息“帶毒”，你的服務(wù)在處理這條消息時就會拋出異常。
你無法將此異常交給任何客戶端，因此消息系統(tǒng)必須處理它。默認(rèn)的處理方式是給接收端重發(fā)消息，但這沒什么幫助，只會增加負(fù)載。在設(shè)定的重試次數(shù)過后，消息系統(tǒng)一般
會將其放入死信隊列(Dead Letter Queue, DLQ)。
使用工作流引擎，一個失敗的流程實例會給你提供很多上下文數(shù)據(jù)，例如它從哪里開始、選擇什么路徑，以及附加什么數(shù)據(jù)。

9.1.6 隱藏在同步facade背后的異步通信

接收響應(yīng)的方式有三種：

• 訂閱發(fā)送響應(yīng)消息的通道。
• 提供一個回調(diào)API。
• 定期進行輪詢，看看結(jié)果是否可用。

其共同點是，你必須考慮超時問題，因為你不能永遠(yuǎn)等待，永遠(yuǎn)阻塞。這意味著你需要考慮如果在限定時間內(nèi)沒有響應(yīng)該怎么處理。
我經(jīng)常看到的一種模式是， 當(dāng)一切正常時同步返回，出現(xiàn)錯誤時退回到異步處理。

9.2 事務(wù)和一致性

9.2.2 處理不一致的業(yè)務(wù)策略

解決不一致問題

在實例層面上解決不一致問題， 無須等待任何批處理的運行：Saga模式和發(fā)件箱模式。

9.2.3 Saga模式和補償

Saga模式描述了分布式系統(tǒng)中長期運行的事務(wù)。其主要思想很簡單：當(dāng)你無法回滾任務(wù)時，就撤銷它們。
BPMN通過補償事件來支持這個模式，補償事件可以將任務(wù)與對應(yīng)的撤銷任務(wù)關(guān)聯(lián)起來。

9.2.4 使用發(fā)件箱模式鏈接資源

另一個有趣的模式是發(fā)件箱模式(outbox pttern)。假設(shè)你構(gòu)建了一個執(zhí)行某些業(yè)務(wù)邏輯的服務(wù)，它會將結(jié)果持久化在一個關(guān)系型數(shù)據(jù)庫中，然后在事件總線上發(fā)送一個事件。正如本章前面所解釋的，你不能對兩個使用不同資源(這里指數(shù)據(jù)庫和事件總線)的任務(wù)使用ACID事務(wù)。（問題難點）
在這種模式的典型實現(xiàn)中，服務(wù)將需要發(fā)布的事件寫人領(lǐng)城數(shù)據(jù)所在的關(guān)系型數(shù)據(jù)庫中，但需要寫入另張單獨的表。這個表就被稱為發(fā)件箱。表在同一個數(shù)據(jù)庫中，服務(wù)就可以使用數(shù)據(jù)庫的ACID事務(wù)，持久化業(yè)務(wù)邏輯的結(jié)果以及寫人事件可以是原子的。（解決辦法）
你還可以利用工作流引擎。這樣的話，你根本不需要一個單獨的發(fā)件箱表。
首先，業(yè)務(wù)邏輯將被執(zhí)行并提交結(jié)果。只有當(dāng)這一過程成功時，事件才會在第二個任務(wù)中被發(fā)布到事件總線上。

9.3 最終一致性適用于各種形式的遠(yuǎn)程通信

過去，有人試圖將遠(yuǎn)程通信的實際內(nèi)容隱藏在框架后面。例如，在你的源代碼中，REST調(diào)用可能看起來像本地方法調(diào)用一樣。 開發(fā)者得到的感受是他們執(zhí)行完就能立刻得到結(jié)果。 ^166c1f

9.4 冪等性的重要性

冪等性操作定位為“可多次執(zhí)行而不改變第一次執(zhí)行結(jié)果的操作”。
一個好的工作流引擎也提供冪等操作，這樣你就可以確保只為一個給定的key啟動一個流程實例。

9.5 結(jié)論

第10章 業(yè)務(wù)-IT協(xié)作

10.1 一個典型的項目

10.2 所有人：BizDevOps

讓我們透過業(yè)務(wù)、開發(fā)和運維(簡稱BizDevOps)之間的合作更細(xì)致地討論一下流程自動化工具的價值。

10.2.1 開發(fā)

可執(zhí)行流程模型是活文檔，當(dāng)流程發(fā)生變更時，它不會像其他沒有與代碼關(guān)聯(lián)的架構(gòu)圖一樣逐漸過時。即使是最規(guī)范化的開發(fā)流程，在程序需要緊急修復(fù)的情況下也無法避免遺忘更新文檔。

10.2.2 業(yè)務(wù)

有一個奇怪的現(xiàn)象：使用流程模型的項目在最初分析階段常常出現(xiàn)工作量激增的情況。流程模型不是應(yīng)該幫助減少工作量嗎?
事實上，由于圖形模型很容易理解，項目組往往會在流程設(shè)計早期發(fā)現(xiàn)流程設(shè)計存在問題，比如設(shè)計缺乏清晰度。

10.2.3 運維

以往，運維人員需要根據(jù)數(shù)據(jù)庫中的日志文件和數(shù)據(jù)開展工作。這限制了他們理解整個流程以及自己解決問題的能力。解決故障的唯一方法就是讓那些對應(yīng)用程序 了如指掌的開發(fā)人員參與進來。
使用可視化的圖形流程能幫助運維人員在上下文中理解事件，其中包括流程模型、歷史信息，附加到流程實例上的數(shù)據(jù)，以及有關(guān)錯誤或異常的詳細(xì)信息。

10.3 一體化模型的力量

在觀察過成功的項目后，我得出一個重要的結(jié)論，業(yè)務(wù)人員和開發(fā)人員之間的協(xié)作絕對不是一方迫使另一方接受定義好的模型。成功來自真正的合作。

從流程金字塔到房子

BPMN能讓你在一個大圖表中建模所有的流程，這個圖表叫作協(xié)作模型。從技術(shù)上講你還是單獨創(chuàng)建流程，只不過將它們放在一個圖上并表達(dá)通信關(guān)系。（房子）
BPMN中，這三個矩形被稱為泳道(pool)。每個泳道都是個完整的流程。 你可以將每個流程視為整個業(yè)務(wù)流程的一個具體視角。

10.4 誰來建模

業(yè)務(wù)分析師思考業(yè)務(wù)需求，專注于“是什么”和“為什么”，盡量忽略“怎么做””(為解決方案留下空間，讓開發(fā)者決定如何進行選擇)。業(yè)務(wù)分析師通常是創(chuàng)建流程模型初稿的人，當(dāng)然， 這也會塑造可執(zhí)行流程。
關(guān)注可執(zhí)行模型，你需要避免讓業(yè)務(wù)分析師覆蓋或刪除那些在他們的工具中不可見的技術(shù)屬性。這就是為什么可執(zhí)行模型的所有權(quán)必須歸開發(fā)者所有。

10.5 創(chuàng)建更好的流程模型

許多不同角色的人都需要理解你的流程模型(理想情況下應(yīng)該無須進一步的解釋)， 這些模型是具有很長壽命的人工制品。
一個正在生產(chǎn)環(huán)境中的不完美模型比一個從未被執(zhí)行過的完美模型更有價值。

10.5.1 將邏輯提取(集成)到子流程中

有些人更喜歡大模型，包含所有的細(xì)節(jié)，然后應(yīng)用建模慣例來保持它們的可讀性。

10.5.3 提高可讀性

從左到右建模，遵循樂觀路線

從左到右建模流程圖(或者相反，如果你所處的文化是這樣書寫的話)，特別注意不要從上到下。這考慮了閱讀方向，還考慮了人類的視野，人們更喜歡寬屏。

10.6 結(jié)論

第11章 流程可見性

11.1 流程可見性的價值

可見性在兩個方面實際影響流程的性能：

• 流程改進(持續(xù)性的)
• 流程運維

流程可見性對所有的運維人員都有幫助。其中一個有趣的內(nèi)容是提供志勢感知(situation awareness)。認(rèn)知心理學(xué)在這一領(lǐng)城有很多研究， 證明態(tài)勢感知對運維人員的決策結(jié)果至關(guān)重要。
有個案例很有趣，是在空中交通管制和核電站控制室的背景下的一項研究。研究報告“The Impact of Process Visibility on Process Performance"(https://oreil.ly/gPTjq)的作者發(fā)現(xiàn)，“運維人員必須能夠隨時了解當(dāng)前的流程狀態(tài)，并有能力充分利用這些知識來預(yù)測未來的流程狀態(tài)以及控制流程達(dá)到運維目標(biāo)”。

11.2 獲取數(shù)據(jù)
11.3 狀態(tài)查詢

11.4 理解跨多個系統(tǒng)的流程

11.4.1 可觀測性與分布式追蹤工具

最常見的例子是分布式追蹤，它致力于追蹤不同系統(tǒng)和服務(wù)之間的調(diào)用棧。它的實現(xiàn)方式是創(chuàng)建一個用來追蹤的唯一ID,將其添加到所有遠(yuǎn)程調(diào)用中(例如添加到HTTP Header或消息頭)。
https://zipkin.io/

11.4.2 自定義集中式監(jiān)控

與其收集技術(shù)蹤跡，不如收集有意義的業(yè)務(wù)事件或領(lǐng)域事件。這樣你能夠獲得恰當(dāng)粒度的信息。
你還可以利用圖形化流程模型將這些信息可視化。比如，bpmn.io這種輕量級的開源JavaScript框架就可以輕松創(chuàng)建HTML頁面。 ^ce3eb9

11.4.4 流程挖掘

還有一類完全不同的工具：流程挖掘( process mining)工具。
流程挖掘工具可以發(fā)現(xiàn)流程模型，并以圖形的方式將其可視化。
換句話說，這些工具擅長分析日志文件，但并不擅長分析實時的事件流。它們能夠用于分析發(fā)現(xiàn)的流程模型，但不能用于監(jiān)控或報告用例。而且它們通常使用DPG（Direct Follower Graph），而不是BPMN,這就很難向所有干系人展示這些內(nèi)容。

11.5 設(shè)置流程報告和監(jiān)控

11.5.1 常見的指標(biāo)和報告

最重要的指標(biāo)反而最簡單。其中一些是基于流程持續(xù)時間的，包括：

• 周期時間，指的是整個流程(包括工作流引擎中運行的流程以及端到端流程)的持續(xù)時間。這是判斷流程性能的關(guān)鍵指標(biāo)。進一步分析趨勢和異常值是很有意義的，比如可以了解運行緩慢的流程實例背后的原因和影響。
• 流程指定部分或指定階段的持續(xù)時間。如果你想聚焦分析流程的某一小段，這個指標(biāo)就很有用。
• 單個任務(wù)的持續(xù)時間。比如，你可能希望驗證SLA，或者分析單個步驟優(yōu)化的可能性。

11.6 結(jié)論

第三部分 應(yīng)用流程自動化

第12章 引入流程自動化的過程

本章將回答以下問題：如何將流程自動化引入你的組織?如何成功完成第一個項目?

12.1 了解采用過程

12.1.1 那些你想避免的失敗

你可能從這個例子中觀察到許多：

• 不要過早地付諸戰(zhàn)略行動，先從小項目開始。
• 避免自上而下的大改造，創(chuàng)造允許自下面上發(fā)展的環(huán)境，最住平衡方案是，創(chuàng)造一個讓一線員工的提議可以被收能起來的環(huán)境，然后接納最含理的方案來討論，進而推動改造。擴大使用范圍的舉措始終應(yīng)該放在第二步。
• 抵擋創(chuàng)建自己平臺的誘感。
• 第一步先選擇合適的流程進行自動化。最重要的核心流程可能太龐大、有風(fēng)險、太過復(fù)雜，不適合作為第一步嘗試。
• 不要同時啟動太多項目。
• 專注于交付業(yè)務(wù)價值。流程解決方案需要解決真正的業(yè)務(wù)痛點。
• 不要從流程架構(gòu)或流程景觀開始。不要期望提前為流程自動化項目導(dǎo)出現(xiàn)成的流程模型。當(dāng)你知道流程自動化的真正運作方式時，將能更好地描繪流程架構(gòu)。
• 讓學(xué)習(xí)帶給自己視野，這包括接受一種公開討論失敗的文化， 因為你可以從中學(xué)習(xí)到很多。廠商或咨詢公司的最佳實踐(或書籍)可以作為一個很好的起點，但不能取代你自己的探索。
• 給子項目團隊自由度，讓他們可以自己做一些決定。

12.1.2 成功案例

這個故事的主要收獲是：

• 一步一步來，直到你準(zhǔn)備好大規(guī)模使用。
• 獲得決策者的認(rèn)可，這需要你的流程解決方案能解決真正的業(yè)務(wù)痛點，
• 確保讓有經(jīng)驗的人有機會在后續(xù)的項目中提供幫助。
• 獲取最佳實踐，確保知識共享。
• 如果可復(fù)用的組件能提高生產(chǎn)力，就提供這些組件，但要作為庫讓團隊自行采用。
• 建立內(nèi)部咨詢方法，也許可以組織成一個專家中心(COE)。 至少要在企業(yè)中確定并培養(yǎng)一名能夠推動該主題的專家。
• 為新人或團隊確定學(xué)習(xí)路徑。

12.1.2 成功采用過程的模式

評估工具棧時，你需要建立概念驗證項目。該項目的目標(biāo)是定義井驗證架構(gòu)和工具棧，具體的代碼往往會被丟棄。
任概念驗證之后，馬上開始一個試點項目。你應(yīng)該選擇一個合適的場景， 在這個場景中至少可以展示流程自動化的一些好處(例如， 提高效率、有效性、合規(guī)性)， 因為許多人(包括決策者)都對可量化的結(jié)果感興趣。
在成功運行試點項目后，啟動一個燈塔項目。
理想情況下，進行試點的團隊也在燈塔項目中工作，因為這樣可以充分利用他們所有的學(xué)習(xí)成果。這一點很重要，因為燈塔可能會成為后續(xù)項目的模板。也因此在燈塔項目完成上線后，你還應(yīng)該規(guī)劃一些時間來進行回顧。 請記住，投入些時間在修正上，遠(yuǎn)好于押注在第一版能做到完美。
只有這樣，你才應(yīng)該進入下一個階段，即在整個企業(yè)中大規(guī)模使用流程自動化。你應(yīng)該逐步推進這個階段。在從少數(shù)項目中收集足夠的經(jīng)驗之前，請確保不要走得太遠(yuǎn)。理想情況下，這種規(guī)模化是以“被動”的方式進行的，換句話說，是項目團隊聽說了流程自動化的優(yōu)勢，并決定要在他們的項目中采用它。

12.2 開始引入流程自動化

12.2.1 自下而上地引入與自上而下地引入

引人可以自下而上。這種情況經(jīng)常發(fā)生在開源組件上。開發(fā)者可能在某個地方了解到一個工具，然后試著使用。
在這種情況下，公司基本上是在工具已經(jīng)穩(wěn)定下來的階段開始采購流程，此時評估已經(jīng)沒有多大意義了。這未必是一件壞事，因為該工具已經(jīng)證明了它的價值。

自上而下的引人方式與此形成鮮明對比，在這個過程中，工具一般是由高層決定并交給開發(fā)團隊的。在極端情況下，企業(yè)要求每個項目都必須使用統(tǒng)的流程自動化工具棧。

12.3 從項目到工程：擴大使用規(guī)模

12.3.3 管理架構(gòu)決策

當(dāng)然，任由每個團隊選擇自己喜歡的東西是有風(fēng)險的，因為這些決定可能會被趨勢、炒作、個人喜好所左右，或者僅僅是人們要嘗試某個“早就想試試”的技術(shù)。
這就是所謂的“誰構(gòu)建，誰運維”(you build it, you run it)。這一重 要的基本原理會使團隊識到他們將為自己的決定負(fù)責(zé)，從而做出 更明智的決定。

12.3.5 角色和技能培訓(xùn)

• 明星開發(fā)者。他們積極進取，充滿熱情。你只需要給他們工作流引擎和入門指南，然后離開。他們大概會自己從網(wǎng)上搜索。這些人可能最適合早期項目，也許還可以成為COE的人選。他們面臨的挑戰(zhàn)是，總想用最新、最好的技術(shù)，有時往往會過度設(shè)計。他們并不總是善于指導(dǎo)別人。要注意，這樣的人很容易分心。
• 專業(yè)開發(fā)者。這些開發(fā)人員是訓(xùn)練有素的軟件工程師。建議讓工具的提供商進行一次培訓(xùn)，或許還要再加上一段時間的咨詢服務(wù)，以便他們遇到任何問題時可以獲得答復(fù)。這些人通常是很好的講師，可以成為COE的一部分。

12.4 結(jié)論
第13章 臨別贈言
13.1 當(dāng)下架構(gòu)趨勢對流程自動化的影響
13.2 重新思考業(yè)務(wù)流程和用戶體驗
13.3 何去何從
關(guān)于作者
關(guān)于封面
推薦閱讀
封底