By Shaowei Mao, Veloce Co-founder and CEO, and Jess Bolen
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 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.
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.
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.
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:
1. Free from complications. Your business requirements — simple to complex — can be fulfilled with our configuration engines.
2. Easy to use and maintain. Maintenance is much easier, as the rules are simpler to put together.
3. 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.
I read a blog post recently complaining that Configure, Price, Quote (CPQ) space is stagnant and lacks innovation. I completely disagree with that.
Beware a common sales tactic of advising you to deprioritize more complex use cases for phase two deployment. We hear stories from customers that have been told by a CPQ vendor that you should solve simple problems first and leave complex use cases for later.
The Veloce team works hard to develop solutions that simply work and require no coding for the customer’s admin team. We take care of the CPQ development, so our customers can take care of business. However, for Systems Integrators and developers who would benefit from insight into our development tool, I’m providing a glimpse of the tool our team uses behind the scenes.
Nucleus Research report highlighting results of increased revenue and reduced operating costs achieved by companies in Telecommunications, Financial Services, and Health Care sectors after deploying Veloce CPQ
Supercharge your Salesforce CPQ with Veloce to easily manage your most complex use cases with incredible performance.