Continuing from my previous post, I'll describe the rest of the components of a BPM Suite, namely:
• Business Rules
• Application Integration
• Performance Management
Business rules
Business rules must be distinguished from routing rules. Routing rules are characterized by:
• Simple conditions at a point in a flow
• Usually defined in the modeling environment
• Changes to rules required versioning, possibly requiring an update of the process in the engine
On the other hand, business rules are characterized by:
• Complex conditions that can be invoked by a wide variety of triggers
• Usually defined in business rules engine (BRE) by business users
• Changes in rules do not require the republishing of the process
Application Integration
In its 2007 report on BPMS, BPTrends.com identified 3 types of integration approaches:
• Brittle Spaghetti
• Adapters
• Introspection
In the Brittle Spaghetti approach, the developer has the responsibility of writing suitable integration code. This is facilitated by sophisticated APIs that allow developers to pass the right information as parameters to third party application. The problem with this approach is that integration code tends to be scattered around through the processes. As the systems changes, the code to do this integration becomes a management nightmare.
With the Adapters approach, vendors provide a standard interface with which the processes communicate with the backend systems. However, they may have some limitations, particularly when your backend system goes through an upgrade.
With the Introspection approach, the integration is generally built around a set of generic technology adapters. The tool introspect the 3rd party applications to create a set of reusable components which can then be used in the process models. A developer uses the introspecting capabilities of the tool to explore the methods and attributes of a remote backend system either via API or Web Services. When you consider that integration costs represent 50% of a process enabled project (cited by the BPTrends report), the advantage with this approach is fairly obvious. If your backend changes, you can just re-introspect the component and make the necessary (and hopefully smaller) changes rather than wait for an updated adaptor or recode. Incidentally, Oracle BPM uses the introspection approach.
Performance Management
Performance management allows you to monitor the processes and how they are performing against your KPIs. Generally, this takes the form of pretty graphs and dashboards displaying performance measures in real-time, near real-time or showing historical trends. These performance data can then be used by line-of-business owners to seek further improvement on their process.
I hope you have enjoyed reading this. In my next post, I'll describe the different features and functionality of Oracle BPM and how they relate to the different components described here.
Cheers,
Ali
