Heping Dai, OperSolution, Inc. USA
Essentially, the Configure-To-Order is a process allowing users to customize an industry product in such a way that the product will have a specific set of selected features as opposed to entire feature set. Use of the CTO process will bring manufacturers a few important business benefits, such as, enhanced customer relationship, improved flexibility of product sales, and increased sales revenues. Therefore, it has become one of processes that many enterprises has been investigating and implementing.
It is well known that the core component of the CTO process is a configurator, which is basically an expert system supporting an OO modeling methodology behind. In theory, any product or system, no matter how complex it is, can be modeled by using an OO modeling methodology in a commercially available configurator. It seems like the CTO process is so simple and straightforward. Unfortunately, like many other processes, the configuration process of an industry product or system in practice is not as easy as simply to build an OO model in a configurator. Among many reasons, the most fundamental one is that the product to be configured in industry is of certain complexity. Some of typical reasons for causing the complexity are:
- The product related rules and facts from manufacture, which must follow in order to make the product usable
- Customer specific requirements such as delta pricing, and stateful or stateless configuration process
- Business requirements such as customized bundling, and product offering
- Environment restrictions, such as existing material structures, world-wide offering, and internal ERP systems.
In the OO modeling world, the complexity of such a product is often proportionally translated into a tree like hierarchy structure with the number of nested levels, the number of nodes, and the number of rules and facts defined in the configurator. Depending upon the number of layers, nodes, and correlations among the nodes, such a tree hierarchy structure can be considered as a Large-Scale (LS) system, which is basically a tree containing a large number of nested levels and nodes.
Now, the challenge is, for the given LS system, how to build a configuration process with reasonable capabilities for configuration as well as standard implementation constraints in industry, such as acceptable performance, and 24x7 availablility.
Based on the decoupling and decentralization principles of a LS system, this article attempts to conceptually discuss one hybrid modeling approach from not only the OO, but also the performance point of views. At this moment, due to the time constraint, no actual comparison results are provided to illustrate the advantages of the proposed method. Rather, both centralized and decentralized approaches will be described from the algorithm point of view.
Centralized vs. Decentralized
One of the very important steps in the CTO process is for modelers to build a proper model for a product with consideration of product menus, and various requirements. Often, the overview of such a product in the OO modeling methodology can be given in the class hierarchy diagram, which is basically one type of tree-like architectures. As shown in Figure 1, it usually starts with a single node as a root node or parent node. The child nodes of the root node may take a couple of different forms: extension and containment. And each of the child nodes can have it's own child nodes, and so on.
The terms of centralized and decentralized are borrowed from the system and control theory, which are mainly used to handle a system with a large number of variables and complicated interactions. The basic idea of the so-called "centralized approach" for a large-scale system is to consider the entire system as a single system. In this paper, a so-called "centralized approach" for CTO is meant to cover a group of commonly used approaches in practice.
Overall, a centralized approach possesses the following attributes:
- Centralized approach treats the entire system as a single system, or a tree of a single root node. From the knowledge base point of view, the centralized approach is normally translated into a single instance of knowledge base for the identified root instance.
- Although the OO principle is still being used for the centralized approach to implement various product specific rules and interactions underneath the root node and to optimize the overall architecture, not all of the internal states of the entire system are visible or observable. It will take a lot of effort to make all of internal states observable.
- From the user's point of view, the entire system can be viewed as a black box with a set of input and output arguments, which define product specific user interfaces.
On the contrary to the centralized approach, the basic idea of the so-called "decentralized approach" is to dissemble the entire LS system into multiple and relatively independent small systems. From the tree architecture point of view, a single root node tree of a LS system is replaced with multiple root node trees of small-scale systems with additional high-level inter-node communications.
A decentralized approach for a LS system in the CTO process is composed of the following steps.
- Using OO modeling methodology, to create an OO overview of class hierarchy
- Using decentralization principle, to identify a set of relatively independent child nodes from the overall OO class hierarchy diagram as possible root nodes of the sub-systems of the LS system
- Using the principle of separation of concerns, to identify a minimum set of I/O arguments for each of the identified child nodes. Note that it is very important to clearly distinguish an I/O attribute form it's internal states for each of the sub-systems
- To build corresponding knowledge base instances for each of the sub-systems. If the decoupling of the LS system is successful, the knowledge base for each sub-system should be very simple, and contain less rules and constraints. More importantly, each knowledge base instance is independent with each other with or without observability of its internal states to another. This is very different from it's centralized counterpart where the rules or interactions among child nodes are still grouped under a same umbrella
- With clearly defined I/O interfaces among the sub-systems, communications within the entire system will be strictly restricted to high level with minimum amount of interactions and traffic, maximum possibility to enhance the overall performance, and most flexible and modularized architecture
Following the above principle, the class hierarchy diagram may be converted into a decentralized version as shown in Figure 2.
As illustrated in Figure 2, the overall system is properly decoupled into multiple sub-systems. Some of the sub-systems are directly connected to the overall root system, and some of the sub-systems themselves contain other sub-systems.
Compared to the traditional centralized approach, use of the decentralized approach in the system and control theory not only effectively resolves problems with the large-scale systems but also greatly improves overall performance of the system. Due to the large similarity between a normal system and a CTO model, it's expected that use of decentralized approach will primarily enhance the overall performance of the CTO process. In addition, the decentralized approach will bring modularization of CTO models to the next level. Like COM concept, a knowledge base can be viewed an intelligent COM component with standard interfaces. Furthermore, with combinations of web services, the decentralized approach will find itself into a huge and realistic market place. It will make the CTO process one step further close to successful real applications of complicated industry problems.
OperSolution, Inc. USA