When evaluating CPQ solutions, you may hear about constraint-based vs. rule-based configuration engines. This post will help make sense of the pros and cons of both. Veloce CPQ is exceptional in that it makes use of both constraint-based versus rule-based technologies. Read on to see why this is a benefit.
First, let’s look at what it means to be Rule-based.
Rule-based Configuration Engines
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.
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:
- a set of constraint variables with a defined domain
- a set of logical expressions defined on the constraint variables.
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.
Constraint-based engines maximize an objective
Further, the constraint-based engine can find a solution that minimizes or maximizes an objective like an expression defined on a constraint variable. In a 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 8×8 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 9×9 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.
Limitations of Constraint-Based Engines
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.
Most configuration rules behave more like rules, not constraint. For example, 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.
Performance of Pure Constraint-Based Engines is Lacking
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.
Veloce CPQ Configuration Engine uses Both Constraint and Rule Technology
As you can see, both approaches have their pros and cons and we need both technologies in a configuration engine. Veloce configuration engine supports both constraint and rule with intelligent solver technology. Our solver is built with proprietary goal search and constraint propagation technologies to execute both constraints and rules with lighting speed. Veloce configuration engine chooses whatever is appropriate to solve the complex configuration problem. When constraint is proper technology to solve the problem, Veloce uses constraint; when rule is the proper technology, Veloce uses rule. The best part is, users don’t have to make a choice — it happens in the background automatically.
What this means for Veloce customers
It’s great that Veloce utilizes both Constraint and Rule technologies in our configuration engine, but what does this actually mean for business? Basically, with Veloce, your CPQ is:
Free from complications
Your business requirements — simple to complex — can be fulfilled with our configuration engines.
Easy to use and maintain
Maintenance is much easier, as the rules are simpler to put together.
Extensible
Your Veloce solution can grow as your business grows and you introduce new products or services.
Veloce allows enterprise to sell creatively, without being restricted by technology that is lacking. You become free to implement your go-to-market strategy as intended, without having to manage expensive workarounds for failing technology that relies on limited configuration abilities.
