Separation of concerns in organisations when it comes to the involvement of business and IT is very important. Let’s have a look at an example and see exactly what this means.

The goal of the Separation of Concerns here is to build an abstraction layer across the enterprise that is maintainable by business, operation or subject matter expert (SME) teams, with minimum need for the involvement of IT (e.g. developers). This abstraction is the essential key to business agility which gives the control of business rules, operational decisions and processes to business.
For example, insurance is one of the many industries that deals with policies, rules and regulations in day-to-day operations. One of the benefits of using a business rules management system is to make sure the decisions that are taken for each step of routine daily tasks are accurate, easy to understand and maintainable.
Business
For example, when you want to get insurance for your car, there are many business rules involved in preparing a quote. Each of these rules may be applied during the different steps of the decision-making process. For instance, one decision made during quote preparation is identifying the potential theft rating of your car.
In order to make this particular decision there are many business rules involved, such as:
- If the car is a convertible, then its potential theft rating is high.
- If the price is greater than $45,000, then its potential theft rating is high.
- If the model is on the list of “High Theft Probability Auto*”, then its potential theft rating is high.
- If all of the following are true, then the car’s potential theft rating is moderate.
- The price is between $20,000 and $45,000
- The model is not on the list of “High Theft Probability Auto”
- If all of the following are true, then the car’s potential theft rating is low:
- The price is less than $20,000
- The model is not on the list of “High Theft Probability Auto”
*The “High Theft Probability Auto” list is maintained by Risk Management and provided as input to the eligibility rating process.
To model these sets of business rules as part of a decision, you can simply use the decision table below:

A Decision table can also model in:
- MS Excel, Google Doc/Drive – You can import them later
- Using our Advanced Decision Table Editor
As you can see, this decision table clearly defines business rules for categorizing and rating your car, and is modeled in a tabular form, which is understandable by anyone without requiring any technical skills. That’s why it can be modeled and managed by the business without the need to understand the underlying technology or code.
Of course, business logic will be far more complex than a single decision table. Also, keep in mind, the decisions can even be deployed as a service and become available as a REST API endpoint across all of the business processes and applications.
IT / Development Team
In order to execute the decision table above, IT applications, services or business processes are simply required to provide input parameters to the decision model. That’s all.
To integrate a decision model into your application, you simply can write 4 lines of code as below:
[TestMethod] public void define_potential_theft_rating() { // Creating and engine for the execution of the model var engine = RuntimeEngine.Create(@"Car Risk Rules.xlsx", "PotentialTheftRating"); // Creating sample data, var car = new Car { Price = 27000, Made = "Hyundai", Model = "IX35", }; // Executing decision model against the sample data var result = engine.Run(car); // Asserting result Assert.AreEqual(car.PotentialTheftCategory.High, car.TheftCategory); }
In this example, we used Excel as a modeling tool, you can use our unified authoring platform that gives you full capabilities for modeling, debugging, version control, collaboration and more.
Also, when there are many different applications, business processes and different devices (e.g. mobile, tablet, etc.) that need to reuse this logic, FlexRule Server allows the deployment and execution of this decision by a simple WebAPI interface and exposes business rules, decisions and logic to a Decision-as-a-Service within your SOA infrastructure.
Benefits
With respect to the separation of concerns between the business and IT, now business logic, decisions and business rules can be modelled independently of technology and IT. Also, IT system implementation can leverage any technology without worrying about breaking any underlying business logic implementation. The other benefit of this approach is that it empowers business people to take care of business logic within the business application, business processes, and across the enterprise. It gives the control and management of business logic (i.e. business rules, decisions, flows, etc.) into the hands of the business.
Book a Custom Demo
Conclusion
This clear separation of concerns in modeling business rules and decisions along with other models, as well as actual IT implementation, allows easier alignment to change for organization. Business rules, and decisions can now be maintained, tested and deployed independently, and as a result this increases business agility.
The best option to model business decision and rules is to use the Decision Model and Notation standard that not only allows you to model rule-driven decisions but also, non-rule-driven decision logic.
Last updated July 23rd, 2024 at 10:32 am Published February 23rd, 2015 at 05:05 am



