用BPM策略對應用進行現代化的可行性如何?Tom Nolle用批判的眼光進行了審視，并且對如何有效使用它提供了一個分步驟的解釋。

一些人提議把業務流程管理作為應用現代化的手段之一，但也有人對此提出質疑，但采用BPM策略可以成為現代化遺留應用的明智方式。Tom Nolle對此進行了解釋。 對遺留應用進行現代化的一個最大問題是“現代化”并不意味著進行任何特殊的技術或功能改變。

這些都應該是任何應用設計和開發項目的一部分。

下面我們來探索一下業務流程管理如何能夠幫助提供一個現代化的框架。

促進有效的BPM策略

正確的BPM使用從仔細識別真正的業務流程開始，而不是它們目前的實現；要把業務流程和應用工具看作是交互元素；對策略的流程和應用維度的重視程度應當與對實現的重視程度相當甚至更高。

BPM被用來打破結合了若干業務目標的特定活動。在許多情況下，也許是BPM策略實施最佳的情況下，它可能是作為企業架構的一個元素而存在的。在應用設計和開發方面，BPM是需求的來源。

應用現代化是重構應用的過程，其目標是吸收被證明能夠提供最好敏捷性和效率的設計原則和技術。它主要考察的是支持業務流程的實現，大多數情況下，會把應用實現當作功能基礎。

明智的BPM驅動應用現代化解決辦法認識到。工具與流程之間存在根本性的依賴。員工利用手頭的東西做自己能做的事，所以應用和數據的可用性往往框定了他們做事的方式。這種相互依賴給應用現代化制造了極大的風險，因為太容易就會把過去基于工具的限制帶給將來的應用了。這意味著你必須從當前的應用細節退后一步重新捕捉真正的業務流程。

這時候，企業架構也許提供了一條容易的途徑，如果存在一個“EA模型”的話（幾乎一直都是這樣）?？梢哉f，對于一家大企業來說，永遠都不要在沒有根據已有的標準（如TOGAF）制定一項EA模型之前，就進行大規模的遺留應用現代化。而在應用現代化項目的范圍存在更多限制的情況下，是有可能從當前的應用中恢復業務流程定義的。如果你沒有EA框架來引導BPM映射，可以利用應用工作流，通過把應用功能組織進支持的業務流程來對它們“抽象”化。

如果你有一個合適的BPM框架，現代化遺留應用的第一步是評估該框架的工作流限制。這種做法的目標是確定應用最適合支持的工作模型。下面一些模型可供參考：

1、簡單事務流：業務流程靠事務驅動，當一個流程被發起時，它是按照既定的路徑走到結束的。大多數遺留應用都是這樣工作的，無論業務有沒有執行。

2、流化計算模型：業務流程受到活動流的驅動，這些活動流可能牽涉到多個事件和來源，流程需要在這些流當中得到交互式的支持。

3、事務+分析：業務流程基本上屬于事務性，但大數據采集和分析驅動了一批流程。

這些模型每一個都有一個合適的應用結構，后者隨后可以推動中間件工具以及應用程序接口（API）的選擇。事務型應用，尤其是簡單的事務型應用，可以很容易地跟SOA應用模型連接起來，而SOA也可以用在事務+分析模型的主事務流上。流計算模型應該基于復雜事件處理以及流（Stream/flow）式API，尤其是微服務。CEP可能對事務+分析模型也有用，因為分析有實時的需要。

這種模型會疊加到你原來的BPM流程圖上，表明了應用是如何與流程自然建立起來的工作流關聯起來的。流程既是模型定義的事務或流的來源，也是活動如何排序的引導力。把握住這種映射來確保你不會在建構應用時打破BPM工作流。

BPM驅動應用現代化項目的下一步是映射當前和未來應用組件到你選擇的模型里面。如果應用組件適合總體圖定義的流，那這種組件就適合用來提供相適應的接口。不過要注意所需的API和信息模型；這些合起來可以形成中間件選擇的需求。

這時候就要考慮業務流程和應用工具的交互性問題。貫穿你模型的臨時性工作流在邏輯上未必與應用組件相適應，或者這個時候你希望使用的流里面合適的組件未必具備所需的信息。如果是這種情況，那可以考慮對流進行試驗性的重映射，改變組件次序，然后收集所需的信息。你在做的是改變假定的業務流程來優化特定的應用用法，所以根據過去經驗從最有價值的組件開始是明智之選。

當所有應用和組件已經映射進模型之后，你就可以策劃應用現代化并實施策略了。重要的是要保持功能（BPM）與結構（技術）的分離，所以新的組合應用圖和工作流應該在你一開始做好的BPM流程圖之上構建。記住，你可能會對這張圖進行少量改動以適應某些應用組件所需的特定信息。

誠然，對于遺留應用現代化來說，作為一種技術演進似乎并不天然從屬于業務流程管理，者也是為什么很多人看不到存在關聯的原因。但是如果沒有BPM策略，你是沒有辦法做好包括流計算在內的應用模型改變的，這些可是下一代應用架構的基礎。不要對BPM做出技術選擇，而是要讓BPM來確定需求，這樣你才能取得勝利。