The various traditional SD software available today allow a user
to build models from abstract primitives-variables-in a modeling
language. This is a slow process that also
requires deep skills in both the discipline of modeling and in
the subject matter of the problem domain-which is a great drawback
for many potential users of models and prospective model builders
or even SD practitioners. However, the process has its own merits.
For instance, it provides the user with flexibility and a wider
range of capability to explore his modeling ingenuity to the limit.
The purpose of this paper is therefore to present a sketched methodological
process of how modeling could be brought many steps closer to
those with knowledge of problem domains but without the relevant
modeling skills, through the use of components.
Component design is not something new to the field of software
engineering in general. Methods to facilitate software reuse have
become a research field of its own in the last decade or so. And
with the increasing focus on object-oriented design, there is
clearly a great potential for reuse of parts of, or even whole,
existing models. There has been efforts to design and facilitate
the reuse of simple components like procedures, or even classes
in the object-oriented sense. The concept
of component design is, however, new to the SD discipline.
The process of component design begins with knowing what components
to design and how to design them. This is an activity that requires
the skills of correct and relevant problem formulation, system
conceptualisation, as well as conceptual domain knowledge, as
important first steps. Problem formulation is a very important
and difficult task in system analysis. It is the process of expressing
precisely or stating definitely or systematically the causes of
uncertainty surrounding a particular phenomenon (usually a reference
mode). More often than not, it is very difficult to distinguish
between what is a problem and what is a symptom. For instance,
dwindling market shares or profits, high employee turnover, low
productivity are normally referred to as problems rather than
symptoms of some underlying problems. However, both the concepts
of problem formulation and system conceptualisation are not new
to the system dynamics discipline.
Richardson and Pugh (1981) have discussed in great detail a general
approach to identifying a problem and conceptualising a system
in SD. These two activities are not only the first step in model
building, but also probably the most important. Model purpose
and focus on a problem and not a system have also been emphasised
in the problem definition and system conceptualisation phases
of model building (Richardson et al (ibid.), Forrester, 1961).
As a result, the focus and emphasis of this paper is on the requirement
specifications of component definition and design.
The reference case study in this particular project is Cadillac, a product of General Motors. The case was taken from Bernhardt et al (1994) and it is about marketing decision making. The central issue of the case is that of whole marketing strategy, which means it encompasses everything relating to a marketing mix strategy. The process of distilling the critical dynamics of the case study-identifying and formulating the problem as well as conceptualising system (model) components-is based on two concepts: Porter's model of market dynamics and the popular 4Ps of the facets of marketing strategy (Chisnall, 1985).
What is a component? And how does it differ from say generic structures or molecules in SD? In a general sense, a component can be a program procedure or a function. In this context, however, a component is a domain-specific, concept-based object which is part of a larger problem represented in a model structure. It can represent a partial or even complete solution to a problem. It can represent a subsystem, but is not necessarily so. A component is built from a collection of variables and a number of components can then be configured into a model.
A component has two main features-Specification and Implementation. Examples of components are cost-oriented pricing, competitive parity, product branding, etc. In contrast to a generic structure or a molecule in SD, a component is not an abstract structure it is based on a well-known domain concept.
The process of identifying a component is based on the concept
of conceptual clustering, one of a number of modern methods
of explaining how knowledge is represented (Booch, 1994). This
approach focuses attention on the behavior of collaborating objects
(components in this case), hoping that these concepts will capture
one's understanding of the problem domain. Since this approach
is based on dynamic behavior analysis, a component is formed or
built based on groups of variables that when put together exhibit
a behavior expected of the system the concepts represent. A component
is identified based on its purpose and place in the total system.
We achieve this by first identifying what goes on in the system
under study-the objects, operations and relationships that the
domain experts perceive to be important about the domain.
We generate components by first formulating conceptual descriptions
of parts of a complete model of a particular system problem. The
model parts are identified according to the properties relevant
to the problem domain. The most important and critical factor
in creating components is the collaboration between an expert
system dynamicist and domain experts. A domain expert is simply
a user, such as an automobile or oil rig engineer, a nurse or
a doctor in a hospital, a marketing, production or personnel manager
in a manufacturing firm, etc. A domain expert does not to be a
modeler, but should rather be one familiar with all the elements
of a particular problem or even the general problems within his/her
domain. Essentially, he should be speaking the language of his
domain.
The actual design, or rather specification, of the components is based on a top-down approach and the implementation, or configuration into a model is bottom-up. The reason for this is that modeling whole systems from subsystems has been known to lead to some counterintuitive behaviors. (Morecroft, 1985). A better approach will be to conceptualize, or even build, whole systems and pull them apart, as if performing partial model testing, and then test the component parts for their independent suitability with the hope that when the parts are reassembled they can again function as a whole.
When we have identified and designed the components, the next step is to group them into catalogs based on their identified functions or purpose. The user, who is assumed to have adequate knowledge of his subject area, will browse through the component catalogs to search for appropriate components that can be configured into his desired system model. The example in figure 2 below shows how one can, for instance search for a 'Pricing Component' based on the 4Ps of the facets of marketing strategy.
The benefits that be derived from the use of components will include, among others:
Essentially, modeling tools need to be made available to practical business people, politicians, and other professionals, or even business students all of whom do not have enough time to learn today's tools or techniques of modeling. This target market needs to be provided with tools that everyone could use to build SD models, and explore the kinesthetics of the models they build. They could learn to control unintuitive dynamics, they could test future scenarios, they could share visions of the future: everything that can be done today, but as a mainstream business practice instead of a fringe. If we can allow people to construct models without learning modeling, everyone will model. Although they may still lack the knowledge of the theories behind the models they build, but not knowledge of the dynamics the models generate and the insight they provide. The ultimate real winner will eventually be the SD discipline and its community.
Bernhardt, L. K &
C. Kinnear (1994) "Cases in Marketing Management." Richard D. Irwin, Inc. USA.
Booch, G. (1994) "Object-Oriented Analysis and Design-With Applications." The Benjamin/Cummings Publishing company, Inc., Redwood City California, USA.
Chisnall, P. M. (1985) "Strategic Business Marketing." Prentice Hall International (UK)
Ltd.Campus 400, Marylands Avenue, Hemel Hempstead Herforshire, HP2 7EZ.
Forrester, J. W. (1961) "Industrial Dynamics." Productivity Press, Inc. Portland OR, USA.
Morecroft, J. D. W. (1985) "Rationality in the Analysis of Behavioral Simulation Models."
ISDC '97 CD Sponsor 