BPMS還是純粹的編程？

當談到實施業務流程時，您更喜歡什麼（從您的開發人員的角度）？BPMS還是純粹的編程？

一個業務流程管理系統（BPMS）或只是你最喜歡的IDE與所需的工具和框架（例如報告工具）？

從你的角度來看，與使用個人工具和框架的IDE相比，BPMS最大的好處是什麼？

好的。也許我應該更具體一些......我知道一個特定的BPMS，它可以通過配置規則來實現業務流程。但作爲一名開發人員，我很難與系統一起工作。我想與我可以重構的文本文件一起工作，我希望能夠爲我必須做的工作選擇正確的技術或框架。相反，系統迫使我進行配置。

有規則，我可以使用Java，但即使如此，我必須堅持系統編輯器而不智能感知等

因此，這使我對我自己的問題的答案 - 我想用我習慣於使用工具，而不必學習如何使用BPMS（至少我知道），因爲它限制了我不僅僅是幫助。我所知道的BPMS是一個難以逃脫的框架！目前，我更喜歡像Grail這樣的框架，而不是我知道的任何BPMS。

所以也許更具體的問題是：你是否感覺相同，還是有BPMSes支持你在開發者身邊，像開發人員一樣思考，或者他們中的大多數人迫使你以不同的方式做你的工作？

來源

2009-12-22 rdmueller

另請參閱http://stackoverflow.com/questions/214122/is-bpm-in-your-mind – rdmueller 2009-12-22 19:16:25

不知道你到底在問什麼，但選擇BPM與純編程將取決於需求。「業務流程」在軟件工程中是一個相對模糊的術語。

這裏有幾個標準來評估你的需求：

規則複雜性 - 體現在你的進程的決定/規則簡單，複雜的，可配置的，硬編碼？
流程的波動性 - 您的流程多久改變一次？誰應該能夠做出改變？
集成需求 - 您的流程是使用多種異構服務實現的，還是全部使用相同的語言實現？
同步/異步 - 您的進程是否需要處理異步操作「長時間運行」？
人類任務 - 您的過程是否涉及人際交互，並根據任務的職責將任務分配/路由給人員？
監控流程 - 您希望在現有流程實例上執行的控制級別是多少？你需要審覈行動等嗎？
錯誤處理 - 根據以前的觀點，您打算如何處理錯誤或重試錯誤的流程執行？

根據這些問題的答案，你可能會發現你的進程更接近simple state圖表與可以在順序執行一些動作和決定，否則你可能會意識到你需要的東西更精細，而且你不想重新實現所有這一切。

之間平原編程和功能完善的BPM溶液（例如Oracle BPM suite含有BPEL，rule engine等），有中間解如jBPM或Windows Workflow Foundation和可能很多其他人。這些中間解決方案通常是很好的折衷。

來源

2009-12-22 15:41:35 ewernli

BPMS--很多常見的商業案例，用例都已經實現。所以你只需要知道如何使用它。對於常見的工作流程，您甚至不需要編寫一行代碼，但大多數情況下，您必須編寫一些腳本來涵蓋尚未實現的內容。

平原編程 - 只需使用IDE來破解代碼即可。積極的一面：更多的控制。負面？花了很多時間重寫樣板代碼。你必須維護它們。

所以簡而言之，我更喜歡業務流程管理系統。我建議的一個是ProcessMaker。它具有一個直觀的流程設計器，允許您通過拖放來設計工作流程。並且您始終可以編寫trigger以擴展過程功能。它也是開源的。

來源

2009-12-22 15:25:53 Graviton

因此，您可以更好地開始使用BPMS，因爲您已經擁有系統並且不必關心登錄屏幕，會話處理等......但是如果你需要實現很多流程，這仍然有效嗎？我的意思是在第一個過程中，您已經實現了您可以在第二個過程中重複使用的樣板代碼... – rdmueller 2009-12-22 16:51:46

是的，有了BPMS，它的速度還是更快 – Graviton 2009-12-23 01:22:02

根據我的經驗，BPMS系統提供的開發環境是第三流的，沒有什麼效果，並且實際上迫使您難以維護，設計不佳的代碼（由於其侷限性）。幾乎所有我熟悉的BPMS系統（由該公司以其數據庫命名的BPMS系統）提供的「功能」（UI，集成等）都不值得我們支付的錢。

如果您不得不使用BPMS作爲開發人員，我的建議是在常規開發環境（如Java或.Net）中儘可能多地構建您的應用程序，並儘可能少地在BPMS環境中構建本身，並融合兩者。 BPMS中唯一應該做的事情是使業務流程起作用的最低限度。

來源

2011-08-04 04:12:41

這也是我的經驗。我所看到的唯一問題是工作流引擎和傳統開發之間沒有乾淨的界面。我想不可能，因爲（工作流程和應用程序）都試圖推動流程... – rdmueller 2011-08-04 06:46:09

我已經與Biztalk在過去和最近與JBPM合作過。我的意見是偏向對BPM的，原因如下：

陡峭的學習曲線：爲了使一個過程的工作，我必須瞭解系統和編輯工作。開發人員很難理解系統，更不用說業務用戶。拖放和可視化表示是一個很棒的演示工具。它確實給管理者留下了深刻的印象（誰最終爲此付出了代價），但開發人員的生產力卻下降了。
非開發人員改變工作流程：我還沒有看到一個BPM解決方案完美無缺。雖然它看起來不像代碼，但右鍵單擊該框並且必須放置一些代碼，否則它不會起作用。所以你絕對需要一個開發人員來做到這一點。最好的部分是，它既不是開發人員友好的，也不是業務用戶友好的，只是演示用戶友好。
可測試性和重構：測試驅動器BPMS幾乎是不可能的。你確實有'單元測試框架'的廣告，但其中大多數是黑客和難以使用。最近我嘗試了JBPM之一。最後，我寫了大量的膠水代碼和假工作流程處理程序來使其工作。對我而言，交易斷路器是重構。如果業務從根本上改變了業務流程應該如何看待的思想，那麼祝好運重新安排這些框，因爲重新安排它們將不起作用，所有綁定到框的變量也需要重新排列。我更喜歡IDE的強大功能和測試來重構我的業務流程。

如果您的應用程序有工作流程，那麼您可以嘗試一個工作流程庫（帶或不帶持久狀態）。它仍然可以管理您的工作流程，而不會出現BPM帶來的所有問題。如果業務用戶需要了解代碼，那麼讓業務人員準備好流程圖並將其轉化爲良好的域驅動代碼。使用黃瓜風格驗收測試將開發人員和業務組合在一起。一個BPM只是試圖做太多事情並最終做所有這些事情的結果。

來源

2012-12-08 18:45:33 uttamkini

BPMS還是純粹的編程？

回答

相關問題