.png)
.png)
If you're comparing CPQ solutions, you've likely come across the terms constraint-based and rule-based configuration engines. Let's break down the strengths and weaknesses of each.
First, let’s look at what it means to be Rule-based.
Rule-based programming is what we usually think about when we think about programming. It’s part of the imperative programming paradigm, which describes HOW the program should do something by explicitly stating each instruction in a series of steps. This is in contrast to the declarative programming paradigm which describes WHAT the program does, without explicitly specifying the sequence of actions.
For example, if configuring a bolt, nut, and washer, the program could state that the bolt needs to be chosen first, then the washer, and then the nut, in that order. In this instance, it’s fine to have to choose a bolt first, but what if the engine is configuring a laptop computer? Let’s say you have a processor option, memory, and screen size, set up in that order. What if the user wants to choose screen size first? The limits to rule-based ordered sequences configurators become clear.
Rule-based engines are defined on a set of rules where each rule has a condition and an action. When a condition is met, the engine will execute action until there is no action to execute.
Rule-based engines don't have the capability to find and optimize a solution to your configuration problem. They can only validate the rule and execute actions. Additionally, most rule-based configuration engines have only simple predefined conditions and actions. Rule-based configuration engines lack the expressive power of constraint-based configuration engines.
We will compare this now to constraint-based configuration engines.
What does it mean exactly when a vendor claims their configuration engine is constraint-based?
Constraint-based comes from the declarative programming paradigm, which is a method of programming which describes what the program does, without explicitly specifying the sequence of actions.
First, we need to understand what a constraint-based problem is, that the Constraint Satisfaction problem is a problem expressed in mathematical terms by a set of variables and constraints. The problem is solved when each given variable has a value that satisfies all the constraints on the variable.
Components of a Constraint Satisfaction Problem are:
The solution to the problem is found when we find a set of values assigned to each constraint variable to make all logical expressions true.
The constraint-based engine goes to work searching for a set of values that will satisfy all constraints. It typically searches for a solution in depth first search algorithm with constraint propagation to prune the search tree.
.png)
Further, the constraint-based engine can find a solution that minimizes or maximizes an objective like an expression defined on a constraint variable. In nutshell: it can generate and optimize a solution.
For example, the “eight queens puzzle” is a typical Constraint Satisfaction problem. In this problem, eight chess queens are placed on a 8x8 chessboard so that none of the queens threaten each other. If you are a chess player, you know that this means no two queens could share the same row, column, or diagonal.
The Constraint Satisfaction problem is expressed as a problem of placing n non-attacking queens on an nxn chessboard. See more about the eight queens puzzle on Wikipedia.
Sudoku is another familiar example. The problem involves a 9x9 grid. The object is to fill the grid with integers from 1 through 9. Each integer can only appear once in each row, column, and major 3-by-3 square. The grid is pre-populated with partial clues. The solution is found when you complete the remainder of the grid.
Remember, with constraint-based, it works for any logical expression as long as you can model your configuration problem logically. However, it is very difficult to model product configuration in pure constraint. There are a lot of product configuration rules that can’t be expressed in constraint logically.
if you have a required rule that says “A implies B (A -> B)”, when condition A is met, one would expect the configuration engine to enforce B, but since it is a pure constraint-based rule, it will break condition A to satisfy that rule. This outcome is not what the user is expecting.
For example, the configuration engine starts with a default configuration and when users change the default configuration, it will fire some constraints and users really don’t want the engine to change the original default configuration to satisfy the constraint. In this case we should keep default configuration to satisfy the constraints.
Constraint propagation goes both ways. For example, X == Y, it will propagate X to Y and Y to X simultaneously. However, sometimes we want to go one way in a sequence. Remember our nut, bolt, and washer example? In these cases, rule behavior is preferred.
Constraints need to be consistent. You can’t assign a value to a constraint variable and change it to different values later, but it’s the rule that allows you to do this. Where the functionality of constraint is not desired, rules can come to the rescue.
Neither approach wins alone – rule-based engines offer control but can't optimize, while constraint-based engines optimize but struggle with sequence and stable defaults.
Most real configuration problems need both. The strongest engines combine the two under an intelligent solver that picks the right method per problem automatically – giving businesses a CPQ that handles any requirement, stays easy to maintain, and scales as they grow.
.png)
.png){kind=spacer}