15
Importance of Integration
Rules of thumb (i.e., “know what is best”) span a shared view of the nexus of
goal-driven technology developments (Burns and Machado 2007) and social
interactions. These rules of thumb include: small groups can be managed
easier than large groups; single points of contact prevent miscommunications (e.g., is easier to deal with one supervisor rather than two supervisors);
communications is vitally important (both as an indicator of collaboration
and the structure in which the communication is provided); and do not overor underdelegate authority and responsibility. Rules of dumb present a different image of the social organization as these rules sometimes reflect or
embody “project legend”—the organizational culture, social interactions,
and interpretations of policies and rules of behavior. Rules of dumb (i.e.,
“hope for the best”) include patterns of behaviors that are readily detectable
with minimal effort on the part of management. These rules of dumb include
not informing management when falling behind in progress toward an
objective (attempting to hide a missed deadline), and delivering partially
completed or inadequately completed work (expecting to continue development during rework cycles). In essence, rule-driven execution of work
requires inductive reasoning to keep abreast of both systems engineering
work and systems integration work. In general, rules are helpful in keeping
track of models that represent reality. But in keeping with those models,
their accuracy is questionable in any specific instance, for example, “how
close the budget or schedule is to the actuals.” Therefore, inductive reasoning more accurately captures the tenor of work by generalizing approaches,
posing and investigating ideas, and collecting evidence that suggests the
dynamics of interplay between social and physical processes, rather than
mere guesswork based on urban or office rules (Haas 1992).
Principle 4: The Principle of Limitation
Integration is only as good as architecture captures stakeholder requirements.
Not all architects have the presumed advantage of preparing an optimum
architecture based on the inputs of key stakeholder and an expert system
designer (or team* of designers). Some architects must work with very little
information or sift through conflicting information. And not all system integration efforts benefit from the work that goes into the system design or the
system architecture. However, in both instances, the architecture remains a
key ingredient for successful integration. The other key ingredient for integration is a concept of operations. The concept of operations and the system
design imbue the architecture with its primary emphasis as represented by
* A team is defined as members of an organization who have only common interests, where
“an organization is a group of people whose actions (decisions) agree with certain rules that
further their common interests” (Marschak and Radner 1972).
Importance of Integration
Rules of thumb (i.e., “know what is best”) span a shared view of the nexus of
goal-driven technology developments (Burns and Machado 2007) and social
interactions. These rules of thumb include: small groups can be managed
easier than large groups; single points of contact prevent miscommunications (e.g., is easier to deal with one supervisor rather than two supervisors);
communications is vitally important (both as an indicator of collaboration
and the structure in which the communication is provided); and do not overor underdelegate authority and responsibility. Rules of dumb present a different image of the social organization as these rules sometimes reflect or
embody “project legend”—the organizational culture, social interactions,
and interpretations of policies and rules of behavior. Rules of dumb (i.e.,
“hope for the best”) include patterns of behaviors that are readily detectable
with minimal effort on the part of management. These rules of dumb include
not informing management when falling behind in progress toward an
objective (attempting to hide a missed deadline), and delivering partially
completed or inadequately completed work (expecting to continue development during rework cycles). In essence, rule-driven execution of work
requires inductive reasoning to keep abreast of both systems engineering
work and systems integration work. In general, rules are helpful in keeping
track of models that represent reality. But in keeping with those models,
their accuracy is questionable in any specific instance, for example, “how
close the budget or schedule is to the actuals.” Therefore, inductive reasoning more accurately captures the tenor of work by generalizing approaches,
posing and investigating ideas, and collecting evidence that suggests the
dynamics of interplay between social and physical processes, rather than
mere guesswork based on urban or office rules (Haas 1992).
Principle 4: The Principle of Limitation
Integration is only as good as architecture captures stakeholder requirements.
Not all architects have the presumed advantage of preparing an optimum
architecture based on the inputs of key stakeholder and an expert system
designer (or team* of designers). Some architects must work with very little
information or sift through conflicting information. And not all system integration efforts benefit from the work that goes into the system design or the
system architecture. However, in both instances, the architecture remains a
key ingredient for successful integration. The other key ingredient for integration is a concept of operations. The concept of operations and the system
design imbue the architecture with its primary emphasis as represented by
* A team is defined as members of an organization who have only common interests, where
“an organization is a group of people whose actions (decisions) agree with certain rules that
further their common interests” (Marschak and Radner 1972).