上個星期，應我們某一上市鋼鐵公司客戶資訊部門協理的邀請，期能協同參與 Workflow 產品 的 Survey，主要是希望能應用在明年 ERP(利用 .NET 系統開發，但需要逐漸從 AS400 移轉)系統的電子簽核功能。

該位協理已經檢視過國內多套 Workflow 產品，但均不是太滿意，例如，光是要求 A牌以 Java-based 所開發的 Workflow 產品能提供個 Web Service 介面供呼叫，就不太能提的出來；或者，雖然與其 ERP 系統同是 .NET Famework 的 Workflow 產品，但卻與 Web UI(ASP or ASP.NET)以及資料庫系統綁得太緊，從 Workflow 廠商的角度，所提供的系統整合的解決方案，就是由 ERP 系統的資料庫，可能是透過 EAI(Enterprise Application Integration) 將資料給整合至 Workflow 系統的資料庫內，甚至，乾脆簡單一點，就是只要能 “匯入(Import)” 至 Workflow 的資料庫就好了。

所以，從 Workflow 廠商角度所提供的系統整合解決方案，均是以 Workflow 的角度來看待系統整合，然後以 Workflow 為核心，來整合其它的系統，包括 ERP、財會系統 …等。這也算合理，因為，最好就是用了該廠商的產品，然後就是一直 “依賴” 它，不要換掉，一同與之成長。 🙂

嗯，不過呢，協理的要求很清楚：要能實現電子簽核的功能，以及．．．未來要能換的掉 Workflow 產品，但卻不致影響到 ERP 系統的主架構。

從客戶的角度來看，還是不太希望能把公司最核心的命脈：ERP 系統，給緊緊的與某一廠商 Workflow 產品綁在一起，況且，頭大的還不止 Workflow 呢，還有要如何能從 AS400 逐漸的將業務邏輯給移轉至新開發的 ERP.NET 系統，又要不影響到 AS400 既有用戶的權益。當然，這就是明年初我們顧問團隊準備輔導該專案在架構設計的最重要議題，因而，更不可能在專案一開始的階段，就被某一個產品給牽著鼻子走。

如何檢視 Workflow 產品的 “好壞” 呢？ 我個人是很肯定國內外一流 Workflow 產品所提供的表單設計、Process Definition 視覺化設計、電子簽核功能的成熟度等。所以，關於功能與圖形操作介面的檢視，由客戶單位覺得 “對眼”，以及價位上可以接受就可以了；至於個人比較重視的，當然就是在系統整合的彈性度上，也就是說：在架構設計上，系統與系統的整合，絕對不是透過資料庫、而是透過 Middleware 層所提供的程式呼叫介面來達成。

我提了一個算是蠻簡單、來驗測 Workflow 產品在系統整合彈性度的 POC(Proof of Concept)。從三個構面，來檢視 Workflow 系統的整合度。

1. 表達並行簽核(會簽)功能的業務流程圖(利用 UML 活動圖表達)。
2. 表達資訊系統功能觀點的使用案例圖。
3. 表達物件(每一支的 .cs 程式碼)在系統動態期間訊息傳遞的循序圖。

圖1 表達的是一個簡單的業務流程圖，我是利用活動圖來表達的，一般 Workflow 廠商即使不懂 UML 也都還知道流程圖的表達。很簡單，就是先目視一下，Workflow 系統要能提供並行(parallel)簽核，或稱之為會簽的功能，以及，當然，要能對業務流程的簽核邏輯，如 “決策(decision)” 的條件判斷做流程的狀態轉移(transition)。同時，該業務流程圖也隱含了，至少有兩個資訊系統的支援：人力資源(HR,Human Resource)系統與Workflow 系統，以及有哪些角色(role)，或稱之為參與者(actor)，來使用資訊系統。 (從圖一，可以看得出有 “請假當事人”、”直屬主管”、”專案主管”、”人事部門” 等參與者)

（點擊圖片鏈接看原圖）圖1、一個簡單的請假業務流程圖

圖2 則是表達了以 HR 系統為開發範圍的使用案例圖(Use Case Diagram)。個人經常是用此來表達資訊系統的架構設計，簡單清晰又明瞭。從圖2 可以看得出 “誰” 來使用 HR 系統，包括了 “請假當事人”、”簽核主管”、”人事審核人員” 等主要參與者(Primary Actor)。這裡我用了 “一般化(generalization)” 的語法來表達 部門主管與專案主管都是簽核主管，另外，我用了 “公司員工” 這個參與者，卻沒有利用 “一般化” 語法來表達，而是利用註解(note)來說明，主要是為了簡潔圖形的表達。然後，Workflow 系統在該架構設計下，就屬於是 HR 系統的支援性參與者(supporting actor)，這也隱含了未來在系統的實做中，HR 系統是透過 “介面(interface)” 的呼叫來與 Workflow 系統整合。

（點擊圖片鏈接看原圖）圖2、一個請假系統的使用案例圖

圖3~圖5 則是實現(realize) 圖2 各個使用案例的循序圖(sequence diagram)。除了一個簡單的表單(form)畫面(請記得，是強調簡單，只要實做幾個欄位就可以了)外，在 Middleware 層，只設計了一個 “控制物件(control object)”，最起碼就已經隔閡掉表單與 Workflow 系統的直接溝通。另外，在圖4 “填寫請假資訊” 的案例實現上，就可以明顯看得出，實做的程式要能達成同時寫入兩個資料庫：HR 與 Workflow。若是同質(同是 .NET Framework)的系統，則可以以緊密的整合方式(tight-coupling)來達成同時寫入兩個資料庫的 “2-phase commit”；而若是異質(一為 .NET，另一為 J2EE)的系統，則可能採取的是透過 “web-service” 的寬鬆連結(loose-coupling)的整合方式，此時，就不太可能達成同時寫入兩個資料庫系統、而是必須採取如 “沖銷” 這樣的手段了。

（點擊圖片鏈接看原圖）圖3、實現請假系統—列出待辦事項的循序圖

（點擊圖片鏈接看原圖）圖4、實現請假系統—填寫請假資訊的循序圖

（點擊圖片鏈接看原圖）圖5、實現請假系統—簽核請假資訊的循序圖

驗證架構 POC 的程式誰來寫？ 這不會是 Workflow 廠商來寫的，可不要期待，一般廠商對於為什麼還要多透過一顆 控制物件 來傳遞表單資訊，還不一定能接受，更何況，等到更嚴謹一點，要透過好幾個物件的傳遞(例如，我一定會再設計一個 “workflow_adapter” 這樣的 boundary 物件)，才能連結到 Workflow 系統，更是無法認同的。

請記得，架構的 POC 是要由提出架構設計的那一方來主導實做的，其實說起來在這個案例上，就是需要由我們顧問團隊來實現的。不過，由於我們一向會輔導客戶單位資訊部門的 IT 人員來實做程式碼，這樣讓客戶單位能有直接參與的感覺，也比較實在。至於 Workflow 廠商的技術代表，可能是 pre-sell or 技術人員，只要在場提供諮詢，當要連結 workflow 系統時，該呼叫哪一個 APIs(Application Programming Interfaces)、以及所帶的參數與回傳值等資訊即可。

當然，一定是要依照循序圖內的規範給實做(implement)出來。過程需要多久才能實做完成呢？ 一般是半天就可以完成實做的，最晚應該不會超過 3 天。若是超過 3 天，就要檢討了，到底是負責實做的 IT 人員的實做能力、平台整合技術等問題，還是… workflow 無法提供出具體的呼叫介面… 簡單的回饋與結論就可以出來了。

※延伸參考：
o 「漫談系統整合—誰是老大？」
o 「淺論架構的 POC (Proof of Concepts)」

※P.S.
若想參考 UML Model(EA 6 格式)檔，可下載：WorkflowPOC.rar
另，若沒有 EA UML 工具，可以下載免費的 EA-Lite Viewer 觀看。