4.3.12. Architecture Design Process
4.3.12. Architecture Design Process
Architecture Design is a trade and synthesis process that allows the Program Manager and Systems Engineer to translate the outputs of the Stakeholder Requirements Definition and Requirements Analysis processes into alternative design solutions and establishes the architectural design of candidate solutions that may be found in a system model. The alternative design solutions may include hardware, software, and human elements; their enabling system elements; and related internal and external interfaces. The Architecture Design process, combined with Stakeholder Requirements Definition and Requirements Analysis, provides key insights into technical risks early in the acquisition life cycle, allowing for early development of mitigation strategies. Architecture Design is integral to ensuring that multiple well-supported solutions are considered. The Architecture Design process supports analysis of design considerations and enables reasoning about key system aspects and attributes such as reliability, maintainability, survivability, sustainability, performance, and total ownership cost.
Architecture design synthesizes multiple potential solutions from system performance requirements, evaluates those solutions, and eventually describes the system down to the individual system element for implementation. The Architecture Design process is iterative and strives to seek a balance among cost, schedule, performance, and risk that still meets stakeholder needs.
The functional architecture provides the foundation for defining the system architecture through the allocation of functions and sub‐functions to hardware/software, databases, facilities, and human operations to achieve its mission. The development of the physical architecture consists of one or more product structures or views of the physical solution. The product structure may consist of conceptual design drawings, schematics, and/or block diagrams that define the system’s form and the arrangement of the system elements and associated interfaces. The DoD Architecture Framework (DoDAF) operational and system viewpoints provide one method for developing and describing the system functional architecture. The development of a physical architecture is an iterative and recursive process and evolves together with the functional requirements and functional architecture. Development of the physical architecture is complete when the system has been decomposed to the lowest system element (usually the lowest replaceable unit of the support strategy). It is critical that this process identify the design drivers and driving requirements as early as possible.
The Program Manager may oversee Architecture Design efforts to gain and maintain insights into program schedule and cost drivers for use in evaluation of alternative architectures, excursions, mitigation approaches, etc.
Key activities in the Architecture Design process include:
- Analysis and synthesis of the physical architecture and the appropriate allocation,
- Analysis of the constraint requirements,
- Identify and define physical interfaces and system elements, and
- Identify and define critical attributes of the physical system elements, including design budgets (e.g., weight, reliability) and open system principles.
During this process, derived requirements come from solution decisions. It is essential to identify derived requirements and ensure that they are traceable and part of the allocated requirements. For each given solution alternative, the Decision Analysis process trades off requirements against given solution alternatives. For each solution alternative, based on programmatic decisions, certain performance requirements may be emphasized over others. The essence of this activity is to achieve a balanced and feasible design with acceptable risk, and that falls within the program design constraints. An integral part of defining and refining the functional and physical architecture is to provide technical support to the market research especially early in the acquisition life cycle. Systems engineers should analyze whether existing products (commercial or non-developmental items) can meet user performance requirements or whether technologies can realistically be matured within the required time frame. When possible, mature technologies should be used to satisfy user needs.
The development of the system architecture should adhere to sound systems engineering (SE) and should conform to industry standards as applicable. The functional architecture should be part of the functional baseline, and the physical architecture should be part of the allocated and product baselines. The system architecture should be placed under configuration control and maintained in a robust repository that maintains the architecture descriptions and its relationships to each of the baselines. This control provides the Systems Engineer with a means of ensuring consistency of the system architecture definition throughout the acquisition life cycle.
The output of this process is the system allocated baseline, which includes the documentation that describes the physical architecture of the system and the specifications that describe the functional and performance requirements for each configuration item along with the interfaces that compose the system. In addition, Work Breakdown Structures (WBS) and other technical planning documentation are updated. The system architecture and the resulting design documentation should be sufficiently detailed to allow the following:
- Confirmation of upward and downward traceability of requirements
- Confirmation of interoperability and open system performance requirements
- Sufficient product and process definition to support implementation, verification, and validation of the system
- Establishment of achievable alternatives to allow key stakeholders to make informed decisions
Confirmation of requirements traceability and the soundness of the selected physical architecture can be accomplished using a cost-effective combination of design modeling and analysis, as applicable.
The result of the Architecture Design process is an architectural design that meets the end-user capability needs shown in the Requirements Management process to have all stated and derived requirements allocated to lower level system elements and to have the possibility of meeting cost, schedule, and performance objectives. The architectural design should be able to be communicated to the customers and to the design engineers. The level of detail of the architectural design depends on the complexity of the system and the support strategy. It should be detailed enough to bound the cost and schedule of the delivered system, define the interfaces, ensure the customers that the requirements can be met, and control the design process down to the lowest removable unit to support operations and sustainment. This architecture design may be documented and found in a program’s system model. Once identified, the system architecture is placed under configuration management.
DAG Tutorial 
