285
Systems Integration Management
than a matter of convenience. Various logics apply, including compliance
issues (e.g., standards, policies, and requirements); preferences based on logistics or support; socioeconomic rationale that makes sense on a normalized or
weighted basis; or other justification that is rational and defensible based on
the rationale. Granularity is the parsing of objects (e.g., requirements) on the
same level of abstraction to differentiate one (in this case) requirement from
another. For the top-level process that describes “to manage,” each of the
portioned subprocesses is determined to have an approximately equal
amount of influence on an organization, that is, having equivalence with
regard to the totality of what is covered. There are also similarities in the
relations, each relation being associated with a common mechanism at the top
level of abstraction to a common set of procedures. In other words, the reasoning and rationale applied to partitioning objects (that are enacted to form
each of the subprocesses) should accommodate the needs of the stakeholders, the limitations set by the boundaries, the constraints established and
imposed by the architecture, and the anticipated changes deemed most
likely as the product or service is used in an operational environment.
Granularity is said to be flexible (Kaindl and Dvetinovic 2008) and if that
flexibility is removed too early in the development process, integration is
made more difficult. By not removing essential flexibility through iterative
design and development, integration is made easier. The ease of integration
is managed by sensitivity and attention to this issue from the systems engineers, the engineers, as well as the project management. A portrayal of granularity is shown in Figure 6.2.
Figure 6.2 illustrates a hierarchical graphical representation of granularity
and abstraction. For granularity, the partitioning of the system of systems (in
this case) into two systems (1.1 and 1.2) indicates that system 1.1 is an integral
whole, as distinct from system 1.2 (also an integral whole). While there may
be overlap in subfunctions, the design and architecture of system 1.1 is
unique and different from the design and architecture of system 1.2. If systems 1.1 and 1.2 were designed and built prior to their integration into a
system of systems, their respective lower-level subfunctions may only be
accessible through interfaces that have already been designed and built. If
one or both of systems 1.1 and 1.2 are being designed and built, then the
separability of the two systems as well as their interoperability will become
the major design and architecture drivers. These design drivers need to be
managed (i.e., planned, organized, directed, controlled, communicated, and
carried by consensus (team-building)).
The notion of overlapping processes or functions is a significant, germane
issue for granularity. Were a function to overlap with a similar, if not identical, function, in an adjacent set of objects, then there may be confusion as to
which of these identical functions should be available to the user. In the
least, there is a redundancy that may or may not be intended. Should there
be an underlap between functions, that is, a part of a function is missing,
or a whole function is missing, then that missing function will inhibit a
Systems Integration Management
than a matter of convenience. Various logics apply, including compliance
issues (e.g., standards, policies, and requirements); preferences based on logistics or support; socioeconomic rationale that makes sense on a normalized or
weighted basis; or other justification that is rational and defensible based on
the rationale. Granularity is the parsing of objects (e.g., requirements) on the
same level of abstraction to differentiate one (in this case) requirement from
another. For the top-level process that describes “to manage,” each of the
portioned subprocesses is determined to have an approximately equal
amount of influence on an organization, that is, having equivalence with
regard to the totality of what is covered. There are also similarities in the
relations, each relation being associated with a common mechanism at the top
level of abstraction to a common set of procedures. In other words, the reasoning and rationale applied to partitioning objects (that are enacted to form
each of the subprocesses) should accommodate the needs of the stakeholders, the limitations set by the boundaries, the constraints established and
imposed by the architecture, and the anticipated changes deemed most
likely as the product or service is used in an operational environment.
Granularity is said to be flexible (Kaindl and Dvetinovic 2008) and if that
flexibility is removed too early in the development process, integration is
made more difficult. By not removing essential flexibility through iterative
design and development, integration is made easier. The ease of integration
is managed by sensitivity and attention to this issue from the systems engineers, the engineers, as well as the project management. A portrayal of granularity is shown in Figure 6.2.
Figure 6.2 illustrates a hierarchical graphical representation of granularity
and abstraction. For granularity, the partitioning of the system of systems (in
this case) into two systems (1.1 and 1.2) indicates that system 1.1 is an integral
whole, as distinct from system 1.2 (also an integral whole). While there may
be overlap in subfunctions, the design and architecture of system 1.1 is
unique and different from the design and architecture of system 1.2. If systems 1.1 and 1.2 were designed and built prior to their integration into a
system of systems, their respective lower-level subfunctions may only be
accessible through interfaces that have already been designed and built. If
one or both of systems 1.1 and 1.2 are being designed and built, then the
separability of the two systems as well as their interoperability will become
the major design and architecture drivers. These design drivers need to be
managed (i.e., planned, organized, directed, controlled, communicated, and
carried by consensus (team-building)).
The notion of overlapping processes or functions is a significant, germane
issue for granularity. Were a function to overlap with a similar, if not identical, function, in an adjacent set of objects, then there may be confusion as to
which of these identical functions should be available to the user. In the
least, there is a redundancy that may or may not be intended. Should there
be an underlap between functions, that is, a part of a function is missing,
or a whole function is missing, then that missing function will inhibit a