用BPM策略对应用进行现代化的可行性如何?Tom Nolle用批判的眼光进行了审视，并且对如何有效使用它提供了一个分步骤的解释。
一些人提议把业务流程管理作为应用现代化的手段之一，但也有人对此提出质疑，但采用BPM策略可以成为现代化遗留应用的明智方式。Tom Nolle对此进行了解释。 对遗留应用进行现代化的一个最大问题是“现代化”并不意味着进行任何特殊的技术或功能改变。
这些都应该是任何应用设计和开发项目的一部分。
下面我们来探索一下业务流程管理如何能够帮助提供一个现代化的框架。
促进有效的BPM策略
正确的BPM使用从仔细识别真正的业务流程开始，而不是它们目前的实现；要把业务流程和应用工具看作是交互元素；对策略的流程和应用维度的重视程度应当与对实现的重视程度相当甚至更高。
BPM被用来打破结合了若干业务目标的特定活动。在许多情况下，也许是BPM策略实施最佳的情况下，它可能是作为企业架构的一个元素而存在的。在应用设计和开发方面，BPM是需求的来源。
BPM驱动现代化的关键应用现代化是重构应用的过程，其目标是吸收被证明能够提供最好敏捷性和效率的设计原则和技术。它主要考察的是支持业务流程的实现，大多数情况下，会把应用实现当作功能基础。
明智的BPM驱动应用现代化解决办法认识到。工具与流程之间存在根本性的依赖。员工利用手头的东西做自己能做的事，所以应用和数据的可用性往往框定了他们做事的方式。这种相互依赖给应用现代化制造了极大的风险，因为太容易就会把过去基于工具的限制带给将来的应用了。这意味着你必须从当前的应用细节退后一步重新捕捉真正的业务流程。
这时候，企业架构也许提供了一条容易的途径，如果存在一个“EA模型”的话（几乎一直都是这样）。可以说，对于一家大企业来说，永远都不要在没有根据已有的标准（如TOGAF）制定一项EA模型之前，就进行大规模的遗留应用现代化。而在应用现代化项目的范围存在更多限制的情况下，是有可能从当前的应用中恢复业务流程定义的。如果你没有EA框架来引导BPM映射，可以利用应用工作流，通过把应用功能组织进支持的业务流程来对它们“抽象”化。
确定“工作模型”如果你有一个合适的BPM框架，现代化遗留应用的第一步是评估该框架的工作流限制。这种做法的目标是确定应用最适合支持的工作模型。下面一些模型可供参考：
1、简单事务流：业务流程靠事务驱动，当一个流程被发起时，它是按照既定的路径走到结束的。大多数遗留应用都是这样工作的，无论业务有没有执行。
2、流化计算模型：业务流程受到活动流的驱动，这些活动流可能牵涉到多个事件和来源，流程需要在这些流当中得到交互式的支持。
3、事务+分析：业务流程基本上属于事务性，但大数据采集和分析驱动了一批流程。
这些模型每一个都有一个合适的应用结构，后者随后可以推动中间件工具以及应用程序接口（API）的选择。事务型应用，尤其是简单的事务型应用，可以很容易地跟SOA应用模型连接起来，而SOA也可以用在事务+分析模型的主事务流上。流计算模型应该基于复杂事件处理以及流（Stream/flow）式API，尤其是微服务。CEP可能对事务+分析模型也有用，因为分析有实时的需要。
这种模型会叠加到你原来的BPM流程图上，表明了应用是如何与流程自然建立起来的工作流关联起来的。流程既是模型定义的事务或流的来源，也是活动如何排序的引导力。把握住这种映射来确保你不会在建构应用时打破BPM工作流。
映射应用组件BPM驱动应用现代化项目的下一步是映射当前和未来应用组件到你选择的模型里面。如果应用组件适合总体图定义的流，那这种组件就适合用来提供相适应的接口。不过要注意所需的API和信息模型；这些合起来可以形成中间件选择的需求。
这时候就要考虑业务流程和应用工具的交互性问题。贯穿你模型的临时性工作流在逻辑上未必与应用组件相适应，或者这个时候你希望使用的流里面合适的组件未必具备所需的信息。如果是这种情况，那可以考虑对流进行试验性的重映射，改变组件次序，然后收集所需的信息。你在做的是改变假定的业务流程来优化特定的应用用法，所以根据过去经验从最有价值的组件开始是明智之选。
策划实施当所有应用和组件已经映射进模型之后，你就可以策划应用现代化并实施策略了。重要的是要保持功能（BPM）与结构（技术）的分离，所以新的组合应用图和工作流应该在你一开始做好的BPM流程图之上构建。记住，你可能会对这张图进行少量改动以适应某些应用组件所需的特定信息。
诚然，对于遗留应用现代化来说，作为一种技术演进似乎并不天然从属于业务流程管理，者也是为什么很多人看不到存在关联的原因。但是如果没有BPM策略，你是没有办法做好包括流计算在内的应用模型改变的，这些可是下一代应用架构的基础。不要对BPM做出技术选择，而是要让BPM来确定需求，这样你才能取得胜利。
本文转自d1net（转载）
