275
Integration in Systems Engineering Context
needs that are unspoken merely frustrate the architect. But architect is not
deterred in the search for more than one set of solutions that satisfy the problem. The system design reflects innovation and creativity. The architecture
must be clever and robust.
When building an architecture, there is no route from beginning to end, no
hint from the design process as to the best perspective from which to reckon
with an architecture, no sequence of steps that can be followed, and no list of
rules to guide the work. Architecting is engineering and systems engineering in that the architect puts things together. Design identifies those things
and therefore the end of design is when architecting is finished. Change the
design, and most probably change the architecture. Change the architecture
and potentially change the design. The end of designing is the end of architecting. But it is not until the end of architecting that the design can sustain
its first verification with requirements. “Engineering aims for technical optimization, architecting for client satisfaction” (Maier 2002). Design leads and
is interactive with architecting through the product or services physical
objects, functional characteristics, and the behavioral responses of the user.
Architecting is one of the many feedback loops to improve design. In this
iterative manner, architecting is much like systems engineering, moving
forward and stepping back to fix and refine, ever keeping the presence of a
solution that is more highly matched to solving the problem. With rework,
the evolving product or service improves at the unit level. Architecting is
that space somewhere embodying the art and science of solving a puzzle.
It is the aim of architecting to recognize that the problem is only the problem
which needs to be solved when viewed from a particular perspective. What
one person views as a problem may be different from that of another person.
The properties, attributes, traits, context, boundaries, and boundary conditions of the problem suggest the types of solutions that can apply. The types of
solutions also suggest the type of problems that can be solved. The constraints of time, money, skills, policy, or rules further constrain the nexus of
problem and solution. Architecting needs to be responsive to all of these.
The architectural views are the greater variability cast by the perceptions
of attributes, context, boundaries, and boundary conditions of the problem.
The wide range of possible solutions is often noticed in industrial and
commercial enterprises. So, it is the job of the architect to pose the brilliant
solution that captures the essence of the design objectives given the resources,
limitations, stakeholder sensitivities, and constraints. Architecture brilliance
is portrayed by the simplicity, coherency, and robustness as seen through
the manageability of the objects and their mechanisms to solve the problem
easily, within budget, on schedule, and with all functionality, requisite
performances, and expected quality.*
The architect’s strategy may notice the breadth of the principal features
of the system design and use that as a key from which to tie other factors
* At a minimum.
Integration in Systems Engineering Context
needs that are unspoken merely frustrate the architect. But architect is not
deterred in the search for more than one set of solutions that satisfy the problem. The system design reflects innovation and creativity. The architecture
must be clever and robust.
When building an architecture, there is no route from beginning to end, no
hint from the design process as to the best perspective from which to reckon
with an architecture, no sequence of steps that can be followed, and no list of
rules to guide the work. Architecting is engineering and systems engineering in that the architect puts things together. Design identifies those things
and therefore the end of design is when architecting is finished. Change the
design, and most probably change the architecture. Change the architecture
and potentially change the design. The end of designing is the end of architecting. But it is not until the end of architecting that the design can sustain
its first verification with requirements. “Engineering aims for technical optimization, architecting for client satisfaction” (Maier 2002). Design leads and
is interactive with architecting through the product or services physical
objects, functional characteristics, and the behavioral responses of the user.
Architecting is one of the many feedback loops to improve design. In this
iterative manner, architecting is much like systems engineering, moving
forward and stepping back to fix and refine, ever keeping the presence of a
solution that is more highly matched to solving the problem. With rework,
the evolving product or service improves at the unit level. Architecting is
that space somewhere embodying the art and science of solving a puzzle.
It is the aim of architecting to recognize that the problem is only the problem
which needs to be solved when viewed from a particular perspective. What
one person views as a problem may be different from that of another person.
The properties, attributes, traits, context, boundaries, and boundary conditions of the problem suggest the types of solutions that can apply. The types of
solutions also suggest the type of problems that can be solved. The constraints of time, money, skills, policy, or rules further constrain the nexus of
problem and solution. Architecting needs to be responsive to all of these.
The architectural views are the greater variability cast by the perceptions
of attributes, context, boundaries, and boundary conditions of the problem.
The wide range of possible solutions is often noticed in industrial and
commercial enterprises. So, it is the job of the architect to pose the brilliant
solution that captures the essence of the design objectives given the resources,
limitations, stakeholder sensitivities, and constraints. Architecture brilliance
is portrayed by the simplicity, coherency, and robustness as seen through
the manageability of the objects and their mechanisms to solve the problem
easily, within budget, on schedule, and with all functionality, requisite
performances, and expected quality.*
The architect’s strategy may notice the breadth of the principal features
of the system design and use that as a key from which to tie other factors
* At a minimum.