Rules and rule engines have been around for a long time. You may very well have worked with one before.
As popularized by IFTTT (If This Then That), a first interpretation may be that rules are something like the code a programmer could write in some software language.
IF variable x is greater than zero THEN assign value 25 to variable y
IF it is raining today THEN alert me to bring an umbrella
You may be thinking of these rules as executing logic. ie. processing data and acting on it, with the primary focus on process.
But this is not the interpretation that Ritc relies on.
A Ritc rule is expressed as “When this case then that outcome”. That is, Ritc rules are declarative, as opposed to procedural – ie. goals (nouns) vs processes (verbs). Conceptually, rules are at a higher level than the processing (code) that they employ. They align more naturally with how we think about the world, and especially how we think about change. ie. we first think about “what” before we think about “how”.
This is an important distinction, which allows us to more closely align Ritc rules with the real world (and real world applications). It falls in naturally with the definition of “use case” – a methodology used in system analysis to identify, clarify, and organize system requirements. So Ritc presents an natural “next step” to build an application where the requirements have been stated this way.
So hopefully, if you have not already done so, this will make it easier for you to build your first rule.
This is an initial post about this topic. Watch this space for some real world examples of how to create Ritc rules.