In this article, we discuss what a dynamic business rules engine is in software development and a few approaches that can be employed to achieve one.
What is a business rules engine?
A business rules engine is a software component that executes one or more business policies or procedures, or “business rules”, in a runtime production environment. In most software solutions, business rules are often statically coded into the system in languages such as C#. These rules might live in Windows Services, Web Services or Web APIs. The business rules will have been captured by an analyst at one point and documented in a user story or functional specification for a developer to ingest and build code from.
If a requirement changes, the analyst typically will document this, then pass the change request over to the developer for him to then build. This often involves lifting the hood on the existing codebase, making the changes and then going through a test and release cycle.
Dynamic business
A dynamic business rules engine allows the end-user to make changes to the way their software behaves – without developer intervention.
Download our strategy guide to start implementing dynamic business rules to your organization.
Why?
The benefits of implementing dynamic business rules are obvious. Some of the reasons mentioned for implementing them are:
- Regularly changing requirements
- The business needs visibility into business rules execution
- Users want to be able to modify their application’s behavior without developer intervention
From a software vendor’s perspective, implementing dynamic business rules can free up developers to work on more interesting tasks or save the business money if specific features can simply be configured from a user interface.
[bctt tweet=”Dynamic business rules can free up developers to work on more interesting tasks” username=”GAPapps”]
Options
Depending on how much configuration management is required, you have a few options:
-
Implement configuration tables that enable/disable specific branches of code in your application based on values held in your configuration tables.
-
Off the shelf solution.
- Build your own dynamic rules engine – an extension of #1 but with much more dynamic code.
Configuration Tables
You can use configuration tables if the business rules you need to amend are simple.
For example, you have an application that extracts the X number of records from the database for each query. The value for X could be defined in the admin section of your application and fetched at run-time thereby giving you some element of dynamic business rules.
Or maybe another set of examples are the descriptions of page headers, images or text on buttons in your web application. Settings such as these can be stored in configuration tables and administered by power users on a client site.
Download our strategy guide to start implementing dynamic business rules to your organization.
What sort of data should be in the configuration table?
You can keep this generic, yet simple and have a database table with a similar definition:
|
Column |
Description |
Data Type |
|
SettingKey |
The unique key, e.g. WelcomeMessage |
String |
|
SettingDesc |
Human readable description for the admin user, e.g. This is the login message the user sees |
String |
|
SettingCategory |
This can be used to group settings per functional area, e.g. LoginSettings |
String |
Then at runtime, you can load these settings via some kind of helper class.
Off the shelf
You’ll need to do your homework and see what’s out there. Integration with your existing product stack, training, licensing costs or technical support all need to be considered.
Workflow Foundation integrates easily with your .NET web applications allowing you to build workflows in Visual Studio.
You can easily model process flows and develop business rules through the designer canvas that ships out of the box.
You can re-host the Workflow Designer in a standalone WPF application for business analysts to use on their machines. The designer canvas offers a drag and drops user experience which is hard to beat.
One thing worth mentioning is that when you re-host the Workflow Designer in a WPF application, you’ll lose IntelliSense support. ActiPro has a product that helps you get around this, though. You can speak to our team too as our engineers are experts and building applications using WPF!
Naturally, you need to import your domain-specific objects and DLLs into the designer to use them, and whoever updates the workflows must know their way around the object graph and problem domain. You’d need to do this with other off-the-shelf products too.
With the advent of .NET Core, it’s not clear if Microsoft are going to port Workflow Foundation, which is a slight concern. The community are pushing for it though!
Other commercial products are:
Roll Your Own Rules Engine
This is where things get interesting, but it involves substantial effort. With Expression Trees, you can “write code that writes code”. Rules can be built in run-time using configuration data stored in your database and evaluated.
There are quite a few examples of this on the web. Check out the following implementations:
YARE allows you to do things like this:
Expression Trees
With Expression Trees, you can manipulate objects, properties, and methods at run-time. You can form dynamic, in-memory branches of code and execute them.
Taking it a step further, you can load external assemblies via reflection into your application and write a web interface that allows you to construct rules around the objects contained in these assemblies.
For example, consider the following, you have an assembly that contains a Person object with properties such as Name, Age, Address, ZIP Code.
The person object also contains another object Notification.
With the web interface that leverages expression trees, you can write code to the effect:
If Person.ZIPCode = 73301 Then [GenerateAndSendEmailToAustin]
Where:
- Person = Object
- Zip Code = Property
- GenerateAndSendEmailToAustin = method invoked at runtime when the precondition is evaluated successfully. i.e. the person zip code being processed = 73301.
The key point here is that the actual method in the assembly is being selected by the user from a rule admin/web interface, and the rule definition is being persisted in a database and subsequently loaded and executed at run-time later.
Amending rules and change management
End users rarely want to modify the business rules daily in their application. A business rules engine should be used by administrators, business analysts and technical support staff.
A change management process should be adopted when new iterations of business rules have been developed to mitigate any risks of breaking your application. You don’t want to update a process or business rule that take immediate effect in your production environment (unless it’ a hot-fix).
It’s a good idea to split your business rules into two camps:
- Rules that can be updated by users
- Rules that should not be updated by users. i.e. core product rules
Make these decisions as you build your product and get feedback from the user community.
Summary
In this article, we’ve introduced dynamic business rules, and why they can be beneficial for both the end-user and software vendor. Here at Growth Acceleration Partners, our expert team of engineers can help you deliver such solutions, and have expertise in Analytics, Mobile, Cloud development and QA.
We recognize that finding cost-effective and quality software engineers can be a problem. Whilst some offshore models look attractive on paper, issues regarding timezone and culture can hinder project delivery. GAP is based in Austin, TX and by using software development centers in nearby Costa Rica and Colombia, we can mitigate such risks. No more late-night calls or email boomerang.
Give us a call today and see how Growth Acceleration Partners can help you.
