|
Conventional wisdom in systems design works the following way:
1. List all factors that affect the behavior or performance of a system.
2. Identify the factors which are the most "significant" through data analysis that typically involves some form of main effects and interaction analysis.
3. Move the system performance in the desired direction by controlling these so-called significant factors.
The questions of interest to management are typically "if I change input A by 30%, by how much does my system output change by?" Of course, some due respect is paid to factor interactions which acknowledge that changing A by 30% usually requires changing B also by, say 10%. As long as the main effect due to input A is "significant" and there are not "too many" other interactions, everyone is happy with the design direction.
Let us take an everyday but simplistic example: the taste of your morning coffee. Lets say this depends on water temperature, coffee flavor, amount of sugar and stirring action (quite reasonable, isn’t it?). If you add too much sugar but fail to stir, the taste is markedly different from adding sugar and stirring. Hence sugar and stirring are “interactions”, while the amount of sugar is the “main effect”. This paradigm works fine when the effects of variation are not too pronounced. Water temperatures from most coffee makers don’t vary significantly; neither does the flavor of coffee or sweetness of a spoon of sugar. In any case human taste buds may even not be able to distinguish between 75 degrees and 80 degrees or between the sweetness of 3 grams versus 5 grams of sugar. We can thus evolve a “design heuristic” for good coffee: heat water to 80 degrees, use 2 spoons of coffee and 5 grams of sugar and stir. Voila!
Thus the paradigm works for systems which have a few parameters, not sensitive to variability (noise) and do not require a very high data granularity (80 degrees is more or less equal to 75 degrees). In other words, systems of low complexity!
The problem arises when this type of design logic is applied to systems that depend on a large number of parameters, subject to extreme variations or noise and are highly sensitive to data granularity. Take an automobile crash for example: the objective of the design is to minimize the injury to occupants when a crash happens. Designs are subject to several constraints (weight, cost, and manufacturability to name a few). Injury mechanisms are affected by too many factors: airbag shape, airbag stiffness, how soon after the crash the airbags are deployed, vehicular decelerations, pitching and yawing, seat motions, dash intrusions, whether an occupant is wearing a belt or not, belt stiffness, glove box material, door trim material, door strength, angle of impact, velocity of impact, size of the occupant, how close the occupant is sitting in relation to the front of the car, so on and so on. On top of this every one of these parameters are subject to variability. The variability can come from the material structure, manufacturing process, or test conditions. In other words this is a system with high complexity!
In this situation asking questions such as “if I reshape my airbag, can I allow the vehicle pitching to increase by 30% and still meet my injury targets?” is not only impossible to answer, but simply the wrong question to ask! For one, identification of a few “significant” factors is virtually impossible in this case (a small variation in any one of the factors can affect results in often unpredictable ways). For another, tightly controlled experiments are simply too unrealistic to achieve. Still further, while redesigning the airbag may help overcoming one type of injury mechanism, the vehicle pitching creates failure by inducing a totally different type of injury mechanism. So what is the right question to ask?
Management focus should be on balancing all the design parameters to yield an acceptable solution. In other words select the combination of design parameters that yield a feasible solution for every possible scenario rather than trying to minimize (or maximize) the design for one particular scenario. This is the challenge in the design of high complexity systems. There are no big hitters in this game. No home runs. Only singles. What is needed is a tool that can identify designs which minimize complexity, not optimize performance. Today, there is such a tool. Try OntoSpace for starters!
|
