Nimble Approach
Implement reporting function for new early-stage sports betting platform
The solution was completed on time and handed over to the client [..]. The client was very happy with the solution and the quality of the documentation.
Project Synopsis
Nimble Approach, a technology consultancy, required Yobibyte Solutions to help with a twelve week project to automate the generation of regulatory reports for a new eary-stage sports betting platform for a US based client.
The Challenge
Nimble's US based client were in the early stages of their product development. They required the automatic creation of regulatory reports to be generated and made available to the compliance regulator.
The data for these reports was to come directly from the product database. However, given the early stage of the product, the data model had not been fully defined so not all data was available.
Oh, and the solution had to be ready in twevle weeks!
The Process
With the requirements in hand, Yobibyte Solutions was responsible for designing the AWS architecture to support requirements which was to include the build pipeline using CodePipeline. This architecture was designed to create a fault-tolerant, decoupled solution whereby failures are reported to the business for manual intervention. This architecture was agreed with the end client and the build started.
Yobibyte Solutions started building out the AWS infrastructure using CloudFormation as the infrastructure-as-code choice keeping to AWS technologies. This build out included the build pipeline such that the infrastructure would be updated on commit of a change to the CloudFormation templates.
AWS EventBridge was used for cron jobs for each required report. The report generation request would be sent to a SQS queue. AWS Lambda was used to provide a function that would process each cron job trigger from the SQS queue. This would also allow ad-hoc reports to be generated if required, either by manually creating a payload for the SQS queue or by some other interface that could be developed later on.
Each generated report would be stored on a SFTP server that could then be accessed by the regulator. Should any part of the process result in a fatal error that could not be recovered from, an e-mail would be sent via SNS to subscribers for manual intervention. Any other failure that could be recovered from, e.g. the SFTP server was down, would be sent to the DLQ such that it could be retried.
The difficulty with generating these reports was the early-stage of the product development. Not all of the data required for the regulatory reports was present in the database and in some cases, the data had not yet been considered in their product. This led to discussions with the end client to understand their product and how the database could and would be structured along with the regulatory subject matter expert.
Show-and-tell sessions with the client allowed early visibility of the reports to show progress and gain feedback.
The Success
The solution was completed on time and handed over to the client via some walk through sessions and written documentation to allow them to update the reporting as their product developed.
The client was very happy with the solution and the quality of the documentation.