James Taylor’s blog today on rules being core to BPM and SOA in which he discussed reuse had a particularly strong impact on me following a trip yesterday. During a meeting with the insurance and retail banking practice leaders at a large consulting firm, we looked for synnergies between applications related to investment and applications related to risk. Of course, during that conversation, we discussed whether operational rules could be usefully shared across these currently siloed areas, but we landed up discussing what they had in common in terms of business concepts, definitions, and fundamental truths or enterprise wide governance. It was clear to us that this was the most fruitful area to develop core, reusable knowledge assets.
In his post, James agrees with the Butler Group’s statement:
Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
I have several problems with this statement:
- I don’t think it’s the most important aspect.
- I don’t think the possibility of re-use is being realized.
- I think current tools’ facilitation of re-use is limited.
The most important aspect of a repository is the reuse of knowledge, not just rules. The types of knowledge that are most easily reused are:
- the vocabulary (e.g., nouns, verbs and adjectives) and what they mean in the domain
- the taxonomy of concepts and how they are refered to using (primarily) nouns and adjectives
- the ontology of concepts, which is the taxonomy plus relationships between concepts, and how they are referenced using nouns, verbs and adjectives
- the definitions of derived concepts in terms of formulas or equations or constraints that define the truth without respect to process, state, or event
- the rules that specify behavior, regulation, governance, or policy
And their re-use decreases in the same order. Industry specific standards, like ACORD or MISMO of FIX or XBRL, for example, stop at 2 or 3. Logical formalism address 4 but are used more rarely than business rules. The SBVR standard, although it stands for the semantics of business vocabulary and rules, actually stops at 4. It’s rules are logical definitions and constraints, not business rules that take action, resulting in state transitions, data modifications, or other side-effects.
The use of SBVR or simply ontology is quite limited in today’s BRMS/BPM markets. There is simply too little emphasis on separating semantic models and business vocabularies using logic and ontology. Most BRMS/BPM platforms are fixated on behavior and process, rather than truth and knowledge.
Sure, clever enterprise architects and systems analyts can engineer rules so that they are useful in more than one application, but this is not the typical result of a business rules application. I do agree that encapsulating decisions within services is a more viable way of realizing re-use, but that is an architectural result (i.e., an SOA benefit), not a benefit of a rules repository.
I have blogged repeatedly (see the requirements category, for example) about the limitations of current tools with regard to vocabulary, separating ontology from implementation, and managing definitions and functional requirements in the natural form. Current BRMS tools are generally limited to an if-then mentality that makes them inadequate for managing knowledge. If-then metaphors force knowledge to be expressed and organized relative to how it is used. This fundamentally and inherently limits its reusability.
Just to drive this home, if you are technically inclined, take a look at the standard developed by the vendors, PRR. It will become immediately apparent that their focus is on rules at the operational rather than the knowledge level. RIF, on the other hand, evolved from the logic community to address the requirements of the semantic web. In this regard it is much more like SBVR. It makes up for its vocabularly weaknesses with much more ontological and logical strength. Nonetheless, RIF, like SBVR, is more at level 4 than level 5.
Another way of looking at this is that the models more than the rules are interchangeable. This misses that logical rules are very reusable, but it is in accordance with the 80/20 rule. In BPM, for example, the model is shared across processes. With decision management, the model should also be shared across decisions. The easiest rules to share across decisions are those that are true, not those that determine what to do.
Practically speaking, put rules that determine what to do in a services that share what is true.
Paul
As always you make interesting points and I think our differences are small overall. My focus is on decisions as the primary point of reuse precisely because rule or ruleset reuse, like code reuse, is hard. However the complexity of standards like SBVR and the difficulty of mapping them to actual operational systems should not be underestimated.
Reuse can occur at many levels and is valuable to different people at each of those levels. When companies cannot agree between divisions what a customer is, the idea that they can start by reusing a vocabulary may be a stretch. A ruthlessly practical focus on how systems can reuse things is one way to progress in the meantime.
JT
Author of Smart (enough) Systems
More agreement. SBVR is not the solution but is good in that it addresses vocabulary, model, and logic (more than rules). Different meanings of customer can be problematic but less than people believe if the vocabulary references a semantic model that is distinct from implementation concerns. It turns out that the meaning of words like “customer” is usually disambiguated by its use within sentences. One customer may be used with one verb relating it to a second concept but a second kind of customer would use a different verb to relate it to a third concept. (These verbs label relations in the underlying ontology, BTW). It is rare for two distinct concepts to use the same verb to relate themselves to the same kind of concept by different relations.
Ruthlessly practical. I like that. This ruthlessness is an onus on the customer side but an opportunity for vendors.
Completely agree. It is impossible to share (interchange) rules without sharing (mapping?) domain ontology first. Still my concern is that underlying ontology is too complex or too large (look at Cyc or even at ACORD). The size of the ontology presents not only the computational but also the semantic challenge as well. Authority’s approach of building ontology from the linguistic rule presentation provides a good example of ad-hoc ontology building, I consider it to be the best “practical” tool for the purpose; still the issues of compatibility, consistency and ontology mapping were not (to the best of my knowledge, which could be somewhat limited and outdated) addressed properly, which could be attributed to resource limitations. This all brings to the fore the question of having all the major vendors to support w3c RDF/OWL ontology format + RIF and therefore “outsource” the ontology compatibility issue to more general community
Although rule interchange may be possible without a common semantics (i.e., syntactically), there is no future in it. Your ontological concern is reasonable and shared. However, Cyc and a rigorous ontology covering ACORD are tremendous assets. Your point about compatibility, consistency and mapping is a good one, although not specific to any vendor’s product.
There is no known, robust and reliable means of reconciling less rigorous ontologies (e.g., folksonomies). Until this theoretical problem is solved, reusing upper or standard ontologies is the way to go, no matter how large they need to be.
I think compatibility is less of an issue than mapping and that the need for consistency is greatly exaggerated. We need approaches to knowledge management and automation that are much more robust in the face of inconsistency. The onus and limitations of enforced consistency are simply too much in practice and in theory.
OWL and RIF are a great technical foundation. SBVR is right to emphasize vocabulary in addition to a lesser emphasis on OWL RIF functionality.
A BRMS that unifies SBVR OWL RIF, perhaps with deployment across CLIPS/JESS/Drools and PRR would be pretty handy.