...
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 |
| 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, AWS Lambda 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”), AWS LZ2fitted 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
| ||||||||
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. | ||||||||
Product name: Discrepancy Report On Payments (DROP) | Oct 2023 | Scrum team - informed | N/A | N/A | ||||||||
S3 Glacier for longterm storage | Oct 2023 | Scrum team - decision makers | See ||||||||||
Jira Legacy | ||||||||||||
server | System JIRA | |||||||||||
serverId | d2911bf3-a8c8-34ad-879e-be57beeeb8f3 | key | CCFPCM-648. | |||||||||
Can we retire the Transfer Family? |
| |||||||||||
Heuristics | Using heuristics instead of a more general matching approach. Strictest heuristics are applied first, in descending order. | |||||||||||
Report length |
| |||||||||||
How often to generate the report |
| |||||||||||
How to distribute the report |
| |||||||||||
How far back to reconcile |
| |||||||||||
How should alerts be tuned in order to deliver them to clients directly? |
| |||||||||||
Reporting dashboard |
|