Class Inheritance won't make you Rich | Configuration Workgroup

You've been wondering about "Class Inheritance." You might have heard that product modeling is a lot like Object-oriented Programming, and you know that in OO Programming you can do all sorts of things with "Classes." Here you'll get an in-depth look into the uses of Class Inheritance in product models in the VC - a gem of an article, spiced up unmistakably, in our favorite Variant Configurator Editor's saucy writing style. Steve Schneider, Aug. 24, 2005

But you should invest in it anyway!

Foreword

If you read CWG Review #1 for 2005, you will remember that there was an article entitled "Restricting Characteristic Value Domains in SAP". Since that article was published, several people have asked the question "Why are the classes assigned as subordinate classes in technique 6, the named best practice?" Other questions ran along the line of "What is a subordinate class?" This article will attempt to not only answer these questions, but describe why, in my opinion, using class inheritance is also a "Best Modeling Practice" for products modeled in SAP.

If you haven't read this article, it can be found by clicking on this link; Restricting Cstic Domains

Please bear in mind, both articles are a direct result of my experiences in the past 7 years at my employer, Steelcase, Inc. with a product model that does NOT have widespread use of these techniques. I have used these techniques and believe in their power, primarily because I've been forced into maintaining our model without them. If you are interested in details on how I feel this has constrained our efforts, feel free to call or email me for more details.

So, having said all that, it's time to start our journey to the center of the SAP Variant Configuration universe, otherwise known as classification. Hopefully, I've written this in a manner that is understandable, yet allows you to smile at (and maybe relate to) my thought processes…

Background

The product model we will discuss in this article is a continuation of the product model introduced in the article "Restricting Characteristic Value Domains in SAP". If you don't have it with you, you'll need a little background.

The products we will use belong to a mythical bicycle company. This company currently has 2 products. A racing bicycle is a product sold to one market while a mountain bicycle is sold to another. The racing bicycle is sold under product number RACER while the mountain bicycle is sold under product number MOUNTAIN.

The Marketing department at this company has already, in their infinite wisdom, created a condition where;

"A racing bicycle may only be sold in Red and Green, and a mountain bicycle may only be sold in Green, Blue, and Black"

This Marketing decision meant that the modeler had to restrict the characteristic domains to only those values appropriate for each product. The product modeler went on a journey through multiple techniques to find the best method to accomplish the Marketing mandate. The modeler decided on the following objects and technique;

COLOR_1 is a restrictable characteristic that contains all possible colors allowed within the company. Red, Green, Blue, and Black are all valid values.
Class COLOR is created with characteristic COLOR_1
Class RACER_1 is created and assigned as a subordinate class to class COLOR
Class RACER_1 is then assigned to material RACER
Class MOUNTAIN_1 is created and assigned as a subordinate class to class COLOR
Class MOUNTAIN_1 is then assigned to material MOUNTAIN
Variant table T_COLORS_RACER is created with characteristic COLOR_1
Allowed values in this table are Red and Green
Variant table T_COLORS_MOUNTAIN is created with characteristic COLOR_1
Allowed values in this table are Green, Blue, and Black
Dependency net S_RACER is created with constraint S_RACER_COLOR. Syntax of this constraint is

OBJECTS:

?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:

TABLE T_RACER (COLOR_1 = SPEC).

INFERENCES:

SPEC.

Dependency net S_RACER is assigned to the configuration profile of material RACER
Dependency net S_MOUNTAIN is created with constraint S_MOUNTAIN_COLOR. Syntax of this constraint is

OBJECTS:

?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:
TABLE T_MOUNTAIN (COLOR_1 = SPEC).

INFERENCES:
SPEC.

Dependency net S_MOUNTAIN is assigned to the configuration profile of material MOUNTAIN

This technique can best be described using the term "Constraint based modeling, utilizing class inheritance". This term is used due to the use of the constraint rules referencing classes that are structured in a hierarchical manner to control what may happen in our model.

In graphic form, the classification of the 2 product models would look as seen in Figure 1.

Why would the modeler have used the subordinate classes Racer_1 and Mountain_1? Surely, there are other methods that could have been used to accomplish the same goal?

Other Possible Techniques

Since we are assuming that we will only use Constraint based modeling to restrict the characteristic domains, there is really only 1 other method for getting the class containing characteristic Color_1 assigned to each material.

Assign class COLOR directly to each product

This would have accomplished the same goal. In fact, some people would state that doing so is more efficient as the 2 subordinate classes (Racer_1 and Mountain_1) would not be required. True statements.

In graphical form, the model would appear as shown in Figure 2

Pretty simple isn't it? Almost makes you want to run out and assign all your classes directly to the material. Trust me, step away from the keyboard and take some deep breaths before you do so.

You see, here comes Marketing again. I'm sure you knew they would be back didn't you?? Guess what? After extensive research (including many parties and receptions, otherwise known as "product introductions"), it has been determined that there is something missing from the bicycle. It seems that the bicycle is difficult to ride without something to sit on. So, Marketing wants to introduce a new element called a SEAT.

Pretty easy to add a seat to the model isn't it? You would think so until Engineering thinks about how it will affect the design. Engineering determines that the Racer needs a thin, streamlined seat while the Mountain needs a wider, sometimes more padded version. While talking to an acquaintance out in Manufacturing, our modeler hears rumors about another version of each bike. Seems that Marketing forgot that people come in different shapes and sizes. Clarification with Marketing does result in a need for something called a handlebar and the ability to offer a different frame style. So, now we need to add the ability to offer different seat, frame and handlebar types.

So, it looks like we are going to need some more characteristics in our model. We will be adding the following characteristics;

SEAT, with values

Racing
Padded Racing
Mountain
Padded Mountain

FRAME, with values

Mens
Womens

HANDLEBAR, with values

Wide
Narrow
Racing

It also appears that we will have to do some more domain restrictions to the characteristics of SEAT and HANDLEBAR. You see, once Marketing heard about the handlebars, they naturally stepped in with the mandate "A Mountain bike may only use the Narrow and Wide handlebars, while a Racing bike may only have the Racing and Narrow handlebars. Oh, yes, the Narrow Handlebars may only be offered with the Racing Seat, not the Padded Racing Seat."

As Product Modelers sometimes do, the bicycle company's modelers discussed the latest great product innovation over a beer (or 6) at the end of the day. During the conversation, some obvious questions come up;

Where to add the new characteristics??
How do we get the most efficient reuse of all relevant objects?
What makes the most sense from a efficient rule design standpoint?
What do we do when Marketing or Engineering decides to offer a new characteristic, but only on 1 type of bicycle?

I'm sure that, in your business, you can think of many other relevant questions to ask based on changes that are made during the design process. Somehow, we need to try and design the more efficient, robust product model possible.

There are at least 3 possible techniques to answer that lofty goal;

1. Add the new characteristics directly into the class COLOR_1

2. Create each characteristic in it's own class and assign each class directly to each material.

3. Design a hierarchy that keeps each characteristic in it's own class and utilizes inheritance to get them to the correct product model

Comparison of Techniques

Technique 1. Add the new characteristics directly into the class COLOR_1 (See Figure 3)

In graphical form, the model would appear as shown in Figure 3

We could add all the characteristics directly into the existing class COLOR_1. It would get the job done and allow us to do something better, like relax with a beer. However, this technique seems to defeat the purpose of having any class naming conventions.

Absolutely!!! Naming conventions are critical in any well-designed product model. They allow object-oriented modeling principles to be utilized to their fullest and also allow the poor people that get stuck maintaining what we design to easily understand it. After all, would you put champagne into a beer bottle??(Ask me about champagne in beer bottles when you see me at the November 2005 CWG conference)

What would happen if (when) Marketing decides to offer a new bicycle that uses almost all the same characteristics? For example, the new product only comes in Black, so no color choices are necessary. This would force a new class, containing only the characteristics of SEAT, FRAME, and HANDLEBAR. This breaks the first rule of object-oriented modeling. Namely, only have the root object in one place, and then reuse that one place wherever necessary. In this case, the root object is, in fact, the characteristic.

Using this technique, every time that a different rule was needed to control characteristic domains, the potential exists that a different class would need to be referenced. This means a different rule would need to be written for each product. For example, lets say that product TRICYCLE is introduced. This product does not require the Handlebar or Frame characteristics. The Color still needs to be restricted to those that are allowed on the Mountain Bike. A new class must be created for use on the Tricycle. A new constraint must be written rather than simply reusing the existing constraint used in the Mountain bike.

Should we care about a naming convention?
This technique also seems to offer some challenges when you think about reuse of objects
OK, are there any challenges with Rule Design using this technique?

Technique 2. Create each characteristic in it's own class and assign each class directly to each material.

In graphical form, the model would appear as shown in Figure 4

This doesn't seem so bad. It does follow that first rule of object-oriented modeling we just talked about. All the characteristics are in their own classes. We can move them about as needed to other product models. The naming conventions are still being followed. So, why wouldn't we do this?

SAP has stated in Variant Configuration training that the more classes assigned directly to a material, the slower the performance in the system. I live with it and can confirm it. Look at Figure 4 and you see a graphical example of why performance is affected. The system has to untangle all of the various assignments to ensure it's getting the correct one each time.

Sooner or later, Marketing will decide to create a new product with exactly the same set of characteristics, but some different restrictions on the domain of characteristic values. How many classes do you want to have to assign?? Remember, I'm lazy and only like to do things once. So, I really only want to do one class assignment..This doesn't seem like that fits the bill, so lets take a peek at something else...

Performance
What about reuse of objects?

Technique 3. Design a hierarchy that utilizes inheritance

In graphical form, the model would appear as shown in Figure 5

This is where each characteristic lives in it's own class, exactly like technique # 2. The single difference is that each class is not assigned to the material. They are all inherited into a subordinate class that, in turn, is assigned to the material.

This method allows SAP to best utilize the internal tables to determine where to start configuration. In this method, the tables (such as AUSP, INOB and KSSK) only need to be scanned once to get the class to object (material) link.

By using a subordinate class that inherits from multiple superior classes, you can assign the subordinate class (one transaction) to the material and get all of the inherited characteristics from all of the superior classes. The ultimate in Lazy modeling maintenance!! Each characteristic still lives in it's single, object-oriented place and get reused over and over again from that one place. It may be used with different domains, depending on the application and inheritance down through different subordinate classes.

Rules are the mechanism that really makes a SAP product model tick. They are like the hops in a good beer (getting a sense of something here?). Rules allow you to define complex relationships between objects, controlling what the user can do without the user having to understand the product.

It's not all that different in this very simple example. Take a more complex, multi level nested material with a large number of related characteristics and I think you will very quickly see the difference.

Lets face it. Whether or not SAP will state it, this is the direction that they are going in the IPC and PME. Sure, the PME will support the non-inheritance models, but one good look at it will quickly show that it works best using inheritance.

There are other products used as modeling tools available (such as the tool from Integral (hey Henk, that should deserve at least a beer for the plug!) that also are designed around inheritance. In some cases, not only are the tools designed around it, they ENFORCE an inheritance model.

As more and more emphasis is placed on configuration, especially over the web, more emphasis will be placed on efficient product models that can be accessed by multiple applications. Object-oriented principles will become more prevalent, not less. We may as well get used to using them.

So, what does this do to performance?
Does this help with reuse of objects?
Alright, what about efficient rule design?
In this manner, all the rules point to each individual class and/or characteristic. Why is this different from technique 2?
Get ready, this is the future.

Observations

Take another look at the rules that were written;

OBJECTS:
?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:
TABLE T_RACER (COLOR_1 = SPEC).

INFERENCES:
SPEC.

OBJECTS:
?A IS_A (300)COLOR WHERE
SPEC = COLOR_1.

RESTRICTIONS:
TABLE T_MOUNTAIN (COLOR_1 = SPEC).

INFERENCES:
SPEC.

Dependency net S_RACER is created with constraint S_RACER_COLOR.

Syntax of this constraint is
Dependency net S_RACER is assigned to the configuration profile of material RACER
Dependency net S_MOUNTAIN is created with constraint S_MOUNTAIN_COLOR.

Syntax of this constraint is

Dependency net S_MOUNTAIN is assigned to the configuration profile of material MOUNTAIN

Notice that the subordinate class is not called out anywhere in the rule. It doesn't have to be. The whole point of object-oriented modeling is to have the rules looking at the same object, even if they do different things to that object!!

Quick thinking readers will note a difference between Figure 1 and Figure 5. You would also be correct.

The big difference between Figure 1 and Figure 5 is that the same subordinate class is used in Figure 5. Why shouldn't it be? The characteristics required in each model are the same. We've shown how the domains of those characteristics can still be restricted independently. Remember that I'm inherently lazy. Obviously, so was the person that thought up object-oriented principles. I'm really glad of that!!

No, I haven't been drinking to much beer, this was done to illustrate a point;

There are multiple methods to creating a class hierarchy. None should be considered on their own merits without first looking at the whole! This is really nothing different than any aspect of product modeling. You should not design your product model unless and until you look at it in a holistic manner. In SAP, or any ERP system using a configurator, what you do in one section of the model is, in fact, going to have an impact somewhere else in the business. The more integrated the software, the larger and faster those impacts are felt by the business.

Now, before you run out and assign all of your superior classes to 1 subordinate class, pause and think about your product model. This very simple example is certainly not like your real-life product. In real life, you need to think about a few more things;

You may have multiple characteristics that are similar. In our model, we may also have different handgrips, horns, and other accessories that are all mounted to the handlebars. Why not group them into 1 subordinate class, then inherit that class down to a second subordinate class that is assigned to the material?

There may be a situation where a component of your higher level product may be sold on it's own. In our case, we sell wheels as independent items so our customers can make their bicycles different. Again, in this case, you would assign all the characteristics related to the wheels to an intermediate subordinate class. That subordinate class could then be assigned to 2 other subordinate classes, one assigned to the bicycle, the other assigned to the wheel material. In this case, you may not want both second level subordinate classes. Depending on your circumstances, you may actually assign the intermediate class to the lower level class and the wheel material sold on it's own.

Grouping similar characteristics
Use on other configurable products
Rule design

Face it, this is the hardest part, but where you get the largest reward. Where you place your characteristic determines how you will write your rule. The fewer number of rules you have, the easier your model will be to maintain. Remember, the ultimate goal is for the architecture of your model to stay the same, while the values utilized in your model change as needed. This type of modeling lends itself to these goals, but can also trap the unwary.

The Bottom Line

In the authors opinion, the best practice for product modeling relative to assignment of classes is;

A well-designed class hierarchy utilizing class inheritance where appropriate

Utilizing class inheritance is one of those things in SAP that has to be seen and used to really be appreciated. Once you begin to use inheritance, you will quickly begin to see how your perception of using constraints and variant tables changes.

I know, you still don't buy it. Reading more won't convince you either. Try it. Get into your development system and change one of your models into a constraint based model, using class inheritance. When you do, keep one thing in mind;

SLOW DOWN

Like anything else in SAP, a taste of something can be misleading. Before you design (or redesign) your product model, you will need to take into consideration the entire breadth and usage of the characteristics, classes, and BOM's. You know, THINK HOLISTICLY!! As you know by now, these items are all intertwined. They are intertwined into more than just configuration also. Think about business reporting and searching for configurable products. Your hierarchy may need to support a solution set AND an individual product. In all cases, the resulting class hierarchy may be very different!

Creation of a poorly designed class hierarchy can be worse than not having a hierarchy. Your hierarchy MUST NOT BE designed with only 1 or 2 of your products in mind. You need to think about how everything in your system will be used together. This is a very difficult task, but I believe it will pay huge dividends in the long run.

Take a deep breath, discuss it with your co workers (a beer or 2 helps), then dig in and see what you can do with it. Feel free to send me your thoughts or comments. Better yet, come on down to Marco Island, FLorida in November 2005. We can discuss it at the CWG conference. You never know, there MAY even be a hands on session designed around this topic...

About the author

Steve Schneider is a Product Data Analyst at Steelcase, Inc., the world's largest manufacturer of office furniture. He has been involved with product configuration since 1993. From 1993 to 1997 he modeled product in the Steelcase developed configurator, and from 1997 to present has modeled in SAP's R/3 system using Variant Configuration. Prior to becoming a Product Data Analyst, he worked for many years in Production and Inventory Control as a user of product data. When not working, he can be found wandering the rural back roads of Michigan on his motorcycle or researching the latest brewpub listings. He will NOT drink and ride though! He can be reached at;

Steve Schneider, VC Editor

(616)-246-4103