The successful implementation of a training simulation system requires that engineering constraints be communicated from the Systems Engineer to the designers in an unambiguous manner. This paper proposes that an architectural framework can be developed, providing the Systems Engineer with a tool to aid in this communication.

The paper documents the F-22 Pilot Training System team's observation that the term "architecture" has no universally-accepted definition. It chronicles the process used to resolve this problem, eliminating the confusion concerning both the terminology and the process of developing an architecture. It describes a hierarchy of definitions, allowing consensus to be reached among a group with widely varying experience levels, without creating a "least common denominator" definition. It explains the term by means of analogy - what "architecture" means to a builder, and how this maps into the trainer engineering context.

Emphasis is given to how an architecture needs to address hardware and software as a system. A preferred process for creating the architecture and managing the subsequent development of the product, using architecture as a systems engineering tool, is discussed. The paper describes the "litmus test" developed to determine whether an approach constitutes an architecture and describes the attributes of an architecture that allow its relative quality to be measured. It observes that most of what is touted as architecture doesn't pass the "litmus test," and why it does not.

Believing that the F-22 program is a microcosm of a trend throughout industry, the paper suggests that lessons learned by the F-22 can be effectively applied elsewhere. It discusses why this subject is so vital to a simulation development effort, and concludes with some thoughts on how a properly developed architecture can provide significant advantages to a system integrator.