This chapter describes the high level flow of starting a project and designing configuration models. The chapter also presents guidelines to help you plan your Oracle Configurator project and determine which design questions you should ask.
For information about planning and starting an Oracle Configurator project, see the Oracle Configurator training available through Oracle University.
This chapter covers the following topics:
A proven, repeatable methodology for designing and creating configuration models includes the following design considerations:
Model structure design
User Interface design
Rule design
Begin by designing the Model structure, which may involve leveraging BOM Model data that already exists in Oracle Bills of Material, and adding guided buying or selling Features and Options.
As you design your Model structure, consider your requirements for the user interface. A runtime UI may be automatically generated in Configurator Developer from your Model structure, and your UI requirements often may drive the structure of your guided buying or selling components. However, the templates that you use to generate UIs in Configurator Developer ultimately provide a great deal of control over the UI's appearance and behavior.
Once you have designed an initial Model structure, apply rules among its elements. Rules typically represent the most complex aspect of your configuration model and should be well thought-out during the design process.
The flow of steps to design a configuration model is often iterative, but by following the suggestions in this Modeling Guide you should be able to reduce the number of iterations during the design process. Planning Guidelines Relevant to Model Design describes a set of guidelines to follow as you plan your implementation and identify what design decisions are necessary.
Caution: Do not use Oracle Configurator to emulate or replace functionality that is missing from other products or processes. For example, using Oracle Configurator to emulate the Configure-To-Order business process because a specific requirement is not addressed in the current release could have undesirable consequences.
This section presents some of the planning guidelines that can help you make appropriate model design decisions in the following areas:
These planning guidelines are intended as a starting point for designing your configuration model. You may need to make additional planning decisions that are specific to your business or Oracle Configurator project.
Note: Even if your implementation does not leverage BOM Models, review the design questions and best practices listed in BOM Model Design or Redesign before beginning your configuration model design.
After reading the following planning guidelines, read through the design questions presented in Starting Your Model Design to help identify best practices that are relevant to your project. For more information, see Best Practices.
The guidelines provided for BOM Model design assume that your Oracle Configurator project is integrated with the Oracle eBusiness Suite.
The BOM is what is configured and ordered. While it needs to be structured for your Enterprise Resource Planning (ERP) process, it also may need to be simplified for end user comprehension and usability during configuration. Even if you believe there is no flexibility for changing your BOM Models, the consequences in implementation effort, maintenance costs, usability issues, and performance may persuade you to make some adjustments. In this case, be aware of the limitations this lack of flexibility imposes and plan your runtime architecture accordingly.
The table below lists some common BOM Model characteristics and specific adjustments that must be made to maintain Oracle Configurator performance and usability.
| BOM Model Design Characteristic | Metric | Recommended Adjustment to Runtime Architecture |
|---|---|---|
| Many BOM Option Classes and BOM Standard Items | Typically, BOM Models with over 10,000 items. | More JVMs More dedicated JVMs Increased (large) JVM heap size Model structure abstraction to hide the BOM from the UI (easier option selection) |
| Large BOM Option Classes | Typically, those containing over 100 BOM Standard Items. | More JVMs More dedicated JVMs Increased (large) JVM heap size Model structure abstraction to hide the BOM from the UI (easier option selection) |
| Multiple BOM Models with similar structure | References to two or more BOM Models that contain only minor differences (few unique items) | Additional memory Additional hardware Increased (large) JVM heap size |
| BOM Option Classes that are repeated in multiple BOM Models | Any duplication of BOM Option Classes, (especially those containing over 100 Standard Items) | Additional memory Additional hardware Increased (large) JVM heap size |
Always begin your Oracle Configurator project by examining the structure of your BOM Models. If your BOM Models exhibit any of the characteristics listed inBOM Model Design and Impact on Runtime Architecture, refer to the design questions listed in Starting Your Model Design to review best practices that may apply to your project.
Another important consideration related to BOM Model design is that the size of the configuration model directly affects the time it takes to load the model and display the UI in a runtime Oracle Configurator. In other words, the bigger the model, the longer the initial load. For this reason, Oracle recommends preloading models so that end users experience better performance throughout the configuration session. For more information on preloading models, see the Oracle Configurator Performance Guide.
The database size of a configuration model is measured in total number of nodes. Appendix A, SQL Queriespresents queries used to find out how many nodes are in your configuration model.
The goal is to streamline your BOM Models so that the resulting configuration models are highly maintainable and scalable as your business grows, with optimal usability and performance at runtime.
Note: Both the name and description of BOM items are imported into Configurator Developer with the BOM Model. If either is used to generate UI captions, make sure they are meaningful to end users.
Be aware that only BOM Standard Items that are defined as optional in Oracle Bills of Material appear in Oracle Configurator; BOM Standard Items that are mandatory are not displayed.
BOM Model redesign may involve changes such as:
Reducing repetitive or similar structure into abstract elements that should be referenced (abstraction)
Changing entity types: For example, changing a commonly used Option Class to a BOM Model.
Eliminating unnecessary items: For example, removing BOM Standard Items from the BOM and converting them to attributes.
These and other BOM Model redesign best practices are discussed in Best Practices.
Note that any changes to the BOM Model may have an impact on downstream operations. Optimal BOM Model design balances the needs of all applications that leverage it. Every item in a BOM is ordered, and either gets manufactured or provisioned. Therefore, any changes to the BOM to improve Oracle Configurator performance may require additional rework to support requirements in other applications, such as Pricing, Order Management, Install Base, Shop Floor Management, and so on.
A single configuration model can support multiple User Interfaces (UIs). Typically, Oracle Configurator Developer is used to automatically generate end-user UIs. Since you may base the UI structure on the Model structure, keep UI considerations and end-user expectations in mind as you design your configuration model. If your expectations for the UI are based on a legacy system, it may be difficult to leverage some of the default features and functionality that is provided "out-of-the-box" by a UI generated in Oracle Configurator Developer. In other words, legacy UI design and behaviors may require you to either extensively customize a generated UI or create a completely custom UI from scratch. Writing Configurator Extensions to implement custom behavior may also be necessary.
Examine and understand how your end users will interact with the configuration UI. The following circumstances are relevant to model design:
Your runtime Oracle Configurator needs to exhibit any of the following behaviors:
UI opens with options already selected
Product complexity hidden from end users by high-level questions or minimal required selections
Your end users need to perform any of the following actions in the UI:
One of the most critical and potentially time-consuming activities in constructing your configuration model is designing and constructing the rules that govern what the end user can select to make a valid configuration. You need to build rules that express relations and behaviors among the Components, Features, Options, BOM Option Classes, and BOM Standard Items of your Model.
The number and complexity of the rules are a factor in determining the size of your configuration model. Independent of whether structure is a factor, fewer than 500 rules is generally a small model, 500 to 2,000 rules is a medium model, and over 2,000 rules is a large model. When working with models containing a large number of rules, performance and usability can be a concern.
It is important to examine and understand all of the rules that define your business or constrain your products before proceeding with your Configurator implementation. You may also want to consider using Configuration Attributes to, for example, insert values that are stored by the host application into the configuration model at the beginning of a configuration session, as the initial values of specified Features. For more information about configuration attributes, see Oracle Configurator Methodologies.
Note: Prototyping a configuration model based on a preliminary and incomplete rule information will likely result in a sub-optimal model, or require additional redesign iterations.
The following circumstances are relevant to model design:
You have over 2,000 rules, or you have rules that exhibit any of the following characteristics:
You use the following types of rules in your configuration model:
Compatibility
Comparison
Defaults
Rules that use the NotTrue operator
You are importing rules from a legacy system
Before importing rules from a legacy system, be sure to carefully analyze them and consider whether they could be more efficiently implemented by creating new rules from scratch in Oracle Configurator Developer. Importing legacy rules directly into Configurator Developer will likely result in less than optimal rules that contain duplicate sub-expressions.
It is important to carefully consider how long your configurable product will be available, plan for how you will maintain it until it is removed from production, and set company expectations accordingly. You should understand the maintenance requirements of your product - such as how often new items will be added, existing items will be modified, and so on - and the impact these tasks will have on your overall business. For example, when the model needs to be updated, will it need to be taken out of production? If so, for how long?
Consider reviewing your business processes to determine if there are areas that can be changed to minimize the impact that configuration model maintenance has on your business, and plan for the kinds of changes that will occur throughout the life cycle of your product.