所謂工作流引擎是指workflow作爲應用系統的一部分，併爲之提供對各應用系統有決定作用的根據角色、分工和條件的不同決定信息傳遞路由、內容等級等核心解決方案。例如開發一個系統最關鍵的部分不是系統的界面，也不是和數據庫之間的信息交換，而是如何根據業務邏輯開發出符合實際需要的程序邏輯並確保其穩定性、易維護性（模塊化和結構化）和彈性（容易根據實際業務邏輯的變化作出程序上的變動，例如決策權的改變、組織結構的變動和由於業務方向的變化產生的全新業務邏輯等等）。 Workflow 引擎解決的就是這個問題：如果應用程序缺乏強大的邏輯層，勢必變得容易出錯（信息的路由錯誤、死循環等等）。
就好比一輛汽車，外表做得再漂亮，如果發動機有問題就只是一個擺設。應用系統的彈性就好比引擎轉速方面的性能，加速到100 公里需要1 個小時（業務流程發生變動需要進行半年的程序修改）還能叫好車嗎？引擎動不動就熄火（程序因爲邏輯的問題陷入死循環）的車還敢開嗎？
工作流解決方案與傳統管理軟件的關係傳統的管理軟件注重解決企業應用層現存的問題（例如提高企業的資源配置率或提高單一員工的生產效率）。例如：EXCEL 可以提高員工畫表格的效率、財務軟件可以規範財務人員的工作並提高帳目查詢的效率、CRM 可以規範客戶管理從而使客戶資源掌握在公司手中而不是被一部分業務人員把持並提高客戶響應時間、ERP 解決的是如何配置企業資源：使企業的人力資源、財力資源和物資資源能夠根據業務的需求實現最大化配置。 workflow 關注的是如何縮短流程閒置時間，從而提高企業的業務處理能力並使企業能夠關注於真正對企業有意義的增值業務上。從建立企業神經系統的角度也許更能理解兩者的區別。傳統軟件不能解決工作流的問題，例如ERP 關注的是企業的資源配置，但不可能解決資源傳輸過程中的損耗和降低傳輸（流程）的成本；同樣workflow也不能完全解決傳統管理軟件所能解決的問題，例如對生產管理的MRP 系統所能解決的生產過程控制通過workflow很難實現。但一個好的傳統軟件如果希望能自動化地在整個企業中應用起來，必須有一個強大的邏輯層，用以解決信息傳遞的邏輯判斷和自動流轉，這個時候就需要workflow的平臺。所以說： 1.workflow 和傳統管理軟件不是同一種軟件，不具可比性； 2.workflow 對於已經有傳統管理軟件的企業的作用非常明顯，可以籍此平臺整合企業的各種應用系統，使之成爲一個完整的企業級應用，也就是通常所說的EAI. 3. 具備workflow功能的管理軟件（workflow與傳統管理軟件的結合）對於傳統管理軟件有絕對的優勢；4.workflow可以根據企業的需要開發解決信息傳遞問題的流程以及幫助企業開發與現有應用系統的接口
工作流自動化並不複雜因爲下述幾個原因，工作流自動化業界有" 適合處理複雜業務流程" 的名聲。
1.常規工作流自動化軟件包及其部署相當昂貴。通常，伴隨產品的是長時期的諮詢關係。所以爲了非常簡單的業務流程購買和部署軟件是被不被採納的。這些軟件通常只被用於複雜、關鍵和控制成本相對較高而工作流自動化帶來的效益明顯的量產型工作流應用。因此經銷商和用戶都會不自覺地關注於將複雜的業務問題自動化。 2. 處於類似原因，工作流研究人士首先會關注解決了哪些複雜的業務流程問題。
而對於大多數案例而言，爲解決簡單工作流程問題部署自動化軟件的成本顯然是不經濟的。這裏遵循一條簡單的道理：走之前必須先會爬，跑之前必須先會走。 3. 最後一條原因，也是"IT 業的尷尬".總經理對IT部門經理工作衡量的標準就是：能夠解決複雜問題的能力。自然，IT經理就會不遺餘力地解決那些複雜的問題，他們的方案通常也就複雜而且昂貴。
所有這些目前都在改變。針對桌面電腦的應用方案快速發展以及工作流解決方案的發展使解決日常工作流程問題成爲可能。費用不再昂貴，部署更爲簡便。事實上，企業越來越意識到工作流的重要性，同時在部署複雜關鍵的流程自動化之前，願意從一些簡單的流程入手積累經驗。
工作流會成爲操作系統的一部分嗎？
有人認爲工作流會成爲操作系統平臺（例如WINDOWS 平臺）的一部分。我們的觀點是，基於下述幾個原因，在可預見的未來，工作流不會成爲操作系統的一部分： 1. 擴展表格、文字處理程序和數據庫存在了20多年，成了家喻戶曉的名詞。這些技術被廣泛理解和應用，也相應形成了各自的標準和相關術語。然而因爲很多原因，直到今天這些技術也沒有成爲操作系統的一部分。最重要的原因之一是用戶需要差異和選擇的自由。相比較而言，工作流自動化軟件是較新的技術，也更有差異性、不易被廣泛理解並且比這些技術更爲先進。因爲工作流程的差異性和複雜性，工作流自動化的用戶需要更多的選擇空間。
2.財務軟件包從電腦發明後就迅速普及了。這是實施、術語和規則被普遍接受的另一個領域。然而至今也沒有哪種操作系統吹噓集成了多少財務軟件的功能。而工作流自動化軟件比財務軟件更爲複雜和有差異性。 3. 操作系統提供商，例如微軟和Sun ，不會爲了使其系統具備工作流自動化的功能而大量改變他們現有的系統。他們有什麼必要爲工作流自動化軟件投入開發和支持的成本呢？ 4. 操作系統是爲常規條件設計並使之最優化。正因如此，目前操作系統的開發成本幾乎都要上億美元。業務流程十分複雜並充滿了例外情況，如在操作系統中內嵌工作流自動化程序會極大地增加開發成本和難度。因此，即便操作系統提供商決定做工作流軟件，也會是鉅額投入開發一套新的操作系統，而不是將工作流嵌入。
事實上，今天的很多優秀的工作流解決方案集成了短信息、頁面服務、目標管理、文件管理和其他一些操作系統才提供的服務。
工作流自動化的主要成分工作流自動化如今成了管理的一句時髦話。市面上也有很多號稱能激活工作流的自動化產品。只要他們的應用程序支持基本的E-mail功能，賣主就會隨意地把" 激活工作流" 作爲標籤貼在產品上。然而，這類產品和真正工作流自動化軟件之間的差別就如同寫字版和Word之間的差別。我們相信，應用程序只有具備了下列主要特徵，才能稱其爲工作流自動化解決方案：
能夠畫出工作流程圖，當然以圖形化界面設計的爲佳；能爲每個步驟設計電子表格；能將外部應用程序結合爲工作流自動化的一部分；能與電子表格及企業數據庫相連接；能設計基於複雜業務規則的條件型路由的工作流程圖，最好無須編程；能根據功能、用戶名稱或上下級關係按規則傳遞信息；能夠監控工作流執行狀況；能夠對工作流進行調節；能夠模擬並測試工作流的行爲；工作流的應用必須支持多用戶並具高度可靠性；工作流的應用必須支持內部網或英特網及跨多種平臺。
網友討論工作流應該是一箇中間件而不應該是一個完整的系統。工作流應該整合到其他系統中而不是單獨使用。
工作流要完成的核心功能有流程設計，流程執行，流程和線程的調度，任務的分派與通知，集成已有信息系統（很多人忘了）。
工作流應該提供對組織機構，用戶，權限管理，流程，任務的管理能力，但是對這些管理能力最基本實現方式是提供API ，而不是一個管理系統，即使把這些管理作爲一個管理系統來實現（A ），也主要是用於演示，因爲當工作流用於其它系統（B ），因爲B 需要一個統一的管理界面，所以通常不會直接使用A.而表單設計，報表之類根本就是外圍功能，是二次開發商的任務。
我基本贊同wangtaoyy 的說法，再補充一點。我覺得工作流與其說是中間件，還不如說是一個應用整合和集成的框架。類似在j2ee規範下各產商開發的應用服務器，工作流也應當是在wfmc標準下開發出來的" 容器" ，只要是滿足了標準的應用程序或組件都能夠在這個" 容器" 中按照預定的規則被調度和執行。我認爲理想情況下工作流系統不應該提供API 作二次開發，工作流的內部對基於工作流的應用程序應當是完全不透明的，工作流應當提供給開發者的是一個類似於J2EE那樣的標準，一套編程模型和接口模型。開發者在這個模型下去實現那些接口，開發出應用組件，再利用工作流提供的管理器進行" 註冊".總而言之，對開發者而言，工作流是黑箱，他需要做的事情是開發標準組件，在工作流提供的UI管理工具中配置業務流程，包括業務過程、資源、權限、時間、規則等等。
1. j2ee 應用服務器也是中間件的一種。
2. 工作流要做成j2ee哪樣的標準還是比較困難的， j2ee 重點在於提供開發全新系統的能力，所以可以制定比較好的容器- 組件標準，而工作流的重點是整合已經存在的系統，要在這些各式各樣的老系統上強加標準是不現實的。
3.工作流應該提供api ，因爲其他系統中的一些事件可能會啓動一個流程，或者觸發其他與流程相關的東西
工作流分爲兩種類型，一種是嵌入式的，另一種是非嵌入式的。這在WFMC的文檔中已經有所介紹，大家可以找找看一下。按照工作流管理聯盟的文檔，大家說的都沒有什麼錯誤，只是側重點不同。wangtaoyy 的觀點傾向於前者，而coffeewoo 的觀點傾向於後者。
我的看法並不是趨向於嵌入式工作流。我理解的工作流提供的api 並不是一般軟件包的API ，而是一種服務方式的API ，類似於操作系統中的系統調用。
我們在軟件中大量使用了操作系統提供的系統調用API ，但是操作系統並不是嵌入到我們軟件系統中的。我認爲工作流系統與操作系統有很強的可比性，只是工作流層次更高。比如流程設計相當於編程，模型相當於程序，流程實例相當於進程，流程分支相當於線程，操作系統要對進程和線程進行調度，工作流引擎要對流程實例和分支進行調度，操作系統和工作流系統都應該對內存進行管理避免耗盡系統內存，操作系統提供系統調用API 而工作流引擎提供工作流API.何其相似。
從功能的角度看：工作流系統的本職工作就是管理和控制業務流程，例如：流程實例的啓動、停止；環節實例的啓動、結束；任務的分配等等。從工作流系統的組成看：工作流系統應該包括流程引擎、流程定義工具、運行管理工具、api 系統。工作流系統應該該不包括表單定義、組織機構定義及其管理、權限管理、數據流管理等等。
工作流系統雖然不包括上述功能，但是工作流系統一定會和上述功能發生交互關係，所以好的工作流產品並不是一個包辦上述功能的產品，而是一個設計良好的能夠和上述功能交互的系統。從和其他系統的關係看待工作流：如果站在基礎業務平臺的角度，那麼，工作流系統、組織機構管理系統、表單自定義系統、權限管理系統、數據流管理系統、報表系統都是這個基礎業務平臺的服務。業務功能系統在運行的過程中會調用這些服務，這些服務之間本身也可能互相調用。例如：工作流服務和組織機構管理服務之間的關係就非常密切，儘管如此，如果認爲工作流系統一定包含組織機構管理系統應該是不正確的。在oa系統中，表單自定義好像比較重要，而且流程常常需要引用表單上的數據，但是表單自定義絕對不是工作流系統的組成部分。流程在運行的過程中可能跨多個數據庫系統，任務在流轉的過程中需要“攜帶”大量的業務數據，但是這些也不是工作流要做的事情，完成這些工作的系統我稱之爲“數據流管理系統”。總之：從功能的角度，所有的功能都是必要的，但是從技術的角度，這些功能不可以做到一個“鐵板一塊”的所謂的“工作流”裏面去。從技術發展的趨勢看：工作流系統很可能發展成爲一個類似關係型數據庫管理系統的專職的系統。我那個工作流東東還在改進中，希望作出一個設計合理的（決對不是強行coding出來的），工程實用的東西出來