Today Yann LeGun tweeted: “Thought != Language” in response to this Einstein’s quote: “I rarely think in words at all. A thought comes, and I may try to express it in words afterwards.”
It reminded me Henri Poincaré whose book on how the inventor’s mind works I was lucky to read as a University student. I tried to google the topic and found this article: “Poincaréfound that he would often struggle unsuccessfully with some mathematical problem, perhaps over days or weeks (to be fair, the problems he got stuck on were difficult, to say the least). Then, while not actually working on the problem at all, a possible solution would pop into his mind. And when he later checked carefully, the solution would almost always turn out to be correct.“
How was this possible? Poincaré’s own suspicion was that his unconscious mind was churning through possible approaches to the problem “in the background”—and when an approach seemed aesthetically “right,” it might burst through into consciousness. Poincaré believed that this “unconscious thought” process was carried out by what might almost be a second self, prepared and energized by periods of conscious work, yet able to work away on the problem in hand entirely below the level of conscious awareness. Link
OpenRules allows non-technical users to easily compare different strings with certain values. Decision table conditions may use simple operators such as “Is”, “Is One Of”, “Starts With”, and “Contains”. There are also more powerful patterns matching operators such as “Like” and “Match”. In this post I will describe these useful operators.
In real-world decision models, our customers deal with complex business glossaries. In particular, it is quite common when one business concept refers to other business concept and it is not immediately clear how to define and use such references. I will explain how it’s supposed to be done in OpenRules. let’s consider a simple example “HelloNestedLocation” with the following glossary:
Iterating over collections (arrays) of decision variables is a frequent need in real-world decision models. For example, the following decision table defines if a company has high-paid employees:
The iteration here is defined by the [for each Employee in Employees] in the first row. The ACTION-BREAK in the column “ActionExecute” will force the iteration process to stop (break) when the very first high-paid employee is found.
In this post we describe an OpenRules decision model that addresses DMCommunity.org Mar-2023 Challenge “Permit Eligibility”. The Challenge asks to implement this rule: “An applicant is eligible for a resident permit if the applicant has lived at an address while married and in that time period, they have shared the same address at least 7 of the last 10 years.” There is already 2 DMN-based solutions published by Bruce Silver who explained that this simply sounding rule requires to address several not so simple considerations. There is also an attempt to create a decision model with ChatGPT, which I analyzed and converted to a working Java code. I asked an OpenRules developer Alex Mirtsyn to look at this problem, and together we came up with a solution described in this post.
These days only lazy people don’t write about ChatGPT and large language models (LLM). Vendors are trying to be the first to announce a ChatGPT integration even when they don’t have anything serious to show. I’ve also written about it: see “ChatGPT Producing Simple Decision Models” and “LLM and Decision Modeling“. This weekend I decided to help ChatGPT (that is now at GPT-4) to address the Challenge “Permit Eligibility” published by DMCommunity.org. It has a simple rule: “An applicant is eligible for a resident permit if the applicant has lived at an address while married and in that time period, they have shared the same address at least 7 of the last 10 years.” But this rule contains several tricky assumptions – no wonder, DM vendors are not in a hurry to submit a solution.
OpenRules, Inc. is now 20 years old! Our team met this anniversary in the best possible way – we did not notice it! We are so busy with adding new powerful capabilities to OpenRules products and supporting our real-world customers. I described a brief history of our company and our development plans 5 years ago. Since then we overperformed by introducing OpenRules Decision Manager which became one of the fastest and user-friendly Decision Intelligence Platform available on the market today. More and more major corporations worldwide choose OpenRules for intelligent business automation. Stay tuned: 20-year-old OpenRules with proven records and unique R&D capabilities is working on new breakthroughs.
Our customers frequently select OpenRules for their decision management needs because of two important factors: 1) Ease of Use; and 2) Performance and Scalability. We have large customers who use OpenRules to create very complex decision models capable to handle large payloads – see an example with 17M records.
Recently we received a request to create a decision service capable to handle 1B records. Luckily this large corporation already uses Apache Spark for scalable computing as thousands of other companies, including 80% of the Fortune 500.
Within a few days, our team built a POC that put an OpenRules-based decision service inside an Apache Spark application. The performance results were really impressive: the total execution time for 1 billion records was under 7 minutes averaging 6 million decisions per second! Read more in the new manual “OpenRules-Spark Integration“.
When we converted a POC into a real decision service that handles more than 30,000 complex rules, we received the following execution results:
Living through the ChatGPT boom, it is interesting to read this article “Is ChatGPT Aware?“:
“Polanyi’s paradox, named in honor of the philosopher and polymath Michael Polanyi, states that “we know more than we can tell.” He means that most of our knowledge is tacit and cannot be easily formalized with words. In The Tacit Dimension, Polanyi gives the example of recognizing a face without being able to tell what facial features humans use to make such a distinction.“
It brings back some of my related thoughts on “Business Rules and Tacit Knowledge” from 7 years ago. It described how “Human Learning” and “Decision Modeling” were moving in opposite directions. Will we see a change?
ChatGPT has the public excited, but the experts are reserved in their praise. Thinking about a practical application of the Large Language Models (LLM) to decision modeling this quote from LeCun caught my attention:
When we create practical decision models we usually deal with an even more limited “universe”. A decision model “manipulates the state of the decision variables” within a very specific business domain (insurance, loan origination, claims, medical guidelines, etc.) complemented by generic concepts well covered by such relatively small standards as DMN and SBVR. Decision modeling universe is really “limited, discrete, deterministic, and fully observable”.
So, being cautious about the current ChatGPT’s hype, we may be more optimistic about the next breakthrough in Decision Modeling. I suspect the answers of experts to my DecisionCAMP-2022 question “Are our Rule Engines Smart Enough?” would be different today.
When 3.5 years ago we introduced a new OpenRules Decision Manager, it was specifically designed as a Decision Intelligence Framework for creation, debugging, and management of Superfast Decision Microservices for that time brand new Serverless world. Over the last 3 years we witnessed how major corporate customers migrated their rules-based applications deployed on the large web servers to OpenRules. Over the last few weeks we saw how several new customers were really surprised that they don’t need anymore heavy lifting for building and managing their rules-based light-weighted microservices. In this brief post I share a working sample that demonstrates how easy it is to build, test, debug, deploy, and run RESTful decision services with OpenRules using any on-cloud or on-premise infrastructure.
OpenRules Release 9.1.0 essentially simplifies how our customers iterate over collections of business objects. Now you may describe your loops in one decision table, immediately see iteration nodes in Decision Diagrams, and analyze the content of each iteration while you are looping over collections inside OpenRules Debugger. Here is a simple loop over an array of Players that accumulates their scores to calculate Team Score:
If in the previous releases every iteration required at least two tables, in Release 9.1.0 one intuitive table is sufficient.
DMCommunity.org offered the Dec-2022 Challenge “Christmas Model” created with ChatGPT. This nice model defines a set of people, a set of gifts, the happiness level, and costs of each gift. The objective is to maximize the total happiness, subject to the budget constraint that the total cost of the gifts must be less than or equal to the budget, and the constraint that each person can only receive one gift. As a holiday exercise, I tried to implement it using a free and open-sourced JavaSolver.com. Here is my solution:
The Holidays season is upon us, and OpenRules team wants to express our sincere appreciation to all our customers and colleagues around the world. In 2022 we made very serious enhancements to OpenRules products and apparently our customers like them. We promise to make OpenRules even more powerful and user-friendlier in 2023. We wish you and your families all the best in the coming New Year!
Our team worked hard to prepare a nice Thanksgiving gift for our customers, and today I am happy to announce general availability of OpenRules-9! This major new release comes with a new implementation of our Graphical Explorer and Debugger as a foundation for the current and future OpenRules Interactive Decision Modeling Environment oriented to business users. Watch new Intro Video, read Release Notes 9.0.0, and evaluate it for free. Happy Thanksgiving!
DMN is a modeling language and notation for the precise specification of business decisions and business rules using well-defined tabular formats. This popular standard even includes an interchangeable XML format. However, contrary to XML (eXtensible Markup Language), DMN can hardly be called extensible. Today’s DMN allows a user to define complex problem-specific decision modeling constructs using powerful FEEL boxed expressions (that still are being criticized as too close to programming). But DMN doesn’t specify means for building simple domain-specific decision tables that look very natural for business users and hide complex implementation details that actually may require programming.
OpenRules empowers business users with an ability to assemble new decision services by orchestrating existing decision services independently of how they were built and deployed. The service orchestration logic is a business logic too, so it’s only natural to apply the decision modeling approach to orchestration. OpenRules allows business analysts to create a special orchestration decision model that describes under which conditions such services should be invoked and how to react to their execution results. Link
The ultimate objective of Business Decision Modeling:
A business analyst (subject matter expert) defines a business problem, and a smart decision engine solves the problem by finding the best possible decision.
Declarative decision modeling assumes that a business user specifies WHAT TO DO and a decision engine figures out HOW TO DO it. This is quite opposite to the Procedural approach frequently used in traditional programming.
IEEE Spectrum just published the article “The Rise of SQL” about the recent SQL’s comeback caused not only by the ever-increasing use of databases, but also by the use of SQL within the fields of data science, machine learning, big data, and streaming systems. While traditionally, Business Rule Engines did not communicate with databases directly, our customers frequently prefer to use SQL-like business rules to access their data when it is necessary following their business logic. At the same time, they want to preserve the power of SQL dealing with databases of any complexity. Two years ago OpenRules introduced a special product “Rule DB” that does exactly this by empowering Excel-based business rules with a run-time RDBMS communication mechanism. In this post we will explain how to migrate an SQL query to OpenRules.
The DMCommunity Challenge July-2022 “Team Performance” gives BR&DM vendors a good opportunity to demonstrate how to handle nested loops. I will describe how it can be done with OpenRules Decision Manager.
DMCommunity.org Challenge May-2022 still has no submitted solutions. I knew that the problem is not as simple as it sounds because we, at OpenRules, have quite a few claim processing customers, whose decision models address similar and much more difficult problems. When I tried to create a decision model for this challenge, I quickly got a solution that still produced these errors while processing a test-claim:
[E71.313] cannot be reported together with [E72.3] [E72.3] cannot be reported together with [E71.313]
But the challenge specifically required not to produce duplicate errors. Trying several decision modeling approaches, I built a few “tried-and-failed” decision models before I came up with two solutions which I feel comfortable enough to share here.
OpenRules, Inc. offers fast support online sessions to help you to start working with OpenRules or to address your technical problem. Upon your request, an OpenRules expert will send you an invite to a remote-support session addressing your particular problem by studying it together with you on your own computer. Anytime you also may order a paid fast-support service that costs only $60.00 USD for up to a 1 hour support session. Link
Decision tables is the most popular mechanism for representation of business logic – no wonder they play the major role in the DMN standard. However, when it comes to analyzing large amount of data, standard decision tables may not be the best way to do it. In this post, I’ll describe a much better approach implemented in OpenRules.
On Apr 20, 2022 I shared recent OpenRules experience building decision services capable to handle huge payloads with sound performance. He described how putting a decision service into a cloud-based environment supporting parallel execution allowed a large US corporation improve the performance 100 times! Watch Recording
While the graphical debugger is the most user friendly debugger, it is currently available only under Windows and Linux. The Command Line Debugger is available under Windows, Mac, and Linux. Continue reading →
I’ll share our recent real-world experience building decision services capable to handle huge payloads with sound performance. I will describe how putting a decision service into a cloud-based environment supporting parallel execution allowed us to improve the performance 100 times!
Usually input validation is an essential part of business decision models created by OpenRules customers. They add rules that validate input decision variables for null values, empty strings, impossible values like Feb 29 during a non-leap year, and many other problem-specific input errors. These custom error reporting mechanisms usually generate lists of errors with explanations in the JSON response for RESTful decision services. However, while input errors are diagnosed by the decision service, its return code is usually 200 meaning it was a “good” request. In this post I will describe how your service may return code 400 for bad requests.
On December 12, 2021 Apache Log4J 2.x reported that this widely used Java logging framework has been exposed to a serious security vulnerability. OpenRules Decision Manager like many other Java-based products uses Log4J. To mitigate this problem, we quickly switched to the recommended version 2.15.0 of log4j that was supposed to remove the above vulnerability. However, on December 14 the second vulnerability was discovered and Apache released the version 2.16.0 to address the problem.
Based on the seriousness of these events, we decided to create a new emergency release 8.4.3 of OpenRules Decision Manager that uses log4j version 2.16.0 (not 2.15.0). We’ve already built the first version 8.4.3 and it’s going through thorough testing. For urgent situations we made the evaluation version 8.4.3 available from here. Our team will continue to work hard to make sure that well-tested Release 8.4.3 will be available to all customers tomorrow morning. If you have any questions, please contact firstname.lastname@example.org.
AWS Lambda has recently extended the capability to track the current state of a function through its lifecycle. In this post AWS wrote: “We’re extending the General Update from September 30 2021 to December 5 2021. The End of Delayed Update date is now also changed to December 6 2021.” With this change, all users of AWS Lambda need to update their AWS SDK-based automation workflows. How would it affect OpenRules-based decision services deployed as AWS Lambdas?
OpenRules provides multiple ways to refer to decision variables inside decision tables and use their values in text expressions. In this post I will use simple examples to explain how to use different expressions inside decision tables.
OpenRules Decision Manager becomes so powerful and easy to use that it dramatically reduces the efforts needed to develop new decision models and deploy them on cloud as decision microservices. Usually everything is done in Excel with our graphical Explorer without any coding. Along with development of large decision-making applications, our team has great practical experience of rapid creation of working prototypes or Proof of Concepts (POC). After a brief meeting with a customer, we quickly (usually within 1-3 days!) put together a POC tested locally and deployed on cloud, so the customer may start testing it remotely without any installations! Continue reading →
Our customers will appreciate the new OpenRules Release 8.4.2 as it essentially improves the validation and consistency checking of their Rule Repositories. It provides much better error diagnostics in business friendly terms. In the Release 8.4.2 we actually implemented a new built-in compiler that runs during the BUILD phase (build.bat), so the majority of errors can be caught before Java code generation. We also added an ability to use CSV-files in situations when XLS-files are too big/slow to handle. We removed Maven Wrapper from all samples and made a free Apache Maven a pre-requisite. Release Notes
The DMCommunity.org Challenge Oct-2021 offers a simple decision model used by our Red Hat colleagues to demonstrate how the DMN standard deals with dates validity. OpenRules similarly follows the DMN standard as shown in the implementation below.
Last week I listened the webinar “The Art of Knowing How to Leverage Decision Intelligence” presented by Roy Schulte, Distinguished VP Analyst at Gartner. Describing the major trends in decision intelligence and why it is growing, Roy concentrated on the question “when to use machine learning, optimization or business rule engines”:
When it comes to handling large collections of data in business rules, OpenRules customers frequently use Excel-based DecisionData tables and/or decision tables of the type “BigTable“. It works fine when Excel tables contain thousands or even tens of thousands rows. However, when an Excel file contains hundreds of thousands rows Excel itself becomes much slower to search and requires much more time and memory to be downloaded in OpenRules. In this case we recommend our customers to switch from the Excel to the CSV format.
OpenRules Decision Manager provides all necessary tools to build, test, and debug your business decision models. The same people (subject matter experts) who created decision models can create test cases for these models using simple Excel tables or objects coming from the outside world (from Java, XML, or JSON). This post explains how to create and use test cases and data tables.
Modern enterprises quickly evolved from monolithic to microservices architectures and they naturally expect that rules-based decision services to be good citizens of the new CI/CD world. My DecisionCAMP-2021 presentation https://lnkd.in/g_rWAazF shares OpenRules experience of developing, integrating, and deploying operational decision microservices which satisfy the requirements of modern enterprise architectures including security, continuous integration and delivery/deployment. Using specific examples, it explains how business analysts may represent and maintain these requirements in their business decision models. Keywords: Business Decision Models, Decision Microservice, Invocation Context, Authorized access, Security, CI/CD Watch
This is the name of the DMCommunity.org Aug-2021 Challenge that is supposed to predict survivors of the Titanic tragedy based on partially known actual results. Dr. Bob Moore has already submitted a very good analysis of this challenge and applied several ML-based approaches to solve it. It inspired me to ponder the same challenge from a bit different angle. I thought I could try two approaches: 1) using common sense or human prejudice-based rules to predict who could survive; 2) using our very simple Rule Learner to let ML algorithms to do the same. I spent almost the whole day today working on this problem, and this post describes what and how I did. It is interesting to compare the final results:
On Sep 14 I will present “Continuous Digital Decisioning or Operational Decision Microservices in the CI/CD World” at DecisionCAMP-2021. In this presentation we plan to share recent OpenRules experience of developing, integrating, and deploying operational decision microservices which satisfy the requirements of modern enterprise architectures including security, continuous integration and delivery/deployment. Here are two key slides:
Release 8.4.1 of OpenRules Decision Manager is about “Securing OpenRules Decision Services” – click on this link to see the new tutorial that describes how to secure decision services using JWT Authentication and SSL communication. Release 8.4.1 also provides business users with an additional control over input and output of their decision models allowing them to validate incoming JSON requests and choose which decision variables to exclude from the produced responses. Read Release Notes
Being at the heart of any decision model, OpenRules Glossary uses columns “Variable Name”, “Business Concept”, “Attribute”, and “Type” to define all used decision variables. It is recommended to add the optional column “Description” with plain English descriptions of these variables.
Additionally, OpenRules 8.4.1 Glossary may include optional columns “Used As” and “Default Value” that allow you to effectively control the input and output of the decision model. It can be especially important when your decision model is deployed as a RESTful web service, and you want to validate the incoming JSON structure and decide which variables should be included in the outgoing JSON structure.
Any practical decision modeling tool allows a user to represent a business glossary that specifies all decision variables and thus is at the heart of any decision model. The DMN standard does not explicitly specify a glossary letting different implementation products to compete. So, the modern digital decisioning systems use different constructs to organize their glossaries. In this post and follow-ups I will describe how OpenRules deals with its most important tables of the type “Glossary” which are always the focal point of any decision modeling process.
As OpenRules Decision Manager experiences growing popularity, many potential customers want to develop a POC (Proof of Concept) before committing to our product. Here is our typical POC implementation roadmap:
The integrated use of Rule Engine and Machine Learning (ML) products becomes more and more popular. OpenRules Rule Learner is a good example of such integration. While there are plenty of powerful Machine Learning algorithms available off-the-shelf, it can be quite practical to use rules-based machine learning instead. The classical rules-based technology may address learning problems considering historical and constantly changing operational data. In such situations a “Rule Engine” plays a role of a “Rule Learner”. Here is a good example.