198
Engineering Systems Integration
and traits of physical objects, functions and their induced behaviors would
seem essential complements to the roles of the user. That view is suggestive
of the functions as being both part of the decision-making processes of the
users and the corporate enactments with which the objects are employed to
gain access to the desired performances. These behaviors are both formative
when anticipating the use of an object and summative when actually using
the objects. For integration, the functional boundaries with the users are not
tested to any extent as part of the systems engineering activities. Some
degree of consideration is given to the human systems integration concept.
However, full implementation in an operational environment has been traditionally generally left to the user. That is changing. As an example, the role
of the acquirer (i.e., the customer) is moving from that of the buyer who takes
delivery to that of a participant in the decision-making processes of the project. The customer has begun to identify their ownership of “trade-spaces.”
Taking on this role of an active participant will precipitate changes in the
integration strategy, the extent of testing and integration, and the purview of
development. Traditional development may extend in the “after-sale”
environment to bring about integration of processes. The result might be to
better target interoperability requirements, more focused integration needs,
and alignment of product and service architectures with that of the operational environment, typically a system of systems environment.
Systems and Integration
There are five necessary and sufficient conditions for integrating to achieve a
proto-system (whether natural or human-built). They are the requisite number of objects, the kind of objects, the density of objects in a region of interaction, the adequacy of the EMMI in terms of rate (average EMMI for a period
of time), and the specific characteristics of the EMMI. The factors that drive
objects and that are found causal can be mixed to achieve various levels of
systemness. The factors that are significant are object, boundary, function,
property, trait, attribute, output, self-reliance, control, and performance. The
duration of lifetime or stability of systemness is determined by the boundary
conditions and variances about the performances of the functions. Within
these categories of factors we find emergence (trait) and trust (self-reliance).
Table 4.1 compares the types of systems with these factors. The systems listed
are NotaSystem, ProtaSystem, System, and System of Systems. These system
types are summarized by a one- or two-word characterization of the type.
Systems have properties that are different from those of their constituent
objects. Systems show emergence related to the properties of their objects
and in aggregate reveal themselves through system properties. This type of
emergence is different from that of interacting objects, which is reversible.
Engineering Systems Integration
and traits of physical objects, functions and their induced behaviors would
seem essential complements to the roles of the user. That view is suggestive
of the functions as being both part of the decision-making processes of the
users and the corporate enactments with which the objects are employed to
gain access to the desired performances. These behaviors are both formative
when anticipating the use of an object and summative when actually using
the objects. For integration, the functional boundaries with the users are not
tested to any extent as part of the systems engineering activities. Some
degree of consideration is given to the human systems integration concept.
However, full implementation in an operational environment has been traditionally generally left to the user. That is changing. As an example, the role
of the acquirer (i.e., the customer) is moving from that of the buyer who takes
delivery to that of a participant in the decision-making processes of the project. The customer has begun to identify their ownership of “trade-spaces.”
Taking on this role of an active participant will precipitate changes in the
integration strategy, the extent of testing and integration, and the purview of
development. Traditional development may extend in the “after-sale”
environment to bring about integration of processes. The result might be to
better target interoperability requirements, more focused integration needs,
and alignment of product and service architectures with that of the operational environment, typically a system of systems environment.
Systems and Integration
There are five necessary and sufficient conditions for integrating to achieve a
proto-system (whether natural or human-built). They are the requisite number of objects, the kind of objects, the density of objects in a region of interaction, the adequacy of the EMMI in terms of rate (average EMMI for a period
of time), and the specific characteristics of the EMMI. The factors that drive
objects and that are found causal can be mixed to achieve various levels of
systemness. The factors that are significant are object, boundary, function,
property, trait, attribute, output, self-reliance, control, and performance. The
duration of lifetime or stability of systemness is determined by the boundary
conditions and variances about the performances of the functions. Within
these categories of factors we find emergence (trait) and trust (self-reliance).
Table 4.1 compares the types of systems with these factors. The systems listed
are NotaSystem, ProtaSystem, System, and System of Systems. These system
types are summarized by a one- or two-word characterization of the type.
Systems have properties that are different from those of their constituent
objects. Systems show emergence related to the properties of their objects
and in aggregate reveal themselves through system properties. This type of
emergence is different from that of interacting objects, which is reversible.