This page captures key decisions made in the course of development.
Decision | Date (est) | Parties | Rationale | Options considered |
|---|---|---|---|---|
Project operations | ||||
Product name: Discrepancy Report On Payments (DROP) | Oct 2023 | Scrum team - informed | N/A | N/A |
Documentation storage | PENDING | Scrum team - decision makers | SharePoint Confluence GitHub Wiki README | |
Version management is done via Jira fix versions, GitHub tags, and package version | Scrum team - decision makers | |||
DROP and its API have separate versions | Scrum team - decision makers | |||
Infrastructure and tooling | ||||
AWS hosting | Spring 2022 | Scrum team - decision makers | Given our product will spend most of its time inactive, periodically scaling up in response to large data submissions, a serverless implementation is the best fit to design for minimal compute cost. | OpenShift OCP AWS LZ2 |
AWS Lambda | Spring 2022 | Scrum team - decision makers | AWS best practice serverless implementation (see “AWS hosting”), fitted to our data needs (Kinesis deals with larger volumes). | AWS Lambda AWS Kinesis |
SNS | Spring 2022 | Scrum team - decision makers | ||
AWS Transfer Family | Summer 2022 | Scrum team - decision makers | ||
RDS | Spring 2022 | Scrum team - decision makers | Given our product’s goal to identify relationships between datasets, a relational database is the best fit and RDS (PostgreSQL) is the AWS best practice implementation for our expected database usage. | RDS (PostgreSQL) DynamoDB (NoSQL) |
S3 Glacier | Oct 2023 | Scrum team - decision makers | Glacier is a low cost solution for long-term storage. It is used on this project to archive files (submitted data and reports) that are older than 3 months. | See CCFPCM-648 - Getting issue details... STATUS |
Client/user experience | ||||
API Services Portal | ||||
Roles | ||||
Data submission | Because files are being pushed to DROP, our product includes custom parsers to import the contents of supported file types. Location and payment method tables. | SFTP (push or pull) JSON API Parsing | ||
Reporting | Generated daily, sent manually. | |||
Alerts | Sent to payment inbox. | |||
Features | ||||
Storing data | “we are saving the entire the ten file as a jsonb column, we are storing data that we don't use that is specific to the general ledger stuff” | |||
Removing the JSON -> flat file parsing | “we're not currently planning to produce the gl generator flat files for the ministry-client” | |||
API upload for all supported file types | Oct 2023 | Scrum team - decision makers | The AWS SFTP transfer family is a significant cost so we would like to provide users with options to replace it. Since BCM submits file that we already have a parser for, a file upload API represents minimal impact to existing behaviour. | We were unable to identify an existing SFTP server we could pull from (unable to eliminate the transfer family). We considered whether our users could adopt a JSON-based API, but concluded the timeline for BCM to be able to do this would be too far out. |
Can we retire the Transfer Family? | PENDING | |||
Heuristics | Using heuristics instead of a more general matching approach. Strictest heuristics are applied first, in descending order. | |||
Report length | PENDING | |||
How often to generate the report | PENDING | |||
How to distribute the report | PENDING | |||
How far back to reconcile | PENDING | |||
How should alerts be tuned in order to deliver them to clients directly? | PENDING | |||
Reporting dashboard | PENDING | |||