This chapter describes an Oracle Configurator project involving many large BOM Models with much explicit and repetitive structure that is best modeled as a single top-level BOM Model containing a deep hierarchy of generic structure and abstractions.
This chapter covers the following topics:
This case study explores redesigning a project consisting of many large BOM Models (such as 90,000), each with a large number of options for selection (such as 150,000). The goal is to fulfill performance and usage expectations in a way best suited to the strengths and characteristics of Oracle Configurator.
This project illustrates the following best practices:
A manufacturer and wholesaler of jewelry offers customers the opportunity to custom configure rings and bracelets. Configuring a ring consists of placing stones with characteristics such as shape, size, type, clarity, quality, into a specified location on the ring. Each ring consists of up to 60 locations. For example, a customer orders a 3-setting ring by configuring a 2mm round ruby at location 1 and 3, and a 3mm square emerald at location 2.
An initial modeling approach might be to have a specific BOM for each ring model. Each ring model contains explicit submodels for each of 60 possible locations. Each Location submodel contains the specifications for the stone placed in that location. Stone specifications are shape, type, and so on. The 60 locations can be arranged in one of many possible settings. So for instance, if a ring is defined with three locations, the locations can be arranged in a line with two bevels flanking a peg. The locations on a 60-location ring could be arranged in many more possible settings. Multiplying the 60 rings containing from 1 to 60 Location submodels by the various possible settings results in 90,000 large, explicit BOM Models with up to 150,000 options in each BOM Model. Many Explicit Ring Models shows an example of such explicit, flat Model structure across many Models.
The graphic Many Explicit Ring Models shows RingModel 1000, RingModel 1001, and RingModel 1800, and shows that 800 RingModels contain repetitive structure.
Each Location has the same kind of configurable characteristics, such as particular stones of specific shapes and sizes. In the individual RingModels, the structure for configuring Locations is repeated over and over again, up to the maximum number of 60 locations. For example, if 100 rings are defined with 3 locations and another 100 rings are defined with 4 locations, then in 200 ring models the submodel structure for Location is repeated 700 times.
The ring configuration can contain the same configuration of a stone in several locations or a stone with different characteristics in different locations.
By defining each possible model explicitly, the manufacturer can maintain and sell each model independently of all the other models. This includes sourcing items to separate organizations and preserving existing routings.
By not defining abstractions, the manufacturer does not have to create a large number of rules to capture the large number of valid combinations because each model identifies explicit options.
A design consisting of 90,000 individual Models, each representing a unique combination, does not leverage the power of Oracle Configurator and causes the following:
Performance problems when importing 90,000 BOM Models into Oracle Configurator Developer
Performance problems at runtime caused by the large number of items (up to 150,000 options per model) that must be instantiated
Costly maintenance of 90,000 explicit Models with repetitive structure of many similar items across many of the models
Costly memory usage during preload, initialization, and UI screen display
Scalability issues as the business expands to more models and more options within those models
The runtime performance issues at a minimum are prohibitive.
The suggested modeling approach avoids the problems presented in A Deficient Modeling Approach and applies numerous best practices described in Best Practices. Rather than define separate explicit models repeatedly for each possible ring, a well-designed implementation defines the duplicated structure by references and abstractions, using optional instantiation to optimize performance.
This case involves several separate models that represent unique rings. However, the ring models contain a large amount of similar structure, such as settings and locations for mountings on the rings.
To leverage the advantages of deep hierarchy and optional instantiation, you need to create abstractions of the structure that is similar across all ring models, as follows:
Combine the separate models into a single top-level model for configuring rings. RingModel_1001 through RingModel_1800 in Many Explicit Ring Models become an abstract model called Ring Model in Top-level Ring Model with Abstractions. Instead of searching from a long list of rings with many pre-defined characteristics in RingModel_1001 through RingModel_1800, the end-user starts by selecting the characteristics of an undefined ring. The undefined ring is represented by Ring Model and the characteristics are the settings and the stones.
This step applies the best practice:
Creating a single top-level Ring Model containing the settings structure, initially results in one huge, flat BOM Option Class containing all possible settings, of which only one will be selected. Not only are all settings loaded when the top-level Ring Model is loaded, but the end user is faced with selecting a setting from this very large list of options.
To help end users see only those settings options that are relevant to their configuration, organize settings into groups by some criterion such as popularity or the ring’s intended function. A Settings Model contains not all possible settings but BOM Option Classes of related or grouped settings.
Each group of settings is a BOM Option Class containing only those options that belong in that group. Ideally, a specific Settings option should not appear in more than one group.
Create a Settings Model that contains all the Setting Group BOM Option Classes.
This step applies the best practices:
To involve only that group of settings in the configuration that contains relevant settings, change the Settings Group BOM Option Classes into BOM Models and make them optionally instantiable, which means the value of Instance Minimum is 0, Maximum is 1. See Top-level Ring Model with Abstractions.
This step applies the best practice:
In the top-level Ring Model, you can significantly decrease the amount of repetitive structure by defining an ATO model for the various Stone Types, each containing BOM Option Classes for the configurable characteristics of the Stone such as size and quality.
This step applies the best practice:
To specify the location where the Stone will be placed, create a Location Option Feature for the Stone Model. The Location List of Options contains the maximum number of Locations allowed for any ring. Making Location an attribute of the Stone Model rather than an Item in the Ring Model is appropriate because the Stone is configurable and orderable, not the Location.
This step applies the best practice described in:
In the Stone Model, refine your design further by creating a Stone Type BOM Model containing each stone type (Diamond, Ruby, and so one) as a separate Model that is optionally instantiable. Each Model in the Stone Type BOM Model contains BOM Option Classes of the configurable characteristics of that stone type, such as shape and size.
This applies the following best practices:
The graphic Top-level Ring Model with Abstractions shows the Ring Model that represents an abstraction of RingModel 1000 to 1800.
Top-level Ring Model with Abstractions
After completing the steps in the previous section (Applying Best Practices to Your Model Structure), continue with the following steps:
To allow end users to select only the Locations relevant to their ring configurations, write rules that disallow selecting Locations that are not allowed for a particular Setting. For example, when the end user has selected a 3-location setting, only 3 Locations should be selectable.
To further enhance usability, define a display condition so only valid Locations are displayed in the UI.
This applies the best practice:
You can also write rules to ensure that each required Location for the selected Setting is selected and that, as the end user configures the Stones for a ring, only those Locations remain available for selection that have not yet been selected.
In the Order Management Sales Order Pad, the end user selects the top-level Ring Model and clicks the Configurator button to start configuring a ring. At start up, no Settings or Stone Models are instantiated. In the Oracle Configurator UI, the end user selects a Settings Group. For example, the end user picks a 3-setting ring. The end user must then configure between one and three Stones for the 3 Locations of the 3-setting ring. The first instance of the Stone Model allows the end user to configure the Stone Type and select from the three available Locations. If the end users picks all three Locations, the configuration is complete and the same Stone configuration will be set in each of the three locations. If not all three Locations are selected, the end user adds additional instances of the Stone Model, configures them and selects remaining available Locations until the ring is fully configured.
The diagram in End User Flow for Configuring a Ring Model shows a typical end-user flow.
The graphic End User Flow for Configuring a Ring Modelis an end-user flow chart for ordering the Ring Model. The end user picks a setting from the Settings submodel and rules select the corresponding number of Locations. The end user then creates an instance of a Stone and configures its characteristics. Finally, the end user completes the Stone configuration by selecting a location for that Stone. These tasks repeat for all locations required by the selected Setting.
End User Flow for Configuring a Ring Model
Creating deeper hierarchy and abstractions may require greater designing effort and more rule definitions than an explicit design approach.
A single BOM Model can be sourced to only one organization.
Downstream ERP applications may require additional setup for option-dependent routings or using configuration attributes. Configuration attributes are explained in Oracle Configurator Methodologies.
Comparing this approach to the deficient one presented in A Deficient Modeling Approach, a single top-level BOM Model with structure that is only instantiated as needed provides the following advantages:
Importing a single BOM Model with abstractions is significantly faster than importing 90,000 large BOM Models with explicit, repetitive structure
Instantiating only the substructures required by the current configuration is significantly faster at runtime than instantiating all items
Maintaining a single top-level BOM Model with abstractions is quicker, more flexible to change, and less prone to error than maintaining 90,000 explicit models with repetitive structure of many similar items across many of the models
Preloading, initializing, and displaying the UI screens for a single BOM Model with optionally instantiated items uses significantly less memory than the same operations for 90,000 explicit models
Scaling the single top-level BOM Model with abstractions to accommodate exponentially more items as the business grows does not significantly affect the performance baseline