In this “key considerations” installment, I’ll cover why a Business Rules Engine should be a key consideration when choosing a low-code platform. In my prior blog entries (first, second, third), I mention other helpful tips and considerations.
Business Rules Engine
Maintaining table definitions, connections and business rules is an ongoing challenge. Hard coding them in every program increases your maintenance burden and introduces potential inconsistencies by residing in multiple places. There is great architectural advantage in storing all your definitions, connections and rules in a centralized Business Rules Engine rather than in your applications.
Why? When a business rule’s definition and enforcement is the sole responsibility of one entity – the Business Rules Engine – instead of a team of different front-end and back-end developers, then the execution of the rule will be guaranteed. You can define a rule once knowing it will be enforced everywhere.
The high-end low-code platforms include a Business Rules Engine as part of its solution. If the low-code platform your evaluating has a Business Rules Engine, here are some features to look for:
Are you able to create, store and maintain definitions in a single repository?
The fundamental tenet of a Business Rules Engine is to keep data definitions separated from the applications and databases with which they work. Every developer must be able to easily see and access the repository.
Are the definitions stored at the database or application level?
If definitions are stored at the database level, that is not the ideal deployment model. The downside of deploying rules at the database level is that all database vendors have their own proprietary ways to implement triggers and stored procedures, effectively locking you into a specific database. Some Business Rules Engines avoid database lock-in by injecting the rules at the application layer, but then every program has duplicate source code which can lead to inconsistencies and difficulty managing code.
The ideal deployment model is through an independent data services layer where the Business Rules Engine is loosely coupled from the database and the applications layers. This architectural benefit allows changes made within the Business Rules Engine to be automatically enforced without changes or recompiling.
For example, imagine you need to update the postal code’s validation rule on the customer table to call a RESTful service instead of performing a table look-up. After making the change in the Business Rules Engine, utilizing a data services layer will allow every program that inserts or updates data in the customer file to immediately use the new postal code rule without recompiling any of those programs that interact with the customer table.
Can you import existing data schemas?
Most projects must extend existing applications with existing databases. Make sure developers can import existing data, schema and stored procedure definitions from sources outside the low-code platform for use within the Business Rules Engine.
Are the business rules accessible from programs outside the Low-code platform?
Be sure the Business Rules Engine can be leveraged from any application, regardless of the development environment used e.g. low-code, Java, C#, PHP, VB, JavaScript, etc. The net result is that all of your applications – irrespective of their age or technology – use a common set of business rules to govern all database I/O and greatly improve your data accuracy.
If they cannot be used outside the low-code platform, you’re back in the duplication game again. Duplicate rules mean duplicate maintenance. And duplicate maintenance opens the door to potential business rule inconsistencies.
Can the Business Rules Engine store more than just business rules and validation logic?
Some Business Rules Engines allow you to store more than just database definitions, connections and validation rules.
In my last post on the key considerations when selecting a low-code platform, I’ll discuss what cross-platform support means and why it makes a difference to your end-users.
