Within the SE community, notions of architecture seem to have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with design as part of a single system life cycle process called “architectural design”. Although there are diverse viewpoints on architecture, the different perspectives have much in common. We consider systems engineering to cover all aspects of the creation of a system, including system architecture. The majority of interpretations of system architecture are based on the fairly intangible notion of structure – i.e. relationships between elements.
Some authors limit the types of structure considered to be architectural; say, for example, restricting themselves to functional and physical structure. Recent practice has extended consideration to include temporal and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice with potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group. (Wilkinson et al.2010, Wilkinson 2010).
System Design
In industrial practices, the term “design” is often used to mean both "architecture" and "design" as defined in the SEBoK. In the recent past, professionals used the term "design" when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of "system" in dealing with complexity.
The trend today is to consider system architecture and design as different sets of activities; attempts are made to define separate concurrent processes, but they are strongly intertwined:
• System design includes activities to conceive a system that answers an intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply traded-off system requirements.
• System design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation.
• System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems.
The purpose of system design is to make the link between the system architecture and the implementation of technological system elements that compose the physical architecture of the system. These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.
Transition from System Requirements to Physical Architecture
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of logical architecture (glossary), then to allocate the elements of the logical architecture to system elements of candidate physical architectures.
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.). Creating intermediate models such as logical architecture models enables facilitation of the validation of functional, behavioral, temporal properties of the system against system requirements which have no major technological influence, and changing during the life of the system the physical interfaces or the technological layer without completely questioning the logical functioning of the system.
Iterations between Logical and Physical Architecture definition
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not taken before. Derived functions must, in their turn, be allocated to system elements. This, in turn, affects the physical architecture models.
Additional architecture and design iterations can produce an exhaustive and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can conduct to creation of new system requirements, called “derived requirements”.
Concept of Interface
The concept of interface is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function “send,” located in one system element, the function “receive,” located in the other one, and the function “carry,” performed by the physical interface which supports the input/output flow.