Architected Futures™

Tools and strategies ... for boiling the ocean

Glossary of Terms

The glossary provides a summary definition of the identified terms. Glossary pages are organized and displayed in alphabetic groups by first letter of the term. Use the alphabar at the top of the page to display the page you are looking for by selecting the first letter of the term you would like to see. To see a more detailed view of the glossary terms, potentially including a second definition, expanded content, or comments, click on the term to be taken to a separate page for that specific term.

A | B | C | D | E | F | G | I | L | M | O | P | Q | R | S | U | V | W | Z

EATS: A service request or response message that conforms to the EATS document model.

58: A discrete, separately targetable and separately managed physical node that serves as the physical platform supporting one or more Architected Service Facilities.

58: A business oriented or utility resource that is accessed and managed through service contracts that comply with delivery using the EATS framework.

58: A module that has been designed and configured for use in the EATS framework Architected Resource Layer and whose purpose is the management of an Architected Resource.

58: A business-oriented or utility service whose technical contract complies with delivery using the EATS framework.

58: A distinct, separately targetable and separately managed software run unit implementing an instance of the EATS framework.

The application of engineering disciplines to the analysis, design and construction of structures or systems. Architectural engineering principally focuses on the engineering and durability qualities (the soundness) of the structure of an architected entity.

Architecture is the arrangement of functions and features within a system that strives for ideal harmony and balance of utility, durability and delight for the stakeholders.

113: "An Architecture Description [AD] is a work product used to express the Architecture of some System Of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System Of Interest. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard)."

113: "An architecture framework is defined as the conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders."

113: "A view is comprised of Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view."

113: "A Model Kind defines the conventions for a type of Architecture Model."

113: "An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models."

113: "An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information."

A term used to indicate indivisibility. Atomic items are at the most granular level of concern relative to the problem statement or domain of interest.