|
Tag: visualeditor-switched |
| Line 1: |
Line 1: |
| − | The purpose of system architecture activities is to define a comprehensive solution based on principles, concepts, and properties logically related and consistent with each other. The solution architecture has features, properties, and characteristics satisfying, as far as possible, the problem or opportunity expressed by a set of system requirements (traceable to mission/business and stakeholder requirements) and life cycle concepts (e.g., operational, support) and are implementable through technologies (e.g., mechanics, electronics, hydraulics, software, services, procedures).
| + | ---- |
| | + | '''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Janet Singer, Duane Hybertson'' |
| | + | ---- |
| | + | This knowledge area (KA) provides a guide for applying the {{Term|Systems Approach (glossary)|systems approach}} as a means of identifying and understanding complex problems and opportunities, synthesizing possible alternatives, analyzing and selecting the best alternative, implementing and approving a solution, as well as deploying, using and sustaining {{Term|Engineered System (glossary)|engineered system}} solutions. The active participation of stakeholders during all the activities of the systems approach is the key to the success of the systems approach. |
| | | | |
| − | System Architecture is abstract, conceptualization-oriented, global, and focused to achieve the mission and operational concepts of the system. It also focuses on high‐level structure in systems and system elements. It addresses the architectural principles, concepts, properties, and characteristics of the system-of-interest. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.
| + | In an engineered system context, a systems approach is a holistic approach that spans the entire life of the system; however, it is usually applied in the development and operational/support life cycle stages. This knowledge area defines a systems approach using a common language and intellectual foundation to ensure that practical systems concepts, principles, patterns and tools are accessible to perform {{Term|Systems Engineering (glossary)|systems engineering}} (SE), as is discussed in the introduction to [[Foundations of Systems Engineering|Part 2: Foundations of Systems Engineering]]. |
| | | | |
| − | == General Concepts and Principles == | + | ==Topics== |
| | + | Each part of the Guide to the SE Body of Knowledge (SEBoK) is divided into KAs, which are groupings of information with a related theme. The KAs, in turn, are divided into topics. This KA contains the following topics: |
| | + | *[[Overview of the Systems Approach]] |
| | + | *[[Engineered System Context]] |
| | + | *[[Identifying and Understanding Problems and Opportunities]] |
| | + | *[[Synthesizing Possible Solutions]] |
| | + | *[[Analysis and Selection between Alternative Solutions]] |
| | + | *[[Implementing and Proving a Solution]] |
| | + | *[[Deploying, Using, and Sustaining Systems to Solve Problems]] |
| | + | *[[Applying the Systems Approach]] |
| | | | |
| − | === Notion of Structure === | + | ==Systems Approach== |
| − | The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.
| + | This KA describes a high-level framework of activities and principles synthesized from the elements of the systems approach, as described earlier in Part 2 of the SEBoK, and is mapped to the articles [[Concepts of Systems Thinking]], [[Principles of Systems Thinking]], and [[Patterns of Systems Thinking]]. The concept map in Figure 1 describes how the knowledge is arranged in this KA and the linkage to the KA in Part 3. |
| | | | |
| − | The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements).
| + | [[File:Fig_1_Systems_Engineering_and_the_Systems_Approach_RA.png|thumb|650px|center|'''Figure 1. Systems Engineering and the Systems Approach.''' (SEBoK Original)]] |
| | | | |
| − | Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''behavioral'','' temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).
| + | According to Jackson et al. (2010, 41-43), the systems approach to engineered systems is a problem-solving paradigm. It is a comprehensive problem identification and resolution approach based upon the principles, concepts, and tools of {{Term|Systems Thinking (glossary)|systems thinking}} and {{Term|Systems Science (glossary)|systems science}}, along with the concepts inherent in engineering problem-solving. It incorporates a holistic systems view that covers the larger context of the system, including engineering and operational environments, stakeholders, and the entire life cycle. |
| | + | |
| | | | |
| − | ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).
| + | Successful systems practice should not only apply systems thinking to the system being created but should also utilize systems thinking in consideration of the way in which work is planned and conducted. See [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] for further discussions on how individuals, teams, businesses and enterprises may be enabled to perform systems engineering. |
| | | | |
| − | 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).
| + | ==References== |
| | | | |
| − | === Architecture Description of the System === | + | ===Works Cited=== |
| − | An architecture framework contains standardized viewpoints, view templates, meta-models, model templates, etc., that facilitate the development of the views of a system architecture. ISO/IEC/IEEE 42010 specifies the normative features of architecture frameworks, viewpoints, and views as they pertain to architecture description. A viewpoint addresses a particular stakeholder concern (or set of closely related concerns). The viewpoint specifies the model kinds to be used in developing the system architecture to address that concern (or set of concerns), the ways in which the models should be generated and how the models are used to compose a view. Zachman (1987), DoDAF (2010), MoDAF (n.d.), The Open Group Architecture Framework (TOGAF) are examples of architecture frameworks.
| + | Jackson, S., D. Hitchins, and H. Eisner. 2010. "[[What is the Systems Approach?]]." INCOSE ''Insight,'' vol. 13, no. 1, pp. 41-43. |
| | | | |
| − | Logical and physical models (or views) are often used for representing fundamental aspects of the system architecture. Other complementary viewpoints and views are necessarily used to represent how the system architecture addresses stakeholder concerns, for example, cost models, process models, rule models, ontological models, belief models, project models, capability models, data models, etc.
| + | ===Primary References=== |
| | + | Checkland, P. 1999. ''[[Systems Thinking, Systems Practice]]''. New York, NY, USA: John Wiley & Sons. |
| | | | |
| − | === Classification of Principles and Heuristics ===
| + | Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE ''Insight,'' vol. 12, no. 4. |
| | | | |
| − | Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:
| + | Jackson, S., D. Hitchins, and H. Eisner. 2010. "[[What is the Systems Approach?]]" INCOSE ''Insight,'' vol. 13, no. 1, pp. 41-43. |
| − | # '''Static domain '''relates''' '''to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces.
| |
| − | # '''Dynamic domain '''relates''' '''to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input flows into output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.
| |
| − | # '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.
| |
| − | # '''Environmental domain '''relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]]<nowiki/> of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]]<nowiki/> of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.
| |
| − | More detailed classification can be found in Maier and Rechtin (2009).
| |
| | | | |
| − | === Transition from System Requirements to Physical Architecture === | + | ===Additional References=== |
| | + | Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology''. Hoboken, NJ, USA: John Wiley & Sons. |
| | | | |
| − | 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)|logical architecture]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]].
| + | Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College. |
| | | | |
| − | (System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.)
| + | Senge, P. M. 1990. ''The Fifth Discipline: The Art and Practice of the Learning Organization''. New York, NY, USA: Doubleday/Currency. |
| | | | |
| − | 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.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.
| + | ---- |
| − | [[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|link=http://127.0.0.1/draft/File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|centre|thumb|600x600px| | + | <center>[[Fundamentals for Future Systems Engineering|< Previous Article]] | [[Foundations of Systems Engineering|Parent Article]] | [[Overview of Systems Approaches|Next Article >]]</center> |
| − | '''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).'''Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
| |
| | | | |
| − | ]]
| + | <center>'''SEBoK v. 2.1, released 31 October 2019'''</center> |
| | | | |
| − | === Iterations between Logical and Physical Architecture Development ===
| + | [[Category:Part 2]][[Category:Knowledge Area]] |
| − | | |
| − | Architecture activities require spending several iterations from logical architecture models development to physical architecture models development and vice versa, until both logical and physical architecture models are exhaustive and consistent. One of the first architecture activities 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 previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.
| |
| − | | |
| − | Additional architecture iterations can produce a through 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 lead to creation of new system requirements, called ''derived requirements''.
| |
| − | | |
| − | === Notion of Interface ===
| |
| − | | |
| − | The notion of [[Interface (glossary)|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"'' as being performed by the physical interface that supports the input/output flow (see Figure 4).
| |
| − | | |
| − | [[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|link=http://127.0.0.1/draft/File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|centre|thumb|451x451px|
| |
| − | '''Figure 4. Complete Interface Representation (Faisandier 2012).'''Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
| |
| − | | |
| − | ]]
| |
| − | | |
| − | In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.
| |
| − | | |
| − | === Emergent Properties ===
| |
| − | The overarching architecture of a system may have design properties that emerge from the arrangement and interaction between technological system elements, but which may not be properties of any individual element. [[Emergence (glossary)|Emergence]] is the principle which states that elements exhibit properties which are meaningful only when attributed to the whole, not to its parts.
| |
| − | | |
| − | The elements of an [[Engineered System (glossary)|engineered system]] interact among themselves and can create desirable or undesirable phenomena, such as inhibition, interference, resonance, or the reinforcement of any property. The definition of the system includes an analysis of interactions between [[System Element (glossary)|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 the interactions among several elements (Thome, B. 1993). The system concept of emergence is discussed in SEBoK Part 2 (see [[Emergence]]). The term [[Emergent Property (glossary)|emergent properties]] is used by some authors to identify any property which emerges from a system, while other may refer to this as [[Synergy (glossary)|synergy]] and reserve emergent property for explaining unexpected properties or properties not considered fully during system development, but have emerged during operation.
| |
| − | | |
| − | {|
| |
| − | |+
| |
| − | '''Table 2. Properties and Emergent Properties.'''(SEBoK Original)
| |
| − | !Broad Categories of Properties
| |
| − | !Description and Examples
| |
| − | |-
| |
| − | |'''Local Property'''
| |
| − | |The property is located in a single system element – e.g. the capacity of a container is the capacity of the system.
| |
| − | |-
| |
| − | |'''Accumulative System Property'''
| |
| − | |The property is located in several system elements and is obtained through the simple summation of elemental properties – e.g. the weight of the system results from the sum of the weights of its system elements.
| |
| − | |-
| |
| − | |'''Emergent Property Modified by Architecture and/or Interactions.'''
| |
| − | |The property exists in several system elements and is modified by their interactions – e.g. the reliability/safety of a system results from the reliability/safety of each system element and the way they are organized. Architectural steps are often critical to meeting system requirements.
| |
| − | |-
| |
| − | |'''Emergent Property Created by Interactions'''
| |
| − | |The property does not exist in system elements and results only from their interactions – e.g. electromechanical interfaces, electromagnetism, static electricity, etc.
| |
| − | |-
| |
| − | |'''Controlled Emergent Property'''
| |
| − | |Property controlled or inhibited before going outside the system – e.g.: unbalance removed by the addition of a load; vibration deadened by a damper.
| |
| − | |}
| |
| − | | |
| − | Physical architecture design will include the identification of likely synergies and emergent properties and the inclusion of derived functions, components, arrangements, and/or environmental constraints in the logical or physical architectures to avoid, mitigate or restrain them within acceptable limits. Corresponding ''derived requirements ''should be added to the system requirements baseline when they impact the [[System-of-Interest (glossary)|system-of-interest]](SoI). This may be achieved through the knowledge and experience of the systems engineer or through the application of [[Pattern (glossary)|system patterns]]. However, it is generally not possible to predict, avoid, or control all emergent properties during the architecture development. Fully dealing with the consequences of emergence can only be done via iteration between [[System Definition (glossary)|system definition]], [[System Realization (glossary)|system realization]] and [[System Deployment and Use (glossary)|system deployment and use]].
| |
| − | | |
| − | The notion of emergence is applied during architecture and design to highlight necessary derived functions; additionally, internal emergence is often linked to the notion of [[Complexity (glossary)|complexity]]. This is the case with complex adaptive systems (CAS), in which the individual elements act independently, but behave jointly according to common constraints and goals (Flood and Carson 1993). 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).<!--EndFragment-->
| |
| − | | |
| − | === Reuse of System Elements ===
| |
| − | Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.<center>
| |
| − | {|
| |
| − | |+
| |
| − | '''Table 1. System Element Re-use Cases (Faisandier 2012).'''Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.
| |
| − | !Re-use Case
| |
| − | !Actions and Comments
| |
| − | |-
| |
| − | |'''Case 1:'''The requirements of the system element are up-to-date and it will be re-used with no modification required.
| |
| − | |
| |
| − | * The system architecture to be defined will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.
| |
| − | * If the system element is not adapted, it is probable that costs, complexity, and risks will increase.
| |
| − | |-
| |
| − | |'''Case 2:'''The requirements of the system element are up-to-date and it will be re-used with possible modifications.
| |
| − | |
| |
| − | * The system architecture to be defined is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.
| |
| − | * The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned.
| |
| − | |-
| |
| − | |'''Case 3:'''The requirements are not up-to-date or do not exist.
| |
| − | |
| |
| − | * It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior.
| |
| − | * This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient.
| |
| − | * Reverse engineering is expensive in terms of both time and money, and brings with it increased risk.
| |
| − | |}
| |
| − | </center>
| |
| − | | |
| − | There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).
| |
| − | | |
| − | == Process Approach ==
| |
| − | | |
| − | === Purpose ===
| |
| − | text
| |
| − | | |
| − | === Activities of the process ===
| |
| − | Text
| |
| − | | |
| − | === Artifacts, Methods and Modeling Techniques ===
| |
| − | Text
| |
| − | | |
| − | == Practical Considerations ==
| |
| − | | |
| − | === Pitfalls ===
| |
| − | Text
| |
| − | | |
| − | === Proven Practices ===
| |
| − | Text
| |
| − | | |
| − | <center>[[System Requirements|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Development|Next Article >]]</center>{{DISQUS}}
| |
Lead Author: Rick Adcock, Contributing Authors: Janet Singer, Duane Hybertson
This knowledge area (KA) provides a guide for applying the systems approachsystems approach as a means of identifying and understanding complex problems and opportunities, synthesizing possible alternatives, analyzing and selecting the best alternative, implementing and approving a solution, as well as deploying, using and sustaining engineered systemengineered system solutions. The active participation of stakeholders during all the activities of the systems approach is the key to the success of the systems approach.
In an engineered system context, a systems approach is a holistic approach that spans the entire life of the system; however, it is usually applied in the development and operational/support life cycle stages. This knowledge area defines a systems approach using a common language and intellectual foundation to ensure that practical systems concepts, principles, patterns and tools are accessible to perform systems engineeringsystems engineering (SE), as is discussed in the introduction to Part 2: Foundations of Systems Engineering.
Topics
Each part of the Guide to the SE Body of Knowledge (SEBoK) is divided into KAs, which are groupings of information with a related theme. The KAs, in turn, are divided into topics. This KA contains the following topics:
Systems Approach
This KA describes a high-level framework of activities and principles synthesized from the elements of the systems approach, as described earlier in Part 2 of the SEBoK, and is mapped to the articles Concepts of Systems Thinking, Principles of Systems Thinking, and Patterns of Systems Thinking. The concept map in Figure 1 describes how the knowledge is arranged in this KA and the linkage to the KA in Part 3.
Figure 1. Systems Engineering and the Systems Approach. (SEBoK Original)
According to Jackson et al. (2010, 41-43), the systems approach to engineered systems is a problem-solving paradigm. It is a comprehensive problem identification and resolution approach based upon the principles, concepts, and tools of systems thinkingsystems thinking and systems sciencesystems science, along with the concepts inherent in engineering problem-solving. It incorporates a holistic systems view that covers the larger context of the system, including engineering and operational environments, stakeholders, and the entire life cycle.
Successful systems practice should not only apply systems thinking to the system being created but should also utilize systems thinking in consideration of the way in which work is planned and conducted. See Part 5: Enabling Systems Engineering for further discussions on how individuals, teams, businesses and enterprises may be enabled to perform systems engineering.
References
Works Cited
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?." INCOSE Insight, vol. 13, no. 1, pp. 41-43.
Primary References
Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.
Hitchins, D. 2009. "What are the General Principles Applicable to Systems?" INCOSE Insight, vol. 12, no. 4.
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight, vol. 13, no. 1, pp. 41-43.
Additional References
Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.
Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College.
Senge, P. M. 1990. The Fifth Discipline: The Art and Practice of the Learning Organization. New York, NY, USA: Doubleday/Currency.
< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
