Once one has worked for a certain time in the realm of Configure, Price, Quote (CPQ), astute or just curious, one may realise that not all CPQ solutions are the same, regardless of what is claimed. They all claim that they will solve (amongst other things) your guided selling and/or your product configuration problems. Best thing since sliced bread, blablabla… You’ve heard it all before… And by the way, in case you’re wondering, most of those claims are not even accurate in the majority of cases, but I won’t dwell on it (yet).
Instead, if you’re in the process of evaluating or looking for a CPQ solution to solve product configuration problems, there’s a few things to keep in mind:
- How well does it integrate with the existing eco system (mainly CRM, ERP, eCommerce Portal)?
- How easy is it to use and to admin?
- How good is its configurator?
I’ll elaborate on the first two points in upcoming articles. For now I’ll just focus on the configurator side of things.
Configurators comes in all sorts and shapes: most are able to handle complex things, some are just a very simple bundling tool. The most capable ones, however, all have unarguably one thing in common: they are powered by a Constraint Engine or a Declarative Rule Engine or a mixture of the two.
The Ugly: Sequential Rule Engine
A configurator powered by a Sequential Rule Engine (as it’s the case in many enterprise-grade CPQ, and yes even recent enterprise grade ones!), will have to give priority (or sequence order) to each and every rules in order to have them fire at the right time. This may sound powerful at first, but in reality it offers false flexibility, and it’s very tedious to implement and even more to maintain. In order to work, priority has to be set accordingly during implementation. Except, it’s often very hard to know in advance exactly what needs to be triggered before what; hence one always ends up setting vastly different priorities between rules.
Does that sounds familiar? Does it remind you of code writing in some languages in the 80’s? When lines had to be numbered because one could not be sure for certain that they will not need to insert a line of code or two in-between two lines. The numbering of lines instead of being straightforwardly sequential was sequentially incremented by 10 (or sometimes 100). If one needed to insert some code between line 10 and 20, one would just add a line of code in between those two aforementioned lines and number it 15 (for instance).
Well it’s very similar in sequential rule engines: I’ve Rule A that needs to trigger before Rule B but because I don’t know yet if I’ll need anything firing in between those two rules (or indeed even before Rule A). So I’m going to set Rule A with a priority of 10 (lower is triggered first) and B with a priority of 20… I’m sure you can imagine the mess after hundreds of rules have been written… This is very ugly!
The Bad: Declarative Rule Engine
In a Declarative Rule Engine, rules are written without the need to express when they should trigger: the engine is smart enough to figure out when all the rules should trigger in order to be satisfied. This is nice because it alleviates the major problem described above with Sequential Rule engine. A great example of a very good and commonly used software powered by a declarative rule engine is Microsoft Excel. In Excel when you create your functions and lookups, one does not need to say “that needs to be done before this…” even though, most of the time, things you’ve defined always need to be done before other things in order to make sense. Excel just magically figures it out on its own! It’s generally good enough for most things, thus that’s why a lot of people, before moving to a proper CPQ solution, are using Microsoft Excel to do the job.
The problem is that it’s so simple and easy to add rules, that their numbers tend to explode exponentially over time. This then results in even more complexity when one wants to maintain a configuration model powered by a declarative rule engine. And performance is drastically affected too: when there’s thousands of rules, having the engine figure out every time which rules should be fired before which, rapidly clogs up the system. The engine should be actually firing the rules, rather than figuring out when to fire them: most of the CPU time is spent on sorting the rules instead of executing them!
The Good: Constraints Engine (also known as Virtual Tabulation in some CPQ solutions)
Constraints Engines have existed for decades (at least since the early 80’s) but have rarely been used in enterprise software until fairly recently. It was more used in universities (with languages such as Prolog or to a lesser extend Lisp). But eventually those researches led to the first Constraint Engine able to solve enterprise configuration problems (Swedish Institute of Computer Science, The University of Edinburgh and Technical University of Denmark spring to mind).
Here’s how a Constraint Engine work:
Instead of defining rules (hundreds and thousand of them), generally relying on the same piece of information over and over again, why don’t we create a few constraints (dozens) that will make sure that things (in the CPQ case, generally products) are picked up/bundled up together correctly?
For instance if one wants to match car interior color with the car chassis color, you can either say with lots of rules (as many as colors):
- ‘black interior’ goes with ‘black chassis’
- ‘red interior’ goes with ‘red chassis’
- etc.
OR you can write one single constraint that says:
- Interior and chassis of the same color go together.
I know which one I prefer! Especially when the complexity builds up: constraints are always easier to read and visualize than tons of rules firing one after another. The only downside here is that because of their potentially ‘global’ nature, constraints have to be written bearing in mind the implication they can have on overall performance. If they are badly written, the performance can be dreadful.
So to summarize in a few words:
- Sequential Rule Engine: lots of rules that needs to have their priority managed
- Declarative Rule Engine: even more rules that don’t need to have their priority managed
- Constraints Engine: few constraints that don’t need to have their priority managed
If you’re interested to read more about what a Model N configuration engine can do for your configuration problems, I suggest you have a look here or you reach out to me directly at vbenoit@modeln.com or linkedin.com/in/vincebm
