Architecture (glossary)

(1) The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (ISO/IEC 2008, Section 4.5)

(2) The organizational structure of a system or component; the organizational structure of a system and its implementation guidelines. (ISO/IEC 2009, 1)

(3) Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (ISO/IEC 2011, section 3.2)

Source

(1) ISO/IEC/IEEE. 2008. Systems and Software Engineering — System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E).

(2) ISO/IEC/IEEE. 2009. Systems and Software Engineering — System and Software Engineering Vocabulary Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronic Engineers (IEEE) 2009 ISO/IEC/IEEE 24765:2009 [database online]. Available from http://pascal.computer.org/sev_display/index.action.

(3) ISO/IEC/IEEE. 2011. Systems and Software Engineering — Architectural Description. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2011.

Discussion

A few definitions are presented here to illustrate the different ways that authors define architecture. Note that many authors write extensively on architecture without ever defining what they mean by the term.

The use of the word fundamental (definitions (1) and (3)) is problematic, since it has no universal definition. In practice, the level of detail in an architecture depends on the context of use and the purpose to which it is being designed. In the early (conceptual) stages it might only contain a high-level description of the system as a whole, but in later stages the key features of all key subsystems need to be mapped out. An architectural description should therefore also justify what is included and what is excluded.

ISO/IEC/IEEE 15288:2008 is normative - see above. The architecture associated with a system-of-interest is conceptual and is realized through an architectural description.

ISO/IEC/IEEE 42010:2011 is normative - see above.

OMG 2010 is normative - “The organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts.”

Works Cited

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

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