18
Engineering Systems Integration
Third, the physical, functional, and semantic structures of the architecture
need to be identified and included as an integral part of systems integration.
The semantic structures (i.e., data model (Feng and Yang 1994)) should reveal
the perspective of the user within the system (or system of systems) architecture to recognize and facilitate an appreciation for the utility of the data that
crosses the interfaces between system objects (Fritz 2006). The meaning of
the data (distinct from the information that is transmitted) is an important
aspect of providing the user with a mapping of knowledge to system physical and system functional domains.* ,†
Fourth, all the mappings of functions to physical entities, semantics to
functions, and user behaviors to functions support the integration activities
through various views of the architecture. Architecture is the venue for connectivity, coupling, and cohesion to be explained in terms of the requirements
that the product or service must be operative. Architecture is the venue for
representing the key stakeholder needs and requirements as modified by
their values, preferences, and desires. System integration depends on architecture, without which system integration cannot succeed.
Fifth, integration can be seen as a rationalization of the functions of the
product or service and its operational use. Once the product or service is put
into operation, the issues relating to integration change to process integration. Since the use of a product carries with it its own history of events, processes will evolve to accommodate those events. Existing operations are
changed by the architecture of new products or services. When architecting
a system, the difficulties in creating a common set of parameters and relations to describe the architecture are compounded by interpreting the divergence of the operational situation and the objectives when the product or
service is put into use. Combining this divergence with organizational
changes, new objectives that may result in new products and services, and
the missing common working processes, transferring architectural knowledge from an old or legacy system to a new system may be problematic for
the user and the associated interactions with the product or service in the
user’s environment and enterprise. Specifically, the integration of knowledge
from the legacy operations to the new operations are skewed by the new
product’s or service’s architecture. The ownership and interpretation of
information from the newly operational system become an issue for the
design and integration level of the enterprise data information system.
Integration must take place in multiple domains at multiple levels to complete the integration of a new product or service into the user’s enterprise. At
* The term information is used in the sense of data with a context. When information is combined with a model for relating the implications of scaling to a set of defined metrics and
interpreting the data within a context that is representative of logic and reason, we have
knowledge. The word information is used widely in this book to refer to data, information,
and knowledge.
† The physical and functional domains are also an integral part of the product or service
architecture.
Engineering Systems Integration
Third, the physical, functional, and semantic structures of the architecture
need to be identified and included as an integral part of systems integration.
The semantic structures (i.e., data model (Feng and Yang 1994)) should reveal
the perspective of the user within the system (or system of systems) architecture to recognize and facilitate an appreciation for the utility of the data that
crosses the interfaces between system objects (Fritz 2006). The meaning of
the data (distinct from the information that is transmitted) is an important
aspect of providing the user with a mapping of knowledge to system physical and system functional domains.* ,†
Fourth, all the mappings of functions to physical entities, semantics to
functions, and user behaviors to functions support the integration activities
through various views of the architecture. Architecture is the venue for connectivity, coupling, and cohesion to be explained in terms of the requirements
that the product or service must be operative. Architecture is the venue for
representing the key stakeholder needs and requirements as modified by
their values, preferences, and desires. System integration depends on architecture, without which system integration cannot succeed.
Fifth, integration can be seen as a rationalization of the functions of the
product or service and its operational use. Once the product or service is put
into operation, the issues relating to integration change to process integration. Since the use of a product carries with it its own history of events, processes will evolve to accommodate those events. Existing operations are
changed by the architecture of new products or services. When architecting
a system, the difficulties in creating a common set of parameters and relations to describe the architecture are compounded by interpreting the divergence of the operational situation and the objectives when the product or
service is put into use. Combining this divergence with organizational
changes, new objectives that may result in new products and services, and
the missing common working processes, transferring architectural knowledge from an old or legacy system to a new system may be problematic for
the user and the associated interactions with the product or service in the
user’s environment and enterprise. Specifically, the integration of knowledge
from the legacy operations to the new operations are skewed by the new
product’s or service’s architecture. The ownership and interpretation of
information from the newly operational system become an issue for the
design and integration level of the enterprise data information system.
Integration must take place in multiple domains at multiple levels to complete the integration of a new product or service into the user’s enterprise. At
* The term information is used in the sense of data with a context. When information is combined with a model for relating the implications of scaling to a set of defined metrics and
interpreting the data within a context that is representative of logic and reason, we have
knowledge. The word information is used widely in this book to refer to data, information,
and knowledge.
† The physical and functional domains are also an integral part of the product or service
architecture.