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 people 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 people.
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.


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:

As you can see, this decision table clearly defines business rules for categorising 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.

Therefore, testing of the decision logic becomes as easy as writing 4 lines of code:

public void define_potential_theft_rating()
    // Creating and engine for the execution of the model
    var engine = RuntimeEngine.FromExcel(@"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);



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.


This clear separation of concerns in modeling business rules and decisions along with other models, as well as actual IT implementation, allows easier alignment with organisational strategies and vision. These can now be maintained, tested and deployed independently, and as a result this increases business agility.

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. We will talk more about Decision-as-a-Service and FlexRule Server in near future.

Last updated September 2nd, 2019 at 01:49 pm, Published February 23rd, 2015 at 01:49 pm