Architecture Decision Record

1 minute

1. Record architecture decisions

Date: 2024-11-08

Status

Accepted

Context

We need to record the architectural decisions made on this project.

Decision

An Architectural Decision (AD) is a justified software design choice that addresses a functional or non-functional requirement of architectural significance. This decision is documented in an Architectural Decision Record (ADR), which details a single AD and its underlying rationale

We will use Architecture Decision Records, as described by Michael Nygard.

1 minute

2. Architecture decision repository

Date: 2024-11-24

Status

Accepted

Context

We need to record Architecture Decisions (AD) as defined in Record architecture decisions and share these records in an accessible repository.

Decision

To capture these records in a lean way, the Markdown Architectural Decision Records MADR have been invented: MADR is a streamlined template for recording architectural significant decisions in a structured manner.

We will use Markdown Architectural Decision Record 4.0.0 minimal template as described by Oliver Kopp and Olaf Zimmermann.

1 minute

3. Architecture referential

Date: 2024-11-24

Status

Accepted

Context

We need to define an Architecture referential to store the differents view of our solution.

Decision

As defined by the Open Group Architecture Framework (TOGAF), we will use Archimate as a modelling language to define our architecture views.

Consequences

See Archi, an Open Source modelling toolkit supporting ArchiMate language.

1 minute

4. Scripting Architecture referential

Date: 2024-11-24

Status

Accepted

Context

We need to access Architecture referential as defined in Architecture referential and export views as Markdown report.

Decision

We will use JavaScript language to work with Archi models.

Consequences

See jArchi plugin by Phil Beauvoir and scripts related.

1 minute

5. C4 model

Date: 2024-11-24

Status

Accepted

Context

We need to define a simple model to share hierarchical abstraction of our software system.

Decision

We wil use C4 model created by the software architect Simon Brown.

C4 model is a lean graphical notation technique for modeling the architecture of software systems.It is based on a structural decomposition (a hierarchical tree structure) of a system into containers and components and relies on existing modelling techniques such as Unified Modeling Language (UML) or entity–relationship diagrams (ERDs) for the more detailed decomposition of the architectural building blocks.

1 minute

6. Scribe personal device

Date: 2024-11-24

Status

Accepted

Context

We need a personal device to capture notes and diagrams.

Decision

We will use Amazon Kindle Scribe, a digital notebook with stylus.

Consequences

Amazon Kindle Scribe enable us to convert and share content. It can also integrate ADR template to PDF format send by mail to the device.

--- config: look: handDrawn theme: neutral --- flowchart LR Template(ADR Template to PDF format) --> |email|Device[Amazon Kindle Scribe]
1 minute

7. Automate action

Date: 2024-11-24

Status

Accepted

Context

We need to automate action to extract export from Amazon Kindle Scribe as defined in Scribe personal device referential.

Decision

We will use Zapier to automate mail parsing and file attachment extraction.

Consequences

See MailParser for integration.

--- config: look: handDrawn theme: neutral --- flowchart LR Device[Amazon Kindle Scribe] --> |email|Mail[Personal Mailbox] --> Action[Zapier] Action --> Parser(MailParser) Action --> Upload(File Attachment Process)
1 minute

8. File storage

Date: 2024-11-25

Status

Accepted

Context

We need a solution to store file extracted from Kindle Scribe device.

Decision

As we rely on Google Mail for file exchange, we will use Google Drive to simplify system integration and consistency.

Consequences

File attachment process described in Automate action will upload file to Google Drive.

--- config: look: handDrawn theme: neutral --- flowchart LR Action[Zapier] Action --> Parser(MailParser) Parser --read--> GMail{{Google Mail}} Action --> Upload(File Attachment Process) Upload --upload--> Drive{{Google Drive}}
1 minute

9. Software quality

Date: 2024-11-25

Status

Accepted

Context

We need to ensure sofware quality of the solution aligned with Clean Code approach and SOLID principles defined by Robert C. Martin (aka. Uncle Bob).

Decision

We will use SonarCloud to automate analysis with native DevOps integration.

Consequences

Project dashboard need to be regularly review for remediations.

1 minute

10. Dependency check

Date: 2024-11-25

Status

Accepted

Context

We need to analyse external dependencies for security issues review.

Decision

We will activate Dependabot on Github repository.

Consequences

We will need to review alerts raised by Dependabot.