Intitial Batch of Architecture Decision Records

[ewferg]

This PR includes an initial batch of nine architectural design records (ADRs) to kickoff a new initiative to enhance the transparency and traceability of architectural decisions made within the Aerie project. Since the project has already existed for some time now, in addition to tracking new decisions, we plan to capture historical decisions over time as time permits. Most of the records included in this batch are historical decisions with the exception of ADR-0102, which attempts to capture a recent decision regarding a new concept called "actions", which would allow missions to develop custom actions triggered off of UI events.

From adr-0000-adr-process.md included in this PR:

Over the past year, the Aerie project team has been tasked by its primary sponsor, the NASA AMMOS program, to incorporate enhanced spacecraft sequencing capabilities into Aerie (this task has been colloquially called SEQ 2.0). The program is interested in ensuring sufficient oversight to preserve stakeholder buy-in on the task as it progresses. In addition, new organizations are contributing to the project (e.g. Goddard Spaceflight Center, Ames Research Center) that have less familiarly with the Aerie project and its history. These drivers have created an increased need to clearly communicate architectural decisions and their rationale.

To address these concerns, we would like to create an architectural decision record (ADR) and use it to track architectural decisions.

From arch-design-overview.md included in this PR:

ADRs are a growing list of key architectural decisions made throughout the project. Architectural decisions are those that have far-reaching, significant impact on the design and have a strong influence on quality attributes of the project. The primary purpose of these records are to capture the rationale behind decisions made over the course of the project. If a decision is modified later, one should create a new record that supersedes the previous record, but should not remove the old record in order to preserve the decision history over time.

[ewferg]

@mattdailis, ADR-0004 is the only one in this batch that still needs work, which I could use your help on. ADR-0005 could also use a tad more information as well on why the current Falcon Sequence Editor was insufficient to meet needs.

[dandelany]

Thanks @ewferg and @mattdailis for finalizing this PR, it's looking really good. I spent some time reading through them this week and they're extremely well-written. I appreciate that the voice is more formal and precise than much of the rest of the docs, as these are a bit closer to specs than informational guides.

Two notes:

• The README notes the different possible statuses for ADRs, but I noticed the documents themselves don't have a Status field - we should probably add this. I like having the distinction between "Accepted" and "Retroactive", so I think 0000-0100 should be "Retroactive" and 0101 (Actions) should be either "Proposed" or "Accepted" (depending on how final that decision is...)
• I have a few small edits on the Actions ADR 0101 that I've been working on, but haven't had time to finish and push yet - will commit those later today, or I can do so in a different branch if you'd rather get this merged.

[mattdailis]

Should we specify where Actions are executed as part of this ADR? E.g. in the browser vs in a backend service?

Dan and I are sketching out a proposal for how actions would work if they were executed in the backend. We think it may be hard to achieve some desired properties (traceability/auditability, robustness to long-running actions) if actions run in the browser. (On the flip side, for quick actions, this adds an "extra hop", so we need to trade that off)

[ewferg]

I thinking adding in detail about where these will be executed is appropriate in this ADR. If there is a lot you feel like should be said regarding the trade, you could also consider a second, separate ADR.

[dandelany]

@ewferg I added a few more edits and and pros/cons to the Actions ADR, as well as a status field on all ADRs. I think we should go ahead and merge this, it's a great start and sets a good precedent for future additions.

I talked to @mattdailis re: the backend/frontend question above, and I think it's best we make that argument in its own ADR, mainly because 101 (actions) is already pretty complicated. We'll work on that this week & submit a separate PR.

[ewferg]

@dandelany Sounds good. I will go ahead and merge.