Initially, Ritc was built as a Rule Engine. It could be compared with IFTTT and Zapier, and relied in great part on the availability of REST APIs to be able to detect patterns and events and act on them. Pretty good stuff. Powerful. Still useful.
But then the realization came that this was not enough, that a rule that, for example, populated a cell in your Google Docs spreadsheet from data captured somewhere else was only addressing part of a need.
The original Ritc vision, which still holds, is based on these axioms:
- Rules and flows can be equated with each other at some level
- Rules can implement “Use Cases”
- Rules are assembled from “building blocks” (“triggers” and “actions”)
- Rules/flows/use cases can be seen as pathways in a decision tree
- Decision trees and forests of decision trees can be equated with applications
So in Ritc, you can consider a group of rules to be an application (called “app”), where each rule handles a specific use case. Together, the group handles all the possible use cases that define the application. Voila! A new way to build applications!
On top of that, Ritc rules are “declarative”. And with the right building blocks, a rule can be “read” just as a requirement can be read. So, in essence, you can create a rule by capturing a requirement. This is related to the BDD message, and that’s where Ritc 2.0 comes in.
What are these building blocks?
- Building blocks can be a number of things:
- Defined and accessible web services – available as REST APIs
- Built-in functions, arranged in libraries
- Machine learning (ML) algorithms
- Legacy systems, available via Robot Process Automation (RPA)
- and others…
Ritc 2.0 enables you to build rules, and therefore applications, just by providing requirements, using available building blocks.
Now there’s a lot of detail that goes behind this vision, but this is the essence of it.
For more information, please contact us.