92
Engineering Systems Integration
Model and Representation Domain
1. Model representations (i.e., “show meaning”) take into account the
need to convey the concepts and procedures that were conjured and
worked out to give to others. But until the ideas and activities are
analyzed and evaluated, recorded and documented, and referenced
and controlled, concepts remain concepts, and ideas for work remain
just that, ideas.
2. Model representations (i.e., “support meaning”) take into account the
uncertainty that remains after the documents have been read and
more questions remain. Were it possible to write all that is required
for everyone to understand and acquire the information they need to
accumulate appropriate knowledge, there would be no need for “sup
port meaning.” But only a fortunate, few people take away the mean
ings from only corporeal, material presentations. Representations of
functions, or objects, of user behaviors, and of processes provide the
paradigm for systems thinking, systems engineering, and systems
integration. But the paradigm for products and services is different.
Theirs is the interactions with all else in their operational environ
ments; in other words all but the previous list. By example, represen
tations of a function or object are the product or service. However, the
product or service should not be thought of as its representations,
rather it should be thought of in its environment and contexts as it
interacts with all else. This is neither a mission nor application-centric
view nor a data-centric view. It is not focused on its internal architec
ture or its user’s intentions. “Support meaning” is the view of interop
erability at the highest level of abstraction. Model representation
“support meaning” is the understanding of operations from the view
point of “others.” Model representation “support meaning” is the ulti
mate determinant for integrative success. Did the product or service
do what it was supposed to do? If yes, success. Every stakeholder did
the job intended—system designers adequately captured require
ments; system architects adequately provided what was need when
and where it was needed; developers overcame the adversities of
project foibles and engineered reliable objects; system integrators
produced value without pretense; systems engineers thought appro
priately in systems; and users made the right decisions. Support
meaning is the physical realizations on which success is built.
3. Model representations (i.e., “defend meaning”) take into account a
broad range of subjective issues that trump all things thought.
Within the province of a project, people working with people often
approach their use of time in different ways, ways that are sometimes
counterproductive to efficient execution of work tasks. Having
Engineering Systems Integration
Model and Representation Domain
1. Model representations (i.e., “show meaning”) take into account the
need to convey the concepts and procedures that were conjured and
worked out to give to others. But until the ideas and activities are
analyzed and evaluated, recorded and documented, and referenced
and controlled, concepts remain concepts, and ideas for work remain
just that, ideas.
2. Model representations (i.e., “support meaning”) take into account the
uncertainty that remains after the documents have been read and
more questions remain. Were it possible to write all that is required
for everyone to understand and acquire the information they need to
accumulate appropriate knowledge, there would be no need for “sup
port meaning.” But only a fortunate, few people take away the mean
ings from only corporeal, material presentations. Representations of
functions, or objects, of user behaviors, and of processes provide the
paradigm for systems thinking, systems engineering, and systems
integration. But the paradigm for products and services is different.
Theirs is the interactions with all else in their operational environ
ments; in other words all but the previous list. By example, represen
tations of a function or object are the product or service. However, the
product or service should not be thought of as its representations,
rather it should be thought of in its environment and contexts as it
interacts with all else. This is neither a mission nor application-centric
view nor a data-centric view. It is not focused on its internal architec
ture or its user’s intentions. “Support meaning” is the view of interop
erability at the highest level of abstraction. Model representation
“support meaning” is the understanding of operations from the view
point of “others.” Model representation “support meaning” is the ulti
mate determinant for integrative success. Did the product or service
do what it was supposed to do? If yes, success. Every stakeholder did
the job intended—system designers adequately captured require
ments; system architects adequately provided what was need when
and where it was needed; developers overcame the adversities of
project foibles and engineered reliable objects; system integrators
produced value without pretense; systems engineers thought appro
priately in systems; and users made the right decisions. Support
meaning is the physical realizations on which success is built.
3. Model representations (i.e., “defend meaning”) take into account a
broad range of subjective issues that trump all things thought.
Within the province of a project, people working with people often
approach their use of time in different ways, ways that are sometimes
counterproductive to efficient execution of work tasks. Having