116
Engineering Systems Integration
organization (Ashby 1962; Galbraith 1977); and connections of elementarylevel subcomponents to higher-level assemblies, subsystem, or system
(Ducamp and Lagarrigue 2007). Systems engineers view integration as that
means of building a system (INCOSE 2008), rather than thinking of integration as the consequences of what happens when individual objects are put
together. A systems-level view of integration emphasizes end-to-end functionality enforced through system design and architecture. For human-built
systems, a function can generally be thought of as how objects are used to
accomplish something, that is, a capability of a system. For naturally occurring systems, a function can be generally thought of as how objects interact
with other objects to work within their mechanisms to gain or sustain stability, that is, showing some degree of preference for low-energy expenditures
(Katifori et al. 2010). A function is the essence of interaction between two
objects, and for integration, a function is a structural property of the relations
between objects. The essence of integration is providing functions that are
unachievable by any individual object; performances that surpass the totality
of individual functions; and quality that engenders stability for availability of
those functions, and stability in the performance of those functions.
A natural system is often thought of as having capacity—capacity to withstand environmental “hardships.” However, a predominant theme for systems engineers who build and “integrate” systems is to consider integration
in terms of recursive or progressive approaches while working with data
and interfaces (Buede 2009). Typically, one scheme or a combination of several schemes is imposed to carry out the mechanics of software integration
through data and interfaces. These schemes include top-down, bottom-up,
thread, mixed, and various combinations of top-down and bottom-up. The
International Council on Systems Engineering (INCOSE) Systems Engineering
Handbook (INCOSE 2010) recommends a bottom-up approach to integration,
beginning with the atomic-level* data items (Broersen 2003) that enable the
most detailed functionality (the most detailed functionality in the system
hierarchy) to build from the individual objects into subsystems, with the
final output enabling top-level system functionalities. This bottom-up view
of integration deals with the specifics of each object through interfaces, data
items, and timing—the details of ensuring the fundamental connectivity
and flow of EMMI between objects.
There is no correct way to integrate objects. There are, however, ways more
correct than others, depending on the circumstances surrounding development and integration. An example of a propitious means of integration
builds processes based on the principles developed in Chapter 1. Consider a
project that is behind schedule and over budget, with objects still in development, and no integration work yet started. Let us assume that we have a
strong alignment of strategies (Principle 1: The Principle of Alignment), and
further let us assume we have followed good practices in planning (Principle
* The smallest discernable level of operation.
Engineering Systems Integration
organization (Ashby 1962; Galbraith 1977); and connections of elementarylevel subcomponents to higher-level assemblies, subsystem, or system
(Ducamp and Lagarrigue 2007). Systems engineers view integration as that
means of building a system (INCOSE 2008), rather than thinking of integration as the consequences of what happens when individual objects are put
together. A systems-level view of integration emphasizes end-to-end functionality enforced through system design and architecture. For human-built
systems, a function can generally be thought of as how objects are used to
accomplish something, that is, a capability of a system. For naturally occurring systems, a function can be generally thought of as how objects interact
with other objects to work within their mechanisms to gain or sustain stability, that is, showing some degree of preference for low-energy expenditures
(Katifori et al. 2010). A function is the essence of interaction between two
objects, and for integration, a function is a structural property of the relations
between objects. The essence of integration is providing functions that are
unachievable by any individual object; performances that surpass the totality
of individual functions; and quality that engenders stability for availability of
those functions, and stability in the performance of those functions.
A natural system is often thought of as having capacity—capacity to withstand environmental “hardships.” However, a predominant theme for systems engineers who build and “integrate” systems is to consider integration
in terms of recursive or progressive approaches while working with data
and interfaces (Buede 2009). Typically, one scheme or a combination of several schemes is imposed to carry out the mechanics of software integration
through data and interfaces. These schemes include top-down, bottom-up,
thread, mixed, and various combinations of top-down and bottom-up. The
International Council on Systems Engineering (INCOSE) Systems Engineering
Handbook (INCOSE 2010) recommends a bottom-up approach to integration,
beginning with the atomic-level* data items (Broersen 2003) that enable the
most detailed functionality (the most detailed functionality in the system
hierarchy) to build from the individual objects into subsystems, with the
final output enabling top-level system functionalities. This bottom-up view
of integration deals with the specifics of each object through interfaces, data
items, and timing—the details of ensuring the fundamental connectivity
and flow of EMMI between objects.
There is no correct way to integrate objects. There are, however, ways more
correct than others, depending on the circumstances surrounding development and integration. An example of a propitious means of integration
builds processes based on the principles developed in Chapter 1. Consider a
project that is behind schedule and over budget, with objects still in development, and no integration work yet started. Let us assume that we have a
strong alignment of strategies (Principle 1: The Principle of Alignment), and
further let us assume we have followed good practices in planning (Principle
* The smallest discernable level of operation.