說起工作流，本人一般遇到兩種場景：一種是某些人對工作流的嚮往之情非常強烈，他們的說法一般是“這個問題就應該用工作流來解決”，而他們卻未必對工作流有詳細的瞭解，只是對這種技術有道聽途說式的理解；另一種是對工作流的強烈反對，認爲工作流根本就不好用，即使用了也是“假”的，業務系統該怎麼樣還是怎麼樣，用了工作流也就是對客戶宣傳的噱頭而已。
本人先後試用了3種java開源的工作流產品，無一例外都要在業務系統中加入一些工作流的代碼，這就造成工作流產品與業務系統的緊密耦合。在鬆耦合是開發系統目標之一的情況下，工作流產品與業務系統的緊密耦合顯得有點背道而馳。而發生這種問題的原因是工作流引擎與業務系統確實存在通信的必要，例如報銷數量超過5000元的報銷單需要老闆審批，工作流引擎如果無法從業務系統得到報銷金額能正常工作嗎？再比如客戶下了一個訂單，訂單以工作流的形式在各個部門中執行，客戶在查詢訂單狀態的時候需要從工作流引擎中獲得最新的狀態。而工作流產品與業務系統的這些交互，很多是需要通過代碼來實現的，在業務系統中寫一些無關的工作流代碼，感覺確實不是太好。
工作流已經存在了很長時間了，最早的使用甚至可以追溯到上個世紀60年代，經過這麼多年的發展，出現了很多工作流產品，這幾年隨着SOA架構的應用，又出現了工作流（Workflow）的升級版本業務流程管理（BPM，Business Process Management）。一種技術發展了30年了，也應該非常成熟了，可是實際應用中還是不甚理想，甚至還有很多業務系統沒有使用工作流產品，出現這樣的情況我們不能不對工作流系統進行反思。總體來說，工作流系統存在以下問題：
- 工作流產品與業務系統的緊密耦合。
- 數據量大時工作流引擎可能會出現的性能問題。
- 工作流產品適應不同業務環境以及隨業務環境變換進行微調的能力不足。
當然以上也只是一個大致的總結，不同的工作流產品有不同的特點，例如對於實現會籤這樣的流程，有的工作流很容易做，有的則要費勁一些。
也許我們應該換個角度看問題，而不是要求工作流產品盡善盡美。我們提供的最終系統是以業務系統的形式出現的，而不是工作流如何，充分利用他們的優點，使用戶在使用業務系統的時候更加方便纔是最終的目標。對於界面展現，我們可以用業務系統來實現，而不是工作流提供的界面；對於任務的流轉、分配，可以充分利用工作流的特性；對於業務系統與工作流的信息交互，完全可以看成是一個統一的系統，而不用劃分彼此。
只要實現了多人協作完成同一個任務的系統都可以叫做工作流應用系統，而不是非要使用工作流產品。儘管WfMC制定了工作流的相關規範，只有遵從規範的才叫做工作流嗎？沒有遵從規範的也存在不少優秀的工作流產品。
沒有采用工作流的業務系統未必不優秀，而使用了工作流的系統也可能很爛，評判標準掌握在用戶手裏，由市場來決定，而不是所採用的技術。