A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.
A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.
Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.
For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:
If inspector believes vehicle is repairable then process as repair otherwise process as total loss.
The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.
Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).
The RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.
How such a unifed view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, the RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.
For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.
Motivates
The rule systems employed by the supply chain partners might have different capabilities. Thus, situations may occur where interchanged process rules cannot be (safely) executed. In such cases, a default to revert to manual processing, or rejection of the process definition, may be required.
Business logic implemented in Business Processes (eg in BPM environments) may be expected to be used in different semantic environments. An example of this would be simple interchangeable business logic that is executed in BPM environment #1 using an inference rule engine, and passed to a BPM environment #2 using an "script" (rule) engine (without inferencing). In this case if inferencing rules are detected in the supply chain process being interchanged, and the receiver only has scripted engine support, then the default behavior may be invoked.
Additional information may be required by supply chain partners if their default behavior is to NOT automate the rule execution, whereas the originator's rules were automated.
Metadata that is appropriate to the supply chain interchange of rules may include applicability of the ruleset(s) (aka preconditions), compliance regulations affected, cost per use, etc.
Implementation of supply chain policies and practices as business rules is considered "well established". Implementability of supply chain partner rules as (for example) production rules will support this motivation.
Minimizing the number of RIF dialects (aka rule semantics supported) will maximize the applicability and usability of rules in supply chain scenarios.
For those industries that utilize OWL (eg pharma, healthcare, academia), the representation of supply chain data in OWL and their subsequent references in supply chain intra-business rulesets will be required.
For those industries that utilize RDF (eg content management, academia), the representation of supply chain data in RDF and their subsequent references in supply chain intra-business rulesets will be required.
Much supply chain information (data) is transported as XML, which is replacing EDI. Therefore support for XML is critical for the supply chain use case.