你怎么知道当你需要一个BPM解决方案？ [英] How do you know when you need a BPM solution?

问题描述

我的客户正在寻找一个业务流程管理（BPM）解决方案。他们需要的是简单的文档路由和审批制度。什么是实施BPM系统中的驱动程序？什么是其中开发人员应该建议实施BPM解决方案与工作流工具或定制开发的门槛？

My customer is looking for a Business Process Management (BPM) solution. What they need is simple document routing and an approval system. What are the drivers for implementing a BPM system? What is the threshold where a developer should suggest implementing a BPM solution vs. a workflow tool or custom development?

在不适合的jBPM？什么时候状态机内置了一个应用程序配合？应该存在什么问题，确定需要去与来jBPM的类似的解决方案？

When does jBPM fit? When does a state machine built into an app fit? What problems should exist that determine that you need to go with a solution similar to jBPM?

我要寻找的一些真实世界的例子，我们试图构建解决方案我们自己，而是结束了的AquaLogic / jBPM的/隆巴迪会因为 _ 的。请填写空白。

I am looking for some real world examples of "we tried to build the solution ourselves, but ended up going with AquaLogic/jBPM/Lombardi because of _". Please fill in the blank.

推荐答案

我写了一个工作流引擎，因为我的雇主想自己的IP，jBPM的蓝本。现在之所以使用这样的工具，而不是创建自己的有限状态机，是适应变化不改变的持久性和支持工作流程的边缘案件我会解释。

I wrote a workflow engine, because my employer wanted to own the IP, modeled after jBPM. Now the reason you use such a tool, instead of creating your own finite state machine, is accommodating changes without altering persistence and supporting edge cases of workflow processes as I'll explain.

您典型的，或者更好地称之为天真，有限状态机实现拥有一套紧密耦合的管理数据，并将其流经过程数据库表。有可能是保持过去的版本，并跟踪谁在此过程中采取了什么行动，以及一种方式。如果这过程中遇到问题的更改数据和流程结构。然后将这些紧密耦合表需要被改变以反映新的结构，并且可以不与旧向后兼容。

Your typical, or perhaps better to call it "naive", finite state machine implementation features a set of database tables tightly coupled to the data managed and the process it flows through. There might be a way to keep past versions and track who took what action during the process as well. Where this runs into problems changes to data and process structure. Then those tightly coupled tables need to be altered to reflect the new structure and may not be backwardly compatible with the old.

一个工作流引擎克服了两种方式应对这一挑战，通过序列化重新present的数据和流程，以及抽象的集成点，尤其是安全性。序列化方面装置的数据和进程可以通过系统一起移动。这使得相同类型的数据的情况下，通过添加新的状态例如按照完全不同的进程到进程可以在运行时改变了点。而这一切都不需要改变底层存储。

A workflow engine overcomes this challenge in two ways, by using serialization to represent the data and process, and abstracting integration points, in particular security. The serialization aspect means data and process can move together through the system. This allows data instances of the same type to follow completely different processes to the point the process can altered at runtime, by adding a new state for instance. And none of this requires changing the underlying storage.

积分点注射入的算法流程和领带，以验证库（谁必须采取行动，即用户）的手段。注入的算法可能包括一个国家是否完成决定，而认证店的例子是LDAP。

Integration points are means of injecting algorithms into the process and ties to authentication stores (i.e. users who must take action). Injected algorithms might include determinations of whether or not a state is completed, whereas authentication stores example is LDAP.

现在的代价是难以搜索。例如，由于数据被序列化，它通常是无法查询历史信息 - 除了检索记录，反序列化，并使用code分析。

Now the tradeoff is difficult search. For instance, because data is serialized, it's usually not possible to query historical information - other than retrieve the records, deserialize and analyze using code.

工作流工具的另一个方面是嵌入到它的设计，并且你可能会不考虑滚动自己，并会后悔当你需要它的功能体验。这两种情况下，来我的心是定时任务和并行执行路径。

The other aspect of a workflow tool is the experience embedded into its design and functionality that you will likely not consider rolling your own and may live to regret when you do need it. The two cases the come to my mind are timed tasks and parallel execution paths.

定时任务分配数据一个演员的责任在一段时间过后。例如，说preSS释放令，并报批，然后坐了一个星期没有审查。你可能希望你的系统做的是确定挥之不去的文档，并得出相应的各方关注。

Timed tasks are assigning an actor responsibility for data after a certain duration has passed. For instance, say a press release is writ and submitted for approval, and then sits for a week without review. What you probably want your system to do is identify that lingering document and draw attention of the appropriate parties.

并行执行的路径是在我的经验（内容管理系统）少见，但仍是经常出现不够的情况。它是给定数据片向下发送的审查或处理中的两个不同的路径，只有在某些稍后待重组的想法。这种类型的问题，需要具有有用合并算法和重新present数据同时繁殖的能力。编织成事后朴素的解决方案是非常麻烦比它看起来可能，特别是如果你想跟踪历史数据。

Parallel execution paths are uncommon in my experience (Content Management Systems), but are still a situation that arises often enough. It's the idea that a given piece of data is sent down two different paths of review or processing, only to be recombined at some later point. This type of problem requires having useful merging algorithms and the ability to represent the data multiply simultaneously. Weaving that into a homespun solution after the fact is much trickier than it may seem, especially if you want to keep track of historical data.

如果你的系统是不可能改变的，滚你自己可能是一个简单的解决方案，特别是如果变化可以打破旧的信息。但是，如果你怀疑你有一个需要这种类型的耐用性还是会遇到一些这些罕见的，但棘手的情况下，工作流工具提供了更大的灵活性和保险，你不会自己画成一个角落里的数据和业务流程更改。

If your system is not likely to change, rolling your own may be an easier solution, particularly if changes can break old information. But if you suspect you have a need for that type of durability or will experience some of these uncommon but thorny scenarios, a workflow tool provides a lot more flexibility and insurance that you won't paint yourself into a corner as the data and business processes change.

这篇关于你怎么知道当你需要一个BPM解决方案？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！