Definition: An Architectural Decision Record (ADR) is a document that captures the key decisions made during the architectural design and development of a software system. It is used to record the rationale, alternatives considered, and trade-offs made during the decision-making process, as well as the context and implications of each decision.
Source: Architectural Decision Records
Source reference: https://adr.github.io/
IoP Dimension: Governance IoP
LOST view: Interoperability Motivation View
Identifier: http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal
eira:ID: http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal
EIRA concept: eira:ArchitectureBuildingBlock
Last modification: 24-04-2023
dct:identifier: A unique increasing number and date that usually follows the ADR-nnnn pattern to help sort them from old to new (ADR-20230412180800). The format to use is ADR-[YYYYMMDDHHmmSS].
dct:title: The title contains a short phrase describing the architectural decisions.
dct:description: The description contains a full description of the architectural decisions.
adr:context: The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons.
adr:decision: The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how.
adr:status: [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)]
adr:consecuences: The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture.
|
|
eira:PURI | http://data.europa.eu/dr8/DigitalSolutionArchitectureDecisionGoal |
eira:ABB | eira:DigitalSolutionArchitectureDecisionGoal |
dct:type | eira:DigitalSolutionArchitectureDecisionGoal |
dct:modified | 2023-06-15 |
dct:publisher | ISO/IEC/IEEE |
dct:identifier | A unique increasing number and date that usually follows the ADR-nnnn pattern to help sort them from old to new (ADR-20230412180800). The format to use is ADR-[YYYYMMDDHHmmSS]. |
dct:title | The title contains a short phrase describing the architectural decisions. |
dct:description | The description contains a full description of the architectural decisions. |
skos:definition | An Architectural Decision Record (ADR) is a document that captures the key decisions made during the architectural design and development of a software system. It is used to record the rationale, alternatives considered, and trade-offs made during the decision-making process, as well as the context and implications of each decision. |
eira:definitionSource | ISO/IEC/IEEE 42010:2022 |
eira:definitionSourceReference | https://www.iso.org/standard/74393.html |
skos:example | |
eira:adr_context | The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. |
eira:adr_decision | The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. |
eira:adr_status | [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] |
eira:adr_consecuences | The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. |
eira:iopDimension | Governance IoP |
skos:note | |
eira:view | Digital Solution Architecture Decisions Catalogue view |
eira:view | Enterprise Architecture Framework alignment guidelines view |