Difference between revisions of "System Architecture"
Afaisandier (talk | contribs) Tag: visualeditor |
Afaisandier (talk | contribs) Tag: visualeditor |
||
Line 16: | Line 16: | ||
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). | 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). | ||
− | === | + | === Architecture Description of the System === |
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. | 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. | ||
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. | 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. | ||
− | === | + | === Classification of Principles and Heuristics === |
text | text | ||
− | === | + | === Transition from System Requirements to Physical Architecture === |
text | text | ||
− | === | + | === Iterations between Logical and Physical Architecture Development === |
text | text | ||
− | === | + | === Notion of Interface === |
Text | Text | ||
− | === | + | === Emergent Properties === |
Text | Text | ||
− | === | + | === Reuse of System Elements === |
text | text | ||
Line 51: | Line 51: | ||
Text | Text | ||
− | === | + | === Artifacts, Methods and Modeling Techniques === |
Text | Text | ||
== Practical Considerations == | == Practical Considerations == | ||
− | === | + | === Pitfalls === |
Text | Text | ||
− | === | + | === Proven Practices === |
Text | Text | ||
Revision as of 14:21, 22 June 2015
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).
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.
General Concepts and Principles
Notion of Structure
The SEBoK considers 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; 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)).
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).
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).
Architecture Description of the System
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.
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.
Classification of Principles and Heuristics
text
Transition from System Requirements to Physical Architecture
text
Iterations between Logical and Physical Architecture Development
text
Notion of Interface
Text
Emergent Properties
Text
Reuse of System Elements
text
Process Approach
Purpose
text
Activities of the process
Text
Artifacts, Methods and Modeling Techniques
Text
Practical Considerations
Pitfalls
Text
Proven Practices
Text
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