ISO/IEC/IEEE 42030:2019 ソフトウェア、システム、エンタープライズ—アーキテクチャ評価フレームワーク | ページ 6

3.1

architecture

fundamental concepts or properties of an entity in its environment (3.7) and governing principles for the realization and evolution of this entity and its related life cycle processes

Note 1 to entry: Architecture entity (3.3) is the term used in this document when referring to the entity being architected or the entity subject to architecture processes. The fundamental concepts or properties of the architecture entity are usually intended to be embodied in the entity’s components, the relationships between components, and the relationships between the entity and its environment.

Note 2 to entry: The concept of architecture used in this document applies broadly to the entity being architected or evaluated. This allows for a more generalized usage when the elements in this document are applied.

Note 3 to entry: The entity to be architected can be of several kinds, as illustrated in the following examples: enterprise, organization, solution, system, subsystem, business, data (as a data element or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, etc. It also spans the variety of applications that utilize digital technology such as mobile, cloud, big data, robotics, Internet of Things (IoT), web, desktop, embedded systems, and so on.

Note 4 to entry: Representation of the concepts or properties of an entity and governing principles is captured in architecture models.

Note 5 to entry: Architectures can address a wide range of concerns (3.6) expressed, for example, through architecture views and models, as illustrated in the following examples associated with particular kinds of architectures such as: security architecture, functional architecture, physical architecture, resilience architecture, etc.

[SOURCE:ISO/IEC/IEEE 42020:2019, 3.3]

3.2

architecture description

work product used to express an architecture (3.1)

Note 1 to entry: This document does not require the existence or use of an architecture description when performing an architecture evaluation (3.4) . Some value (3.10) assessment methods do not demand existence of documented architecture models or views. Examples are customer focus group, expert panels and quality workshops where sufficient knowledge of the architecture is in the people participating in use of these methods. The same is true for architectural analysis in that not all methods applied here necessarily need an explicit description of the architecture.

[SOURCE:ISO/IEC/IEEE 42010:2011, 3.3, modified — The abbreviated term “AD” has been removed; Note 1 to entry has been added.]

3.3

architecture entity

thing being characterized by an architecture (3.1)

Note 1 to entry: When referring to the architecture itself of these architecture entities, it is common practice to place the name of the kind of entity in front of the word architecture. For example, the phrase system architecture is used when the thing being dealt with during the architecting effort is a system. Likewise, for the other kinds of entities that are being dealt with during the architecting effort.

[SOURCE:ISO/IEC/IEEE 42020:2019, 3.6, modified — The words “considered, described, discussed, studied, or otherwise addressed during the architecting effort” have been replaced with “characterized by an architecture”.]

3.4

architecture evaluation

ae

judgment about one or more architectures (3.1) with respect to the specified evaluation objectives

Note 1 to entry: A decision regarding disposition of the architecture is usually outside the scope of an AE effort, although it could be done in conjunction with the AE effort. The AE results are often reported to a decision maker who makes the actual determination of disposition based on those results and sometimes also on other factors (3.8) not considered by the AE effort. Sometimes this determination is called an “evaluation” but for the purpose of this document, the evaluation is limited to just the judgment with respect to relevant evaluation objectives.

3.5

architecture evaluation framework

conventions, principles and practices for evaluating architectures (3.1) in a consistent and repeatable manner

Note 1 to entry: This framework can be generic in nature or specific to a domain of application, a collection of concerns (3.6) to be examined or a methodology. This document defines a generic AE framework and a specific AE framework can be derived from the generic framework.

Note 2 to entry: An AE framework can enable AE efforts to be performed in a more consistent and repeatable manner.

Note 3 to entry: The evaluation framework can consist of different sub-architecture frameworks for an entity with many layers or levels. These could be defined and consolidated as part of the comprehensive architecture framework package.

3.6

concern

matter of interest or importance to a stakeholder (3.9)

Note 1 to entry: The concept of concern is similar to “quality attributes” as used in the ATAM. See Annex D for an overview of the ATAM approach. In ATAM, quality attributes are typically decomposed into concerns.

Note 2 to entry: The concept of concern is similar to the concept of quality. See A.4 for an overview of the quality concept.

[SOURCE:ISO/IEC/IEEE 42020:2019, 3.8, modified — In EXAMPLE, reference to 4.2 has been added; Notes 1 and 2 to entry have been added.]

3.7

environment

context determining the setting and circumstances of influences upon an architecture entity (3.3) or upon which the architecture entity can have an influence

Note 1 to entry: There can be things beyond the environment that have an indirect impact on the architecture entity. It could be important to account for these indirect effects by incorporating these causative agents in the environment even though they are not usually considered to be within the immediate context. Value (3.10) chain analysis is an example of where this is done.

3.8

factor

circumstance, fact or influence that contributes to a result or outcome

Note 1 to entry: A factor is something that contributes causally to a result. Factors identification can sometimes be driven by knowledge of desired effects.

3.9

stakeholder

role, position, individual or organization having a right, share, claim or other interest in an architecture entity (3.3) or its architecture (3.1) that reflects their needs and expectations

[SOURCE:ISO/IEC/IEEE 42020:2019, 3.20]

3.10

value

regard that something is held to deserve; the importance, worth, or usefulness of something to somebody

Note 1 to entry: Architecture evaluation (3.4) is focused primarily on the value of an architecture (3.1) with respect to stakeholder (3.9) concerns (3.6) or architecture objectives for that thing. However, sometimes the purpose of the evaluation effort is, by inference, to determine the impact of the architecture on the value of the architecture entity (3.3) when the entity is developed or evolved to align with the architecture concepts and properties.

Note 2 to entry: The determination of architecture value can take various aspects into account, such as worth, significance, importance, usefulness, benefit, and quality. These words have similar but not identical meaning. Worth is usually what one is willing to pay for something. Significance is about being worthy of attention. Importance is about the state or fact of being of great significance or value. Usefulness is about serving some purpose, or about being advantageous, helpful or of good effect. Benefit is about an advantage or profit gained from something. Quality is about the degree of excellence of something. Throughout this document, the term value is used to mean one or more of these other concepts, as appropriate.

Note 3 to entry: Even though a new architecture could be found to be of greater value with respect to the current situation, this needs to be balanced against the costs and risks of adopting the new architecture. So, it is not necessarily the case that when examining architecture alternatives, the one with the maximum value is proposed as the preferred choice since the extra cost or risk of this architecture might not be worth the extra burden. This is sometimes referred to as the benefit-cost ratio or some other term with similar meaning.

Note 4 to entry: Value is determined primarily in the Value Assessment Tier of the evaluation framework illustrated in Figure 1. Requirements on value assessment are specified in 6.2.