Distinguishing rule-driven decision automation using known data from decisions for gathering data.
Using countless approaches, just about every organization or government agency you encounter has historically—and is increasingly—invested in software that enables automation of business decisions with explicitly defined outcomes. This type of decision automation is functionally just a calculation—the outcome is known and can be determined through a known set of steps. The obvious example is a calculator performing a mathematical equation, but there’s a reason that there hasn’t been a major evolution in the calculator market in our lifetimes—humans have researched and shared mathematical techniques for five millennia. Successfully automating decisions that are contingent upon mathematical premises and use case-specific variables requires the expertise of the individuals experienced in that industry or field of study.
These decision outcomes are first documented as business rules by individuals with domain expertise, such as by a clinician defining a patient’s risk factors for a particular ailment, or a civil engineer defining degradation calculations for municipal infrastructure.
Well-defined business rules are unambiguous, brief and precise. From these, standardized data and logical models may be formulated, facilitating communication about the business rules between the individuals (designers, developers, technical writers etc.) building applications and workflows, and the individuals with the domain expertise, such as the clinician or engineer. The degree to which the latter persona can contribute to the formers’ implementation of business application logic is thus the key barometer of the utility of a business rule management system, and precisely the guiding philosophy of Progress Corticon’s historic and future roadmap.
A characteristic of model-driven software development practices is abstraction—abstraction from data points to data models, and of application logic as business rules. Beyond enabling better interpersonal collaboration, model driven development patterns start with the aspects of the logic which are agnostic to where software runs (devices/platforms/versions). For any given application, the business rules and the data upon which the business rules operate are generally homogenous regardless of the target device or platform. Building applications by first defining what the rules will be doing before defining how is a design pattern is called Declarative Programming—the act of programming in languages that conform to the mental model of the developer rather than the operational model of the machine.
The applicability of business rules management systems for building application logic through declarative programming is largely self-evident within the confines of an explicit, confined decision to be made: When Entity1.attribute has the value of “X,” assign the value of Entity2.attribute to be “Y.”
More practically, when Patient.penicillinAllergic = “True,” assign the value of Patient.therapyChoice to be “Levofloxacin.” A clinician can define the data model that will capture all potential values that each set of patient data might contain, and define actions based upon specified combinations of these values.
Because we’re modeling decisions to be made, not subjective determinations, all potential combinations of the input values for Patient.penicillinAllergic have a known output. All we’re asking from the application when using this logic is to produce that known, specific output—we don’t necessarily care the under-the-covers steps through which it produces that output. We’re likewise taking for granted that the input data (e.g., Patient.penicillinAllergic = “True”) is already available for use with the rules, ready to be passed to a decision service awaiting requests.
For scenarios where the input data for a decision is being entered into a form by an end user, the decisions-from-data paradigm can be extended to optimize dynamic data-collection logic presented to end users.
Interested in driving decisions related to dynamic form behavior? You can find a full tutorial with live examples at the Corticon.js Dynamic Forms GitHub page, accessible here.
Seth Meldon is a Pre-Sales Engineer with a primary product focus area of Progress Corticon Business Rules Engine. His work is focused on educating and demoing Corticon’s expansive functionalities, use cases, and architectural strategies to internal and external audiences. You can follow Seth on LinkedIn.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.Learn More
Subscribe to get all the news, info and tutorials you need to build better business apps and sites
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.