171
Foundations in Systems Integration
ucts (classes and domains) and the final resultant integrated whole are often
invisible. This observation suggests a strategy for integration.
Making appropriate investments in key resource areas such as information systems, tools to improve efficiency, training and education for the project
team, the customers, and the users* provide substantial paybacks in both
systems engineering and integration. For the specifics of the project, these
concepts extend to increase the likelihood that integration will provide the
highest amount of strategic value through the product or service. Another
investment that pays off is for systems that can be modeled. Model-based
systems engineering offers the allure of describing both the objective and
subjective domains for the objective causalities.
Model-Based Systems Integration
Systems engineering has evolved a more formal approach to integration,
albeit still methodological. The U.S. Department of Commerce, National
Institute of Standards and Technology (NIST) derive a model of integration
for systems engineering starting from a defined systems perspective
(Barkmeyer et al. 2003) that is premised on the interplay of models. At the
most abstract level, integration is a process (in contrast with this book’s careful characterization of integration as a method in which processes play a
dominant role) for bringing parts together to form a whole—in this case a
system. What is meant, termed as “technical integration,” is to ensure
interoperability by turning an integratable component into an interoperable
component. Technical integration is a procedural list of tasks that identify
interface requirements (inputs and outputs) and data entities that when
transferred ensure interoperability between the identified components. The
systems perspective is comprised of models that describe the organizational
structure of resources (the system structure model), the rules for conducting
business operations (the policy models), and the logical, physical structures
of communications (the network models). These three models form a web of
planned interfaces that presumably span the scope of interactions that will
result in integration. For technical integration to succeed, the behaviors of
the components must be completely represented by the models. The difficulty of building all of the known and emergent behaviors into the models is
compounded by the continuing iterations of discovery of what a component
does and is supposed to do, and then coupled with the addition of new
requirements that naturally result from the interactions with stakeholders
during design, architecting, development, and testing, it can completely
undermine the efficacy of the models. On large-scale system integration or
system of systems integration efforts, technical integration is challenged and
has not yet been shown to be effective. As stated in the NIST report, there
must be a consistency between the functional and behavioral characteristics
* Users who become mixed up turn into Suers.
Foundations in Systems Integration
ucts (classes and domains) and the final resultant integrated whole are often
invisible. This observation suggests a strategy for integration.
Making appropriate investments in key resource areas such as information systems, tools to improve efficiency, training and education for the project
team, the customers, and the users* provide substantial paybacks in both
systems engineering and integration. For the specifics of the project, these
concepts extend to increase the likelihood that integration will provide the
highest amount of strategic value through the product or service. Another
investment that pays off is for systems that can be modeled. Model-based
systems engineering offers the allure of describing both the objective and
subjective domains for the objective causalities.
Model-Based Systems Integration
Systems engineering has evolved a more formal approach to integration,
albeit still methodological. The U.S. Department of Commerce, National
Institute of Standards and Technology (NIST) derive a model of integration
for systems engineering starting from a defined systems perspective
(Barkmeyer et al. 2003) that is premised on the interplay of models. At the
most abstract level, integration is a process (in contrast with this book’s careful characterization of integration as a method in which processes play a
dominant role) for bringing parts together to form a whole—in this case a
system. What is meant, termed as “technical integration,” is to ensure
interoperability by turning an integratable component into an interoperable
component. Technical integration is a procedural list of tasks that identify
interface requirements (inputs and outputs) and data entities that when
transferred ensure interoperability between the identified components. The
systems perspective is comprised of models that describe the organizational
structure of resources (the system structure model), the rules for conducting
business operations (the policy models), and the logical, physical structures
of communications (the network models). These three models form a web of
planned interfaces that presumably span the scope of interactions that will
result in integration. For technical integration to succeed, the behaviors of
the components must be completely represented by the models. The difficulty of building all of the known and emergent behaviors into the models is
compounded by the continuing iterations of discovery of what a component
does and is supposed to do, and then coupled with the addition of new
requirements that naturally result from the interactions with stakeholders
during design, architecting, development, and testing, it can completely
undermine the efficacy of the models. On large-scale system integration or
system of systems integration efforts, technical integration is challenged and
has not yet been shown to be effective. As stated in the NIST report, there
must be a consistency between the functional and behavioral characteristics
* Users who become mixed up turn into Suers.