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:

```[TestMethod]
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,
Model = "IX35",
};

// Executing decision model against the sample data
var result = engine.Run(car);

// Asserting result
Assert.AreEqual(car.PotentialTheftCategory.High, car.TheftCategory);
}
```