Difference between revisions of "Physical Architecture"

From SEBoK
Jump to navigation Jump to search
Line 207: Line 207:
<center>[[Architectural Design: Logical|< Previous Article]]  |  [[System Definition|Parent Article]]  |  [[System Analysis|Next Article >]]</center>
<center>[[Architectural Design: Logical|< Previous Article]]  |  [[System Definition|Parent Article]]  |  [[System Analysis|Next Article >]]</center>
==Comments from SEBoK 0.5 Wiki==
Please note that in version 0.5, this article was titled “Architectural Design”. The comments below are shared with the "Architectural Design: Logical" article.
<iframe src="http://www.sebokwiki.org/05/index.php?title=Talk:Architectural_Design&printable=yes" width=825 height=200 frameborder=1 scrolling=auto>

Revision as of 12:51, 2 August 2012

The purpose of Physical Architecture Definition (or design) is to create a physical, concrete solution that accommodates the Logical Architecture and satisfies and trades-off System Requirements. Once a Logical Architecture is defined (see Architectural Design: Logical), concrete physical elements have to be identified that could support functional, behavioral, and temporal features, as well as expected properties of the system deduced from non-functional system requirements (for example constraint of replacement of obsolescence, and/or continued product support).

A Physical Architecture is an arrangement of physical elements (System Elements and Physical Interfaces) which provides the designed solution for a product, service, or enterprise, and is intended to satisfy Logical Architecture elements and System Requirements (ISO/IEC 26702). It is implementable through technological System Elements.

System Requirements are allocated to both the Logical and Physical Architectures. The global System Architecture is assessed with System Analysis, and when achieved becomes the basis for System Realization.

Concepts and Principles

Concepts of System Element, Physical Interface, and Physical Architecture

A System Element is a discrete part of a system that can be implemented to fulfill Design Properties. A System Element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these (ISO/IEC 15288:2008).

A Physical Interface physically binds two System Elements; this is similar to a link or a connector.

Table 1 provides some examples of System Elements and Physical Interfaces.

Table 1. Types of System Elements and Physical Interfaces (Table Developed for BKCASE)
SEBoKv05 KA-SystDef Types of System Elements and Physical Interfaces.png

A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of systems and System Elements. The number of elements in the decomposition of one system is limited to a few in order to facilitate the ease of mastering the system; generally "five plus or minus two" elements (see illustration in Figure 1).

Figure 1. Layers of Systems and System Elements (Faisandier 2012) Reprinted with permission of © Alain Faisandier.

Every system in each layer of the decomposition is structured as a Physical Architecture.

A Physical Architecture is built from systems, System Elements, and all necessary Physical Interfaces between these elements, as well as from external elements (neighboring or enabling systems and/or System Elements in the considered layer and concerned elements in the context of the global system of interest) - see illustration in Figure 2.

Figure 2. Physical Architecture Representation (Faisandier 2012) Reprinted with permission of © Alain Faisandier

Concept of Design Property

A Design Property is a property obtained during system architecture and design through the assignment of non-functional requirements, or estimates, analyses, calculations, simulations of a specific aspect, or obtained through the definition of an existing element associated with a System Element, a Physical Interface, and/or a Physical Architecture. If the designed element complies with a requirement, the Design Property will relate to (or may equal) the requirement. Otherwise, one has to identify any discrepancy that could modify the requirement, the design, or identify a deviation.

Stakeholders have concerns that correspond to expected behavior within operational, environmental, or physical constraints as well as more general life cycle constraints. Stakeholder Requirements and System Requirements express these concerns as expected abilities from the system (e.g., usability, interoperability, security, expandability, environment suitability, etc.). Architects and/or designers identify these abilities from requirements and deduce corresponding quantitative or qualitative Design Properties to equip their physical architecture (e.g., reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.). (For more discussion on how some of these properties may be included in architecture and design, please see the article Systems Engineering and Specialty Engineering in the Related Disciplines knowledge area (KA).

Emergent Properties

The overarching Physical Architecture of a system may have Design Properties that emerge from the arrangement of and interaction between technological System Elements, but which may not be properties of any individual element. emergence is the principle which states that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts. Models of a human activity systems exhibit properties as a whole that are derived from its component activities and their structure, but cannot be reduced to them (Checkland 1999).

Technological System Elements interact between themselves and can create desirable or undesirable phenomena called emergent properties, such as inhibition, interference, resonance, or reinforcement of any property. The definition of the system includes an analysis of interactions between technological System Elements in order to prevent undesirable properties and reinforce desirable ones.

A property which emerges from a system can have various origins, from a single System Element to several ones, or from interaction between several ones (Thome, B. 1993). (For more information, see Table 2, as well as the article by Dereck Hitchins at http://www.hitchins.net/EmergenceEtc.pdf.).

Table 2. Emergent Properties (Figure Developed for BKCASE)
SEBoKv05 KA-SystDef Classification of emergent properties-v2.png

The notion of emergent property is used during architecture and design to highlight necessary derived functions and internal physical or environmental constraints. Corresponding “derived requirements” should be added to the System Requirements baseline when they impact the system of interest.

The notion of emergent property is often linked to the notion of complexity. It is the case with Complex Adaptive Systems (CAS) often defined as a 'complex macroscopic collection' of relatively 'similar and partially connected micro-structures', formed in order to adapt to the changing environment, and to increase its survivability as a macro-structure. Examples of CAS include the global macroeconomic network within a country or group of countries, stock market, complex web of cross border holding companies, manufacturing businesses, geopolitical organizations, etc. (Holland, J. 1999 and 2006).

Allocation of Logical Elements to Physical Elements and Partitioning

Defining a candidate Physical Architecture for a system consists of first identifying System Elements which can perform functions of the Logical Architecture and identify interfaces capable of carrying out input-output flows and control flows. When identifying potential elements, a systems engineer needs to allocate Design Properties within the Logical Architecture; these properties are deduced from System Requirements. Partitioning and allocation are activities to decompose, gather, or separate functions in order to facilitate the identification of feasible System Elements that support these functions. Either they exist and can be reused or re-purposed, or can be developed and technically implemented.

Partitioning and allocation use criteria to find potential affinities between functions. Systems engineers use System Requirements and/or Design Properties as criteria to assess and select physical candidate System Elements and partitions of functions; e.g., similar transformations within the same technology, similar levels of efficiency, exchange of the same type of input-output flows (information, energy, and materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, other enterprise constraints, etc.

The activity of partitioning and allocating Functions to System Elements of different technologies, taking into account compatibility issues and emergent properties, justifies the Concurrent Engineering approach: it is necessary to get in parallel several technologies knowledge and skills when working out candidate Physical Architectures.

Working out Physical Candidate Architectures

The goal of Physical Architecture and Design activities is to provide the “best” possible Physical Architecture made of suitable systems, technological System Elements and Physical Interfaces (i.e., the Architecture that answers, at best, all System Requirements, depending on agreed limits or margins of each requirement). The best possible way to do this is to produce several candidate Physical architecture models, assess and compare them, and then select the most suitable one.

A candidate Physical Architecture is worked out according to affinity criteria in order to build a set of (sub) systems and System Elements (i.e., separate, gather, connect, and disconnect the network of System Elements and their Physical Interfaces). These criteria are the same as those used for partitioning and allocating functions to System Elements. The Physical Architecture definition may be focused in different ways; some examples include:

  • a reduction in the number of Physical Interfaces;
  • System Elements that can be tested separately;
  • modular (i.e., have low interdependence);
  • maintainable, replaceable System Elements;
  • compatible technology;
  • measures of the proximity of elements in space;
  • accounts of handling (weight, volume, and transportation facilities); or
  • optimization of resources shared between elements.

Evaluating and Selecting the Preferred Candidate

Viable Physical Architectures enable all required functions or capabilities specified in the Logical Architecture.

Architecture and Design activity includes optimization to obtain a balance among Design Properties, Costs, Risks, etc. Generally, the architecture of a system is determined more strongly by non-functional requirements (e.g., performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many ways to achieve functions but fewer ways of satisfying non-functional requirements. The preferred Physical Architecture represents the optimized design after trade-offs are made.

Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior and structure of the candidate architectures regarding System Requirements; this is often broadly referred to as “system analysis.” Other analyses and assessments require knowledge and skills from the different involved technologies (mechanics, electronics, software, etc.); they are performed through corresponding technological System Elements Design processes.

Legacy Systems and Systems of Systems

When considering a set of existing systems of interest (SoI) that have their own existence in their own context of use, one issue is knowing whether or not it is possible to constitute a system of systems (SoS) that includes those existing systems as System Elements (often called Component Systems). The higher level system has a mission, a purpose, a context of use, objectives, and architectural elements. Engineering of such systems generally includes both reverse engineering and a top down approach, as is the case when upgrading facilities in the frame of a company using information technology keeping legacy systems.

The architecture activity combines top-down and bottom-up approaches to integrate existing or legacy systems on which no (or very few) modifications can be applied. Additional tasks consist of identifying capabilities and interfaces of these existing systems. The architecture activity has to answer two questions:

  • How can the requirements of the new system of interest be fulfilled?
  • How can legacy systems be managed?

Please see the Systems of Systems (SoS) knowledge area (KA) for more information on special considerations for architecting a system of systems.

Process Approach


The purpose of the Physical Architecture Definition (design) Process is to define, select, and synthesize a system Physical Architecture which can support the Logical Architecture. A Physical Architecture will have specific properties designed to address stakeholder or environmental issues and satisfy System Requirements.

Because of the evolution of the context of use or technological possibilities, the Physical Architecture made of System Elements is supposed to change along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts logical architecture elements, allocations to System Elements could change. A Physical Architecture is equipped with specific design properties to continuously challenge the evolution.

Generic inputs include the selected Logical Architecture, System Requirements, generic patterns and properties that designers identify and use to answer requirements, outcomes from System Analysis, and feedback from System Verification and System Validation.

Generic outputs are the selected Physical Architecture, allocation matrix of functional elements to physical elements, traceability matrix with System Requirements, Stakeholder Requirements of each system and System Element composing the Physical Architecture, and rejected solutions.

Activities of the Process

Major activities and tasks to be performed during this process include the following:

  • Partition and allocate functional elements to system elements:
    • Search for System Elements or technologies able to perform Functions, and Physical Interfaces to carry input-output and control Flows. Ensure System Elements exist or can be engineered. Assess each potential System Element using criteria deduced from Design Properties (themselves deduced from non-functional System Requirements).
    • Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria, and allocate partitioned sets to System Elements (using the same criteria).
    • When it is impossible to identify a System Element that corresponds to a partitioned functional set, decompose the function until the identification of implementable System Elements is possible.
    • Check the compatibility of technologies and the compatibility of interfaces between selected System Elements.
  • Model candidate Physical Architectures; for each candidate:
    • Because partitioned sets of functions can be numerous, there are generally too many System Elements. For defining controllable architectures, System Elements have to be grouped into higher-level System Elements known as (sub) systems.
    • Constitute several different sets of (sub) systems corresponding to different combinations of elementary System Elements. One set of (sub) systems plus one or several non-decomposable System Elements form a candidate Physical Architecture of the considered system.
    • Represent (using patterns) the Physical Architecture of each (sub) system connecting its System Elements with Physical Interfaces that carry input-output Flows and triggers. Add Physical Interfaces as needed, in particular, add interfaces with external elements to the (sub) system.
    • Represent the synthesized Physical Architecture of the considered system built from (sub) systems, non-decomposable System Elements, and Physical Interfaces inherited from the Physical Architecture of (sub) systems.
    • Equip the Physical Architecture with Design Properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.
    • If possible, use executable architecture prototypes (e.g., HW-SW in the loop prototypes) for identifying potential deficiencies, and correct the architecture as needed.
  • Assess Physical Architecture candidates and select the most suitable one:
    • Constitute a decision model based on criteria deduced from non-functional requirements (effectiveness, environmental conditions, safety, human factors, cost, risks, etc.) and Design Properties (modularity, communication commonality, maintainability, etc.)
    • Assess Physical Architecture candidates against the given criteria. Select the most suitable one by comparing scores and rationales to determine which candidate best matches the criteria. Use the System Analysis Process to perform assessments (see the System Analysis Topic).
  • Synthesize the selected Physical Architecture:
    • Formalize physical elements and properties. Verify that System Requirements are satisfied and that the solution is realistic.
    • Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding System Requirements.
    • Establish traceability between System Requirements and physical elements, as well as allocation matrices between functional and physical elements.
  • Prepare for the acquisition of each system or non-decomposable System Element:
    • Define the system's or System Element’s mission and objectives from allocated functions and effectiveness.
    • Define the Stakeholder Requirements (the concerned stakeholder being the current studied system). Additional information about development of Stakeholder Requirements can be found in the Stakeholders Requirements topic.
    • Establish traceability between these Stakeholder Requirements and elements of the studied system (in particular Design Properties). This allows traceability of requirements between two layers of systems.

Artifacts and Ontology Elements

This process may create several artifacts, such as:

  • System Design Documents (describe selected logical and physical architectures);
  • System Design Justification Documents (traceability matrices and design choices); and
  • System Element Stakeholder Requirements Documents (one for each system or System Element).

This process handles the ontology elements of Table 3.

Table 3. Ontology Elements Handled within Physical Architecture Design (Figure Developed for SEBoK)
Table. Ontology Ele Handled w Phy Arch Desig AF 071112.png

Note: The element "Interface" may include both functional and physical aspects. It can be used for technical management purposes.

Note: System Element Requirements become Stakeholder Requirements applicable to the System Element of the lower layer of decomposition.

Methods and Modeling Techniques

Modeling techniques are used to create and represent Physical Architectures. Some common models include:

  • Physical block diagrams (PBD);
  • SysML block definition diagrams (BDD); or
  • Internal block diagrams (IBD) (OMG 2010);
  • Executable architecture prototyping.

Depending on the type of domain (Defense, Enterprise, etc.), Architecture Frameworks such as DoDAF, TOGAF, Zachman, etc. provide descriptions that can help to trade-off candidate architectures - see section 'Enterprise Architecture Frameworks & Methodologies' in Enterprise Systems Engineering Key Concepts.

Practical Considerations

Major pitfalls encountered with Physical Architecture Definition are presented in Table 4.

Table 4. Pitfalls with Physical Architecture Definition (Table Developed for BKCASE)
SEBoKv075 KA-SystDef Pitfalls Physical Design.png

Proven practices with Physical Architecture Definition are presented in Table 5.

Table 5. Proven Practices with Physical Architecture Definition (Table Developed for BKCASE)
SEBoKv075 KA-SystDef Practices Physical Design.png



Checkland, P. B. 1999. Systems Thinking, Systems Practice. Chichester, UK: John Wiley & Sons Ltd.

Holland, John H. 1999. Emergence: from chaos to order. Reading, Mass: Perseus Books. ISBN 0-7382-0142-1.

Holland, John H. 2006. "Studying Complex Adaptive Systems." Journal of Systems Science and Complexity 19 (1): 1-8. http://hdl.handle.net/2027.42/41486

ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.

OMG. 2010. OMG Systems Modeling Language specification, version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.

Thome, B. 1993. Systems Engineering, Principles & Practice of Computer-Based Systems Engineering. New York, NY, USA: Wiley.

Primary References

ANSI/IEEE. 2000. Recommended practice for architectural description for software-intensive systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

INCOSE. 2011. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.

ISO/IEC/IEEE. 2008. Systems and Software Engineering - System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).

ISO/IEC/IEEE. 2011. Systems and Software Engineering - Architecture Description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.

Maier, M., and E. Rechtin. 2009. The Art of Systems Architecting. 3rd ed. Boca Raton, FL, USA: CRC Press.

Additional References

Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com

Thome, B. 1993. Systems Engineering, Principles & Practice of Computer-Based Systems Engineering. New York, NY, USA: Wiley.

< Previous Article | Parent Article | Next Article >
SEBoK v. 1.9.1 released 30 September 2018

SEBoK Discussion

Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.

If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.

blog comments powered by Disqus