ANALYTICS SAAS APPLICATION ( )
Budget: $10,000 – $20,000 USD
Multi Node data modelling required across different Database Clusters or Object
Storage’s geographically scattered across global regions.
2) Data modelling should be done with read, write corruption prevention and
read/write maximum latency to be about 1 second.
3) As the consumers of the data exposed by the SaaS Platform that we are building
could be from different persona for different usecases (BI Engineer, Data analyst ,
Data Scientist, Executive, operations Manager) , the DB Schema and the DB modelling
should be catering to wide set of persona’s across usecases.
4) Flexible schema structure and dynamic “security” paradigm across different Rows
or specific fields in the DB Table (Columns) would be required across different
Data consumer personas. (RBAC, SSO, SAML, Attribute based security access control,
AWS IAM, Cognito et al)- Reference. This is a mandatory requirement.
5) SaaS platform product should have different data Producers coming from different
sources like OLTP, OLAP, ERP, CRM, REST API , NBAPI, Datawarehouse. Support for
ingesting the data from all the above mentioned Data Producers should be possible
into the SaaS platform’s DB structure.
6) SaaS Platform’s DB architecture should follow multiple Data tables approach like a)
RAW, b) Processed, c) Curated, d) Analytics serving data with different data policy
like Bronze, Silver, Gold mapped to each of the above databases.
7) Different kind of analytics and query report generation functionality /methods
should be possible from the Gold datastore of the “SaaS Platform as per above.
8) Data consumers could be using tools like Looker, AWS Athena SQL query, AWS
Quicksight, MSFT Power BI, Lucid Charts, MSFT PPT, tableaux et al.
9) SaaS Platform that we are building is going to serve customers across different
verticals like Airport/Travel, Retail, Hospitality, Smart City, Government offices,
Service providers /ISP and MVNO service providers and hence the data should be in
time series format with a second to Milli second level granularity.
10) There is a Timing window based time scheduling engine which is a key part of this
SaaS platform and hence the DB Schema should consider this in the DB Table
structure for storing the data accordingly.
DB SCHEMA TEMPLATE (SAMPLE ILLUSTRATION):
https://drawsql.app/wism/diagrams/copy-of-laravel-spark-mysql
◦ Phase-1: User Insights, Behavioural Pattern, Factors Affecting It
◦ Phase-2: Network Control
◦ Phase-3: Global Telco (Universal Open Roaming)
Phase-1 (Intended more towards User’s Behaviour)
◦ Dashboard
◦ Technology Dashboard
◦ Maketing Dashboard
◦ Business Dashboard
◦ User Behavioural Pattern
◦ Reports
◦ Predictive Analytics
◦ User Loyalty Index
◦ Captive Portal
◦ Intuitive & Responsive
◦ Widgets
◦ Content Management System
◦ Pre-Defined templates to choose from
◦ Bandwidth Management (User Policy)
◦ Per User
◦ Per Location / Zone (VLAN)
◦ Per Application / Protocol
◦ Preferential Access (e.g. prefer emails over streaming)
◦ Scheduling of user Policy
◦ Call-To-Action on Analytical data
◦ External and Internal Factors Affecting Users and their co-related decisions
Storage’s geographically scattered across global regions.
2) Data modelling should be done with read, write corruption prevention and
read/write maximum latency to be about 1 second.
3) As the consumers of the data exposed by the SaaS Platform that we are building
could be from different persona for different usecases (BI Engineer, Data analyst ,
Data Scientist, Executive, operations Manager) , the DB Schema and the DB modelling
should be catering to wide set of persona’s across usecases.
4) Flexible schema structure and dynamic “security” paradigm across different Rows
or specific fields in the DB Table (Columns) would be required across different
Data consumer personas. (RBAC, SSO, SAML, Attribute based security access control,
AWS IAM, Cognito et al)- Reference. This is a mandatory requirement.
5) SaaS platform product should have different data Producers coming from different
sources like OLTP, OLAP, ERP, CRM, REST API , NBAPI, Datawarehouse. Support for
ingesting the data from all the above mentioned Data Producers should be possible
into the SaaS platform’s DB structure.
6) SaaS Platform’s DB architecture should follow multiple Data tables approach like a)
RAW, b) Processed, c) Curated, d) Analytics serving data with different data policy
like Bronze, Silver, Gold mapped to each of the above databases.
7) Different kind of analytics and query report generation functionality /methods
should be possible from the Gold datastore of the “SaaS Platform as per above.
8) Data consumers could be using tools like Looker, AWS Athena SQL query, AWS
Quicksight, MSFT Power BI, Lucid Charts, MSFT PPT, tableaux et al.
9) SaaS Platform that we are building is going to serve customers across different
verticals like Airport/Travel, Retail, Hospitality, Smart City, Government offices,
Service providers /ISP and MVNO service providers and hence the data should be in
time series format with a second to Milli second level granularity.
10) There is a Timing window based time scheduling engine which is a key part of this
SaaS platform and hence the DB Schema should consider this in the DB Table
structure for storing the data accordingly.
DB SCHEMA TEMPLATE (SAMPLE ILLUSTRATION):
https://drawsql.app/wism/diagrams/copy-of-laravel-spark-mysql
◦ Phase-1: User Insights, Behavioural Pattern, Factors Affecting It
◦ Phase-2: Network Control
◦ Phase-3: Global Telco (Universal Open Roaming)
Phase-1 (Intended more towards User’s Behaviour)
◦ Dashboard
◦ Technology Dashboard
◦ Maketing Dashboard
◦ Business Dashboard
◦ User Behavioural Pattern
◦ Reports
◦ Predictive Analytics
◦ User Loyalty Index
◦ Captive Portal
◦ Intuitive & Responsive
◦ Widgets
◦ Content Management System
◦ Pre-Defined templates to choose from
◦ Bandwidth Management (User Policy)
◦ Per User
◦ Per Location / Zone (VLAN)
◦ Per Application / Protocol
◦ Preferential Access (e.g. prefer emails over streaming)
◦ Scheduling of user Policy
◦ Call-To-Action on Analytical data
◦ External and Internal Factors Affecting Users and their co-related decisions