Traditional product configurators feature large databases, configuration logic trees, and an expensive change control process. A less common approach is to create Virtual Product models, but that’s the approach we prefer to take at The Weidt Group. Virtual Product models are not mere graphical models, but are instead behavioral models that can stand in as functional proxies of the real products themselves inside an application. Here are some of the compelling advantages to Virtual Product models.
Virtual Products know what they can be, and can become anything that can be manufactured and shipped. They manifest the products composition, geometry, and actual rules of manufacturability. And because Virtual Products are models, they can also provide calculated or derived data that is impossible to reference empirically, such as derived weight, shipped size, and product performance results calculated for a specified context. Such information can be supplied even if the configured product is of a custom size or complex configuration.
This approach has other benefits over ordinary product configurators. Empirical data is useful when it is externally interpreted, but interpretation logic is rarely reusable for other purposes. Virtual Products, on the other hand, manifest configuration logic, derived data calculations, user interaction support, and on-the-fly generation of visualizations and other data, all within a self-contained and reusable “model”.
Whether you’re talking about a design application, quoting system, order capture system, or automated manufacturing system, at the heart of nearly every product based software application lies a configuration system. The best example of the reusability of a Virtual Product model is the Andersen Windows Virtual Product Model used by three different programs. The Weidt Group created three different interfaces to the same engine when Andersen Windows asked us to create Window Studio, WindowSymbols.com, and the WindowCentrics Wall Planner. In all three cases, the program and its graphical user interface know nothing about specific Andersen Windows products. Instead, they know how to “talk” to the Andersen Windows Virtual Product Modeling engine. This means that as product changes and updates are made to the Virtual Products, changes are not typically required to the three application codebases.
So, with Virtual Product models of Andersen’s products as a super-configurator, Andersen was able to quickly leverage the models’ utility for other product based applications.