Cross-team building block standup meeting minutes 05-08-2021

Hello All,

Once again, please make sure your team’s documents are accessible from Teams from the appropriate working group’s folder in Microsoft Teams. If you need help with this, let me know!

If you have a use case that connects multiple building blocks, please link to it in the Logical Process Blueprint so other teams can find it: Logical process blueprint - Google Documenten

Agenda for this meeting:
• Review each group’s progress (standup!)
• Review progress on PPTs
• Reminder about using the building block definition template
• Reminder about writing down significant changes and decisions in a log under a header in your building block definition template
• Reminder to provide source for all images and diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved.
• Review last week’s key decisions and see if they’ve been addressed
• Work on the next sprint’s logical process outlines and flow diagrams

We opened with standup, this time reviewing each team’s building block specification updates, questions and changes. Highlights included:

  • Information Mediator submitted a draft specification with open questions for the Architecture team. Guidance on standardization, as well as a technical review. Moving specifications into JSON schemas and OpenAPI to GitHub. Inviting HISP working group members.
  • Registries working on Registration BB spec, discovered an additional API needed for statistics. Reviewed security BB requirements, they were quite heavy to understand. Meeting with David to clarify. Sending draft to Architecture team Friday.
  • Architecture gave an overview of the work around positioning, tendering process, ongoing interoperability work, work on document versioning, and tracking progress across groups with a milestone deliverables checklist.
  • Trevor gave an overview of his document versioning proposal, see Arch_Document_Standards_v0_2.docx - Google Documenten. Hoping to finalize by Monday.
  • Ramkumar gave an overview of the milestone deliverables checklist at milstones deliverables.xlsx - Google Spreadsheets
  • David gave an overview of how an API Gateway will be deployed from the security building block and how user authentication and authorization will work with with the IAM solution.
  • IAM will handle Provisioning, authentication/authorization and access tokens., then access token validation by a building block to get a series of roles. All application user identities are provisioned via IAM. David will identify and highlight workflows that show these steps with flows and references to OpenAPI specifications.
  • Taylor raised the issue of our OpenAPI specifications potentially having bias towards existing DPGs.

Key decisions made in this meeting:

  • All groups will create accounts and update their pages on https://discourse.govstack.global/ with key links, see Architecture Team Resources as an example.
  • All groups will cc the relevant auto-mailer addresses for each of the working groups. Any messages sent to these addresses will create a new topic in the corresponding category:

Information Mediator:
infomed@discourse.govstack.global

Payments:
payments@discourse.govstack.global

Identification:
id@discourse.govstack.global

Registration:
registration@discourse.govstack.global

Security:
security@discourse.govstack.global

  • Security(IAM) and Registration will work on flows and OpenAPI examples to show how application user provisioning, authentication and authorization. Other building blocks can use this as an example of how to interface with IAM to validate end-user authentication and authorization.
  • Applications will be responsible for mapping user roles from Security(IAM) to specific permissions on a case-by-case basis.
  • A certain amount of bias towards existing best of breed DPGs is expected. It’s a good thing to adapt APIs from existing, proven DPGs - as long as those API definitions are as minimal as possible to outline the interactions between building blocks. For example, the entire OpenIAM specification can be referenced, but building block OpenAPI definitions should only include the minimal viable subset of those APIs to achieve cross-building block interoperability.
  • Each building block definition’s OpenAPI specification will be used to validate the building block’s functionality. Ideally, example applications will be assembled during development to help evolve the standards. This should be an iterative process.

Previous key decisions:

  • Information mediator is only for securing backend requests. Some communication may be made directly available by building blocks on the open internet.
  • Building blocks MUST be secured so they don’t need to communicate through Information Mediator or API gateway - they MUST be completely autonomous from a security perspective. This means checking authentication and authorization for API and web calls instead of relying entirely on other services.
  • Payments will cover G2P and G2B use cases. OpenAPI will be done later
  • Information mediator is nearly done moving editable diagrams into github and are working on OpenAPI specifications
  • Information Mediator(Publish/Subscribe) will only send payloads to subscribers. A type and payload field will be published to the information mediator. Subscribing to the same service to a type/topic multiple times is allowed.
  • Security highlighted the need for a Networking group to handle networking-related issues, specifically firewalls, reverse proxies that have been identified as key components. They will work on an OpenAPI/Swagger specification for talking to an API Gateway building block, see below:
  • Information Mediator showed an excellent diagram highlighting a more detailed overview of how requests coming into Govstack will be handled: https://drive.google.com/file/d/1bp0DkRnITod0h96jIf6-AL2ks6NfGaoP/view
  • Payments is debating whether or not they will handle cash or not. They will handle mobile to mobile and bank payments. If they decide not to handle cash/teller/reconciliation/accounting functions, we will need a separate group for that functionality.
  • All groups will review the Data Verification and Validation - Unconditional Social Cash Transfer draft use cases at Logical process blueprint - Google Documenten
  • Groups will look at https://discourse.govstack.global/ and see how it fits their needs. See the Architecture Team Resources topic for an exampe of how groups can list their resources for public consumption. Architecture will continue to evaluate discourse.
  • Groups will fork a copy of GitHub - GovStackWorkingGroup/BuildingBlockAPI so they have a centralized, versioned repository for editable diagrams and other resources
  • Groups will provide source for all images diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved. If possible, check them into your group’s forked copy of GitHub - GovStackWorkingGroup/BuildingBlockAPI to provide versioning consistent with your document versions.
  • Groups will submit initial revisions of their building block specifications for review by the Architecture group as soon as possible.
  • Architecture will give an overview and demo of how we use github for editing diagrams

Outstanding tasks

  • Architecture will work on a flow diagram outlining how webhooks work with Information Mediator and will meet with Information mediator team to review
  • Payments will move language specific to their group from the Logical Process Blueprint Logical process blueprint - Google Documenten and link to it
  • All groups will review and link to the cross-cutting requirements of the Security building block definition Security Building Block Definition.docx - Google Documenten. Groups will review additional functional requirements that and point to those as well. Groups are free to consult with the Architecture and Security groups once this is done.
  • All teams still need to work on updated powerpoints
  • Groups can request a formal review from the Architecture group at any time.
  • All use cases that connect multiple building blocks should be linked from the Logical process blueprint: Logical process blueprint - Google Documenten
  • Transactional system of record registries MUST use a document-based approach and MUST copy all records, e.g. a doctor’s record must be copied into a snapshot as part of a prescription. If you store a foreign key, e.g. doctor’s reg number and their phone number or address changes the record will be incorrect. Therefore, documents stored in system of record registries MUST copy all the data onto the document to provide a record as a snapshot in time, and SHOULD retain references to all foreign keys/references to objects copied for auditing, e.g. to the doctor’s address and phone number record URIs. This capability will be part of the registration building block.

Thanks to everyone that attended!

Action items for each working group:
• Continue to work on your own copy of the Building Block Definition Template Building Block Definition Template.docx - Google Documenten. At least the Key Digital Functionalities, Cross-cutting requirements and Functional Requirements sections should be filled in based on the specific requirements outlined in the logical process blueprints: Logical process blueprint - Google Documenten and functional components in the logical process checklists for the use cases already covered (e.g. registration, payments and case management for Postpartum and Infant Care): Logical process checklist - registration - post partum and infant care.xlsx - Google Spreadsheets https://docs.google.com/spreadsheets/d/1_mU6HNGuiMciZhxKMHUaucyAjqy9Acrf/edit#gid=832614800 and Logical process checklist - case management - postpartum and infant care.xlsx - Google Spreadsheets.
• Ensure your Building Block Definition Template and other documents are accessible via Teams so other groups can see them.
• Review the logical process blueprint for the current sprint (Case Management - Postpartum and Infant Care) and add any comments or questions that come up: Logical process blueprint - Google Documenten
• Confirm the components for your building block designated in the logical process checklist are correct: Logical process checklist - case management - postpartum and infant care.xlsx - Google Spreadsheets
• Review the building block flow diagrams for Logical process blueprint - Google Documenten UC-P-USCT-001: Payment - Unconditional Social Cash Transfer (bank payments) - Google Documenten and UC-P-USCT-002: Payment - Unconditional Social Cash Transfer (non-electronic/cash payments) - Google Documenten
• Identify folks who could be good for the new working groups we’re spinning up: consent management, messaging, marketplace, scheduling and workflow!

Next week we can review our progress and perhaps begin another sprint!

Agenda for next week:
• Review each group’s progress (standup!)
• Review group’s documents in the context of how a specific arrow in a flow diagram maps to specific functionality in the block
• Reiterate that use cases are not to be taken as gospel, they can be rewritten and new use cases can be created that more accurately reflect reality
• It’s fine to break a building block into multiple blocks that better map to functional domains
• Reminder to provide source for all images diagrams, ideally draw.io, web sequence diagrams so they can be edited and evolved
• Work on the next sprint’s logical process outlines and flow diagrams
• Github and discourse overview

From the chat:

Here are the auto-mailer addresses for each of the working groups. Any messages sent to these addresses will create a new topic in the corresponding category:

Information Mediator:
infomed@discourse.govstack.global

Payments:
payments@discourse.govstack.global

Identification:
id@discourse.govstack.global

Registration:
registration@discourse.govstack.global

Security:
security@discourse.govstack.global
Please remember to update your key links on your pages like we have for the architecture page link aboke
Trevor’s document versioning draft:

Ramkumar’s milestone checklist:

Folks, can you disable screen sharing and video to save bandwidth? Thank you!
15:54