Architectural Artefacts
Architectural artefacts are created in order to describe a system, solution, or state of the enterprise. The concepts discussed in this section have been adapted from more formal definitions contained in ISO/EC/IEEE 42010:2011 and ISO/EC/IEEE 15288:2015. They are illustrated in Figure 3-1.
Concepts
The context determining the setting and circumstances of all influences upon a system. The environment of a system includes developmental, technological, business, operational, organisational, political, economic, legal, regulatory, ecological, and social influences.
A combination of interacting elements organised to achieve one or more stated purposes.
The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
A work product used to express an architecture; a collection of architecture views and models that together document the architecture.
Individuals, teams, organisations, or classes thereof, having an interest in a system.
Interests in a system relevant to one or more of its stakeholders. Concerns may pertain to any aspect of the system's functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability and may determine the acceptability of the system.
A representation of a system from the perspective of a related set of concerns. It consists of one or more architecture models of the system. An architecture view will comprise selected parts of one or more models, chosen so as to demonstrate to a particular stakeholder or group of stakeholders that their concerns are being adequately addressed in the design of the system architecture. An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models. Every architecture view has an associated architecture viewpoint that describes it, at least implicitly. ISO/EC/IEEE 42010:2011 encourages architects to define architecture viewpoints explicitly. Making this distinction between the content and schema of a view may seem at first to be an unnecessary overhead, but it provides a mechanism for re-using architecture viewpoints across different architectures.
A representation of a subject of interest. A model provides a smaller scale, simplified, and/or abstract representation of the subject matter. In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools.
A specification of the conventions for a particular kind of architecture view. It can also be called the definition or schema for that kind of architecture view. It establishes the conventions for constructing, interpreting, and using an architecture view to address a specific concern (or set of concerns) about a system-of-interest. Architecture viewpoints are generic, and can be stored in libraries for re-use; an architecture view is always specific to the architecture for which it is created An architecture view is what you see; an architecture viewpoint is where you are looking from - the vantage point or perspective that determines what you see An architecture viewpoint references one or more model kinds; an architecture view incorporates one or more models.
A model kind establishes conventions for a type of modelling.
A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository.
In summary, then, architecture views are representations of the overall architecture in terms meaningful to stakeholders. They enable the architecture to be communicated to and understood by the stakeholders, so they can verify that the system will address their concerns.
Concerns are often related to requirements. A concern can be a general requirement type, such as availability. It may lead to the definition of several particular requirements. It may be an interest related to some goal of a stakeholder. Identifying concerns helps ensure stakeholders' interests are addressed and requirements are identified. Associating concerns with general artefact types helps architects to select and develop particular artefacts for presentation to stakeholders.