For business admins implementing product configurators of any kind, their primary goal is to allow end users to configure solutions, especially highly complex and customizable products and services as quickly and intuitively as possible.
For products and solutions that are highly complex, with hundreds of configuration rules, with multiple rule dependencies, and sometimes highly advanced calculations, traditional configurators have struggled to maintain high-performance, speed, and usability, because traditional configurators have not targeted optimization of scale and performance of rules.
Here at Logik.io, we’ve learned from over 100 years of collective experience building configuration solutions. We believe that the next generation of configuration solution requires speed and performance especially for the most complex solutions, and we’ve built our next generation configuration product with three primary goals in mind to achieve that objective:
- Build a configuration engine optimized to run rules. Minimize all other operations.
- Model the smallest configurable product object in memory during configuration.
- Rules execution should do the least amount of operations each update.
To deliver on these goals, we’ve focused on building the following into our configuration solution:
Statefulness & Caching
To optimize the performance of each click during a configurable session, we have built our solution to use a stateful engine.
This feature allows us to maintain a cached version of the product and reference it during each update. The state lives on the server and can be quickly accessed, meaning that we don't need to spend any time doing product lookups. Also, every call that is made to Logik.io can be a set of changes to that stored product instead of the full object.
This means a configurable product with even 1000 or more attributes may have updates with no more than a handful of fields each time. That makes rule preprocessing run fast, allowing us to devote maximal processing time to running business logic. An update need only be concerned with the changes made since the last call into the Logik.io system.
Leverage a Configurable Product Object Model
Now that we are managing a configurable product in memory, it is important that it be modeled in the most efficient way. Configurable products are complicated objects that may feel overwhelming at first. But, they can be reduced to their simpler component parts.
At a fundamental level, a product exists as a collection of fields or “attributes” and a collection of products. Ultimately, in an attribute based configuration model, the set of fields is the input that drives business logic.
Visibility, editability, message feedback, and other features that are typically part of the guided selling component of a CPQ platform are all extras to guide users in the course of configuration. Product existence can be dispensed with for input logic too since a recommended product will not drive other rules. All will be ignored during the actual rule processing.
So, the configurable product only needs to be aware of the inputs from the end-user that touch fields. This distinction means that in our rule engine we can cast aside any mechanism for managing what happens to any of the other properties on a configurable product as all are a logical consequence of fields and rules. They are outputs instead of inputs.
To model this efficiently, the products, view state (hiding, option exclusion, editibility), recommendations, and messages within the end-user configuration can live in a subcategory of configurable product components that work one way: from the rules engine to the user.
Only the fields list needs to be kept up to date in this type of model, from inputs getting fed from the sales user. And, since we are working on a stateful model, these fields will be reduced by only operating on changes from the stored state.
Rule Optimization
Just as important a concern as the size of the configurable product is the complexity of the rules operating on it. As described above, at Logik.io we’ve stripped down the configurable product into its smallest components and operated only on them. Rules must do the same.
To do that, we identify what the driving input fields are for each rule. Rules will execute only when their input fields are changed by either the user or other rules. Therefore, execution performance is tied to the number of fields updated (and the rules that they fire) rather than the number of rules defined for a configurable product.
To do this, our Logik.io next generation rules engine maintains a rule tree managing the input and output of every rule. Again, if a rule adds a product or message, this is something that can be disregarded until the field state settles. But if a rule has a determination action, that update can bring more rules into play. With this tree, rule execution will begin with an initial list of rules based upon the change set of input fields. These fields will be marked as dirty. When a rule executes, its output may update the list of dirty fields, which could trigger more rules to execute. This process is repeated until there are no more updated fields or rule execution is exhausted by limiting out on the number of rules allowed to run. For most real world examples, the set of rules will resolve quickly, resulting in a lightning fast performance for end-users of the platform.
Conclusion
In order to achieve maximized performance and to build a truly next generation configurator, Logik.io has taken multiple approaches: caching, minimal product modelling, and rule optimization, each interacting to give a performance and scale benefit greater than the sum of its parts and one that guarantees maximal performance for even the most complex product configuration use cases.
Want to learn more about the benefits of Logik.io's proprietary configuration rules engine? Reach out!
