您如何知道何时需要 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/Lombardi"的一些真实示例.请填空.

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.

工作流引擎通过两种方式克服了这一挑战，即使用序列化来表示数据和流程，以及抽象集成点，尤其是安全性.序列化方面意味着数据和流程可以在系统中一起移动.这允许相同类型的数据实例遵循完全不同的流程，直到流程可以在运行时更改，例如通过添加新状态.而这一切都不需要更改底层存储.

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.

现在权衡是困难的搜索.例如，因为数据是序列化的，所以通常不可能查询历史信息——除了检索记录、反序列化和使用代码分析.

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.

定时任务是在经过一定的持续时间后为数据分配一个参与者的责任.例如，假设新闻稿是书面的并提交批准，然后静置一周而不进行审查.您可能希望系统做的是识别该遗留文件并引起相关方的注意.

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.

在我的经验(内容管理系统)中，并行执行路径并不常见，但这种情况仍然经常出现.这种想法是将给定的数据发送到两条不同的审查或处理路径，然后再重新组合.这类问题需要有用的合并算法和同时表示数据乘法的能力.事后将其编织成一个简单的解决方案比看起来要复杂得多，尤其是如果您想跟踪历史数据.

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屋！