274
Engineering Systems Integration
a flawed design is wasteful. To circumvent a design problem, the integration
plan needs to more than simply define the sequence of activities that will be
accomplished to integrate components into subsystems and subsystems into
a whole. The plan is important by two measures: what function(s) are to be
demonstrated first, then second, and so forth, and how the users respond
(user behaviors) to their use of the function(s) (Federal Highway
Administration 2009). If integration planning relied only on architecture,
behaviors are process related but not user related. Process behaviors capture
the system performances of the product or service, not the behaviors of the
users. The system may perform in such a manner as to inhibit the user from
accomplishing their task in the requisite period of time. Architecture merely
reinforces the product or service performance, not the combination of user
and product or user and service behaviors. Naturally, the systems engineer
endeavors to design the system to accommodate and provide for user behaviors through architecture, functionalities, performances, user interfaces, and
physical adaptations. But since there is no one item that captures the behaviors, the only means of validating a product’s or service’s fitness are through
modeling, simulation, or actual use of the product or service. Integration
planning should provide for at least one of these three means of validation.
Testing by itself is not validation.
Architecting
Architecture is different from design, as different as marketing is from sales.
In some ways, an architect is like the salesperson who readies a pitch to reach
a deal. The pitch is derived from a plan which is in line with policies set
down by the position of product (the buyer’s perception of the product) in the
marketplace, by the product’s design, and by the manner in which the product is thought to be useful. The architecture carries with it the organization
of the product or service (embodied in its objects and their interactions) to
provide the user with various functions. The premise of the architecture is
the flow of EMMI that satisfies the needs of the user, reinforces the desires of
the seller, is in agreement with what the customer expects, and is sustainable
during its lifecycle.
Whereas design has more to do with setting up the problem, architecture
must solve the problem. Architecture has more to do with the ways in which
the purpose of the design is to be achieved than with the selection of the
optimal means for realizing that design. Architecting brings order to misleading, ill-fitting, and confounding data; at-odds opinions; differing values;
and problematic convergences. Architecture must sort these, implement the
decisions, and show that the resulting compromises satisfy the key stakeholders. Designs that are not well defined, problems that are misstated, and
Engineering Systems Integration
a flawed design is wasteful. To circumvent a design problem, the integration
plan needs to more than simply define the sequence of activities that will be
accomplished to integrate components into subsystems and subsystems into
a whole. The plan is important by two measures: what function(s) are to be
demonstrated first, then second, and so forth, and how the users respond
(user behaviors) to their use of the function(s) (Federal Highway
Administration 2009). If integration planning relied only on architecture,
behaviors are process related but not user related. Process behaviors capture
the system performances of the product or service, not the behaviors of the
users. The system may perform in such a manner as to inhibit the user from
accomplishing their task in the requisite period of time. Architecture merely
reinforces the product or service performance, not the combination of user
and product or user and service behaviors. Naturally, the systems engineer
endeavors to design the system to accommodate and provide for user behaviors through architecture, functionalities, performances, user interfaces, and
physical adaptations. But since there is no one item that captures the behaviors, the only means of validating a product’s or service’s fitness are through
modeling, simulation, or actual use of the product or service. Integration
planning should provide for at least one of these three means of validation.
Testing by itself is not validation.
Architecting
Architecture is different from design, as different as marketing is from sales.
In some ways, an architect is like the salesperson who readies a pitch to reach
a deal. The pitch is derived from a plan which is in line with policies set
down by the position of product (the buyer’s perception of the product) in the
marketplace, by the product’s design, and by the manner in which the product is thought to be useful. The architecture carries with it the organization
of the product or service (embodied in its objects and their interactions) to
provide the user with various functions. The premise of the architecture is
the flow of EMMI that satisfies the needs of the user, reinforces the desires of
the seller, is in agreement with what the customer expects, and is sustainable
during its lifecycle.
Whereas design has more to do with setting up the problem, architecture
must solve the problem. Architecture has more to do with the ways in which
the purpose of the design is to be achieved than with the selection of the
optimal means for realizing that design. Architecting brings order to misleading, ill-fitting, and confounding data; at-odds opinions; differing values;
and problematic convergences. Architecture must sort these, implement the
decisions, and show that the resulting compromises satisfy the key stakeholders. Designs that are not well defined, problems that are misstated, and