AWS prescriptive-guidance documentation change
Summary
Updated document title, fixed contractions, modified breadcrumb navigation links, and updated image paths for architectural decision record process diagrams.
Security assessment
Changes are editorial improvements and image path updates without any security-specific content. No vulnerabilities, security controls, or security incidents are mentioned. The modifications focus on general documentation structure and process descriptions.
Diff
diff --git a/prescriptive-guidance/latest/architectural-decision-records/adr-process.md b/prescriptive-guidance/latest/architectural-decision-records/adr-process.md index 5e3673c7f..c3b66576e 100644 --- a//prescriptive-guidance/latest/architectural-decision-records/adr-process.md +++ b//prescriptive-guidance/latest/architectural-decision-records/adr-process.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Using architectural decision records to streamline technical decision-making for a software development project](welcome.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Using architectural decision records to streamline decision-making during development](introduction.html) @@ -9 +9 @@ Scope of the ADR processADR contentsADR adoption processADR review process -# ADR process +# Architectural decision record process @@ -11 +11 @@ Scope of the ADR processADR contentsADR adoption processADR review process -An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they’re planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. For an example of an ADR, see the [appendix](./appendix.html). +An architectural decision record (ADR) is a document that describes a choice the team makes about a significant aspect of the software architecture they're planning to build. Each ADR describes the architectural decision, its context, and its consequences. ADRs have states and therefore follow a lifecycle. For an example of an ADR, see the [appendix](./appendix.html). @@ -38 +38 @@ Functional and non-functional requirements are the most common inputs to the ADR -When the team identifies a need for an ADR, a team member starts to write the ADR based on a projectwide template. (See the [ADR GitHub organization](https://adr.github.io/) for example templates.) The template simplifies ADR creation and ensures that the ADR captures all the relevant information. At a minimum, each ADR should define the context of the decision, the decision itself, and the consequences of the decision for the project and its deliverables. (For examples of these sections, see the [appendix](./appendix.html).) One of the most powerful aspects of the ADR structure is that it focuses on the reason for the decision rather than how the team implemented it. Understanding why the team made the decision makes it easier for other team members to adopt the decision, and prevents other architects who weren’t involved in the decision-making process to overrule that decision in the future. +When the team identifies a need for an ADR, a team member starts to write the ADR based on a projectwide template. (See the [ADR GitHub organization](https://adr.github.io/) for example templates.) The template simplifies ADR creation and ensures that the ADR captures all the relevant information. At a minimum, each ADR should define the context of the decision, the decision itself, and the consequences of the decision for the project and its deliverables. (For examples of these sections, see the [appendix](./appendix.html).) One of the most powerful aspects of the ADR structure is that it focuses on the reason for the decision rather than how the team implemented it. Understanding why the team made the decision makes it easier for other team members to adopt the decision, and prevents other architects who weren't involved in the decision-making process to overrule that decision in the future. @@ -46 +46 @@ The following diagram illustrates the ADR creation, ownership, and adoption proc - + @@ -62 +62 @@ The following diagram shows the process of applying an ADR to validate if a chan - + @@ -70 +70 @@ The team should treat ADRs as immutable documents after the team accepts or reje - +