On Smart Configurators, for IT Architects

Manufacturing is the key player in applied intelligent configuration, but software businesses are catching up too. Factoring out dependencies between components (or classes, services etc.) to separate configuration issues from application logic, is a well-tried SW-variability principle likely to evolve further in the era of machine learning (ML).   

Dependency…. 
…inversion, injection, “intermediation” (broker pattern, bus pattern), factoring-out (configuration-file pattern), etc; well-known SW architecture tasks. Some “tricks of the trade” in product configuration elsewhere turn out useful in IT as well and, judging from some recent papers, ML becomes augmentative for those.

Intelligent configurators assist, or replace in part, a human role such as a technical salesperson. Which in turn implies a “translation” from a customer’s wishlist to a matching selection of components and their configuration, without redesign. The result: a custom-fit product offer (sometimes even one-of-a-kind) without any new components. Quote-to-Order & Configur-to-order. The logic (figuratively “grammar rules” of “translation”) is expressed in constraints, inclusion/exclusion rules, and more recently even stored as relationships within a component cluster (“pool”) in a noSQL database like for example, Graph. On the product & product-data side, this implies quite a degree of architecture and modular design-to-configure.

If you’re looking for an insightful update on applied analytics, AI, and ML in cloud ERP, especially for automotive and manufacturing, make sure to read this Forbes article by Louis Columbus from July 2018.

Component Configuration
This is the simpler case where the customer knows which components in which configurations match the requirements (functional and nonfunctional). The customer has enough application-and-component knowledge to make a good “translation” upfront, from a wishlist to product-data compatible, along the lines of a Bill of materials. The configurator compares similar possible configurations, and also, checks that applicable rules and constraints are met; for example, doors must open and shut smoothly even when the selected interior extras are in place, or in SW, latency limits must be met even with all necessary firewalls in place.
Especially in the software realm, this tends to underline structure.  

Functional Configuration
This is the challenging case where it’s up to the configurator and salesperson to figure out how the customer’s wishlist (of both FR and NFR) maps onto components, parameters, and particular configurations. Here, the configurator contains both domain knowledge and application-and-component knowledge necessary for a sufficient translation. Knowledge-based configurators are quite good in this within well-defined domains, not least in manufacturing industries. Today, BI and CI (Customer Insight) also enable configurators to estimate customer preferences, so that they can suggest components more accurately.

Especially in the software realm, this tends to underline behavior and functional requirements (from user stories, use cases, features, etc.)

           

Scania Trucks & Buses has a wealth of experience in product configuration. Image source:  Scania Annual and Sustainability Report 2015.
  
Machine Learning
Sometimes, it’s profitable, as a first choice, to “replay” configurations from recent similar orders (those with good margins and customer ratings), using simpler ML technologies such as Case Based Reasoning. If none of the orders fits, then we’ve the current tradeoff between on one hand, ML from order statistics to fine-tune the configurator logic, and on the other hand, auditability, comprehensibility, predictability, traceability, V&V.

A hybrid approach is ML (from past orders, plus corresponding lifecycle-history data) to fine-tune the rules and constraints of the configurator, making them accurate. That is, rules are still represented transparently, as rules, although ML gradually makes their conditionals smarter. Even in the “replay” order data, ML can improve classification of past orders into categories, to efficiently match particular customers’ wishlists.

Sub-symbolic “opaque” logic from deep learning will cover more tasks than this, but we’ll still need an add-on that will transform it “back” to something humans find transparent enough; visualization tools for decision trees or Graph databases are widely available, including open source (for a picture, see this post on noSQL and Panama Papers). Configurator logic and key PDM data are knowledge assets worth secrecy, for sure, but also worth thorough control and transparency to authorized roles.         
by Milan Kratochvil

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, and design. You can meet him in the coming months of 2018 at public Architecture courses in English or Swedish (fundamentals T1101, customization and variability T1430) or public Modeling courses (agile T2715, advanced T2716).