An enduring architecture, for the purpose of this paper, is not the physical or functional architecture. It is not necessarily even the product of the systems engineering or design process! This paper suggest that the term “enduring architecture” represents a set of constraints placed on the design for the purpose of:
1) Ensuring consistency of key characteristics as a
product design matures or evolves, and
2) Exemplifying a strategy for continuing customer
satisfaction and communication.
An enduring architecture, in this sense, can contain both structure and behavior, but at an abstract level. It does not contain the entire system structure, but only
those aspects of the structure necessary to accommodate 1) and 2) above. Likewise for system behavior. In doing this, the system architecture provides a
framework in which the design is performed. It also serves to set the system context, constrain the system concept, and bound the interfaces of the resulting
system, thus providing a common system lifecycle focus around which the design team, suppliers, and customer can rally. The relationship between system
architecture and system design is represented in Figure 4. Square boxes represent functions, and rounded boxes represent information. Note that this diagram does not include the control flow or iterative loops normally experienced.
Replaced/Superseded by document(s)
|File||MIME type||Size (KB)||Language||Download|
The term “System Architecture” has been widely used in the systems engineering community for at least three decades. Even today, however, the use of this term often elicits more confusion than understanding! In particular, “System Architecture” has been used to describe, at various times, both the evolutionary system
framework (Rechtin 91) (Rechtin/Maier 97), and the specific physical design or component interrelationship (Hatley 88). Even when it is agreed that the “System Architecture” represents a framework in which detailed design is performed, it is not generally agreed what aspects of behavior and structure should be
captured in such a framework, how it should be represented, and how it relates to the specifics of system design. This paper examines current definitions of “systems architecture”, and proposes a taxonomy of terms to distinguish “single use” from
“enduring” applications of architecture. Particular attention is paid to enduring architectures and their relationship to systems engineering.