2023-03-20 Architecture WG Meeting Notes

Finished the second round of reports - in the hands of the DOI
Same results as the first round
Feedback provided to the carriers was not integrated into this - they didn't have an opportunity to fix data issues where needed and if applicable.
Still moving fwd successfully - DOI ready to take the next steps but still defining what these will be

B. Ken Sayers - Mississippi Zeta POC.

No new news - still in internal discussions with the carrier
Still seeking the approval to move forward

C. Jeff Braswell - Test Net Update

Senofi is finishing their migration to the newer platform using HL Fabric - some of loose ends on this tied up. This will be central platform moving forward that will accept carrier test data.
Peter is out this week but a call out has gone to carriers to have data prepared; this may be sent in before Antley returns
An initiative is also ongoing to try to engage Hanover; this is the next step to demonstrate use of the test net and it will move the team a step closer to the production phase.
Also interest from Ken in using the data AAIS has
Much will happen in the next few weeks

D. Jeff Braswell - Infrastructure Working Group Update

Consolidation of the code base
Decision about doing a merge versus a clean branch with the latest code; the IWG chose the latter to avoid disturbing the ongoing work.
Moving toward organization of repositories into manageable elements distinguishing major subsystems.
IWG is also investing the time to bring infrastructure partners up to speed on the work Senofi has done on HL Fabric operator - to accommodate this, the team is organizing calls in which information can be shared for the Chainyard people.

E. Ken Sayers - Architecture Decision Capture Template

RRDMWG - a discussion arose about specific practices that might or might not be adopted re: managing the schemas of the database.
It was requested that we document said architectural decisions in some consistent way
Today's discussion concerns how said decisions are recorded. One example: HL Fabric. How was it chosen? What role is it filling? This question has arisen many times - we need to be prepared and resourced (resourceful) when it is asked. This will also ensure a consistency of response.
The first step: deciding how architectural decisions are captured (a meta decision about making decisions)
Options to be explored today and consensus sought.
Decisions to be made
1. How do we capture decisions? Where do we keep them? And how do we govern them?
  1. Common thinking in the past: if decisions are not so controversial they need less consensus.
  2. However, more controversial decisions need clarity on what, who was part of the decision, how was it reached?
  3. Options for where to put it? (e.g., Github)
  4. The governance of it (How do we manage the acceptance of an architecture decision as part of our architecture?)
  5. Suggestion: JB - as a test case, the group could start with something like the decision to use MongoDB ahead of PostgreSQL.
  6. KS: would prefer to start out with the documentation method before diving into the tech decisions themselves - i.e., the basic process of doing it with the tool and the discussion points.
  7. Request to group for options - suggestion from Ken wrt adrgithub.io ('ADR' - Architectural Design Records) - a process that captures architecture decisions, maintains them in a repository. Can only become difficult if there is more than one repository for a given project. Also a potential issue that non-developers aren't necessarily all familiar with Github.
  8. To Ken the most valuable aspect and the most pertinent to openIDL's needs is the template provided at https://adr.github.io/madr/ (Markdown Any Decision Records) - a template for captring architectural decisions in markdown. Lightweight format, documentation for it, a template that is available. Basically laid out as a main page (in wiki). In confluence, you can click on the decisions individually to se what they are. Contents of MADR are fairly straightforward - goes through the following:
    1. status
    2. date
    3. deciders
    4. consulted
    5. informed
  9. Suggestion arose that a repository might be advantageously created that is specifically for documentation apart from the other repositories.
  10. Documents must be easy to manage - so a light markdown based implementation is preferable - editing without downloading (possible in Github) - leaving a record in the repository.
  11. Questions to group about other options (other than ADR/MADR) they would consider.
    1. Faheem: ADRs are great, but it also depends on the degree the documentation is done - (how granular?) - possible to lose the picture if you do too many ADRs
    2. Faheem:@ hanover - two templates: a technology selection template (opposing forces, requirements, options, costs - similar to adr - then you make a recommendation). Similar to adr but at a higher level. They also use standard documentation templates, diagram-heavy, etc., to walk through architecture.
  12. It was stressed that consequential/pivotal architectural decisions are the ones that most need to be documented
  13. Ken asked Faheem if it would be possible to share the Hanover's templates, and Faheem agreed to look into this.
  14. Goal in working with ADR: end with dozens of these not hundreds.
  15. No additional templates or processes suggested.
  16. Ken suggested that we start with ADR perhaps supplemented with additional fields added by Faheem from his experience at the Hanover, and then start trying to flesh out secondary and tertiary areas of the form, such as 'Technology Selection Template' and 'Document Template.'
2. Wrt decision of where to put records - will go into wiki for now, perhaps can be put into github later.

GMT20230320-183222_Recording_1920x1080.mp4

Time	Item	Who	Notes

Space shortcuts

Page tree

Date

Attendees:

Agenda:

Notes:

Documentation:

Notes: (Notes taken live in Requirements document)

Recording: