Proposed Global Financial Reporting Platform

Proposed Design
Global Financial Reporting & Analytics Platform
Apr 01, 2022 Atanu Mandal
Solution Architect

TABLE OF CONTENTS
2
• Revision History
• Stakeholder Representation
• Context
• Business Requirements
• Design Risks, Assumptions and Constraints
• Proposed Solution Design
• Architecture Overview Diagram
• High Level Cost & Timelines
• Cost Benefit Analysis (CBA)

Revision History
Revision Date Author Change Description
1.0 01st Apr’22 Atanu Mandal Initial Draft

Stakeholder Representation
Role Contact Name
Solution Architect Atanu Mandal
Operational Transition Lead Xx
Enterprise Architect Xx
IT Security Xx
Service Owner xx

Context
• Description: Global Financial Reporting & Analytics Platform.
• Business Need: Client (ABC) is looking for a financial reporting & analytics platform (must be highly secured & scalable) which can be used to generate reports
for changes in prices of 2 millions stocks and to retain data for 5 years period.
Historical and ungoverned (disorganized) approach to capture data has led to the current chaotic situation for the stock monitoring team to gain insights and
unlock value from transactions which happens daily through stock exchange for its current stock volumes as below:
 Lack of coordinated BI strategy to date for legacy EDW, reporting applications.
 Extract raw data from existing transactional platform for analysis and never-ending one-off data dumps (texts, CSVs, excels).
 Explosion in MS Share points sites, File shares, MS Access DB’s and SQL DB’s.
 Net result is multiple unconnected un-usable datasets.
 No single organized data repository available to support multiple demands for stock monitoring team.
 Traditional BI Journey for (using legacy EDW ) usually turns out to be complicated, very time intensive.
• Objective: Target is to identify right platform & implement secured, cost effective and scalable solution to unlock the value / gain real insights from the
transactional data generated from 2 million stocks daily. This implementation may be done in multiple phases as below over period of 1.5 years (Phase 1 : 6
Months, Phase 2: 3 Months & Phase 3: 9 Months):
 Phase 1 (Proof of Value) : Implement “New Financial Reporting/ Analytics Solution” (initially with limited transactions) & demonstrate value
realization out of the new solution in terms of “Time to Market”, “Performance”, “Cost”, “Benefits in Potential Target Solution for Legacy EDW
Platform” etc.
 Phase 2 (Legacy Data Bulk Migration): Bulk migration of stock master data, legacy transactional data from source system in batches to report
price changes over previous years for 2 million stocks and retained them for 5 years.
 Phase 3 (Legacy App Consolidation): Any additional functionalities or possible legacy application
migration (e.g. on prem EDW) to new platform.

Business Requirements
Functional/ Technical Requirements
Phase 1:
 Target solution must collect transactional data from source systems, transform
the data & retain the data for reporting purpose.
 Solution must be designed to provide access to global users of the organization
with multiple languages.
 Implement reporting logic & requirements in new platform as per the defined
use cases to show price changes in stocks through a visualization layer.
 Automate the extract, transformation & loading of the data.
 Provide end users flexibility to customize, create reports through ready to use
templates.
 Users must be able to access the report via. desktop think client, mobile app &
web portal.
Phase 2 & 3:
 Bulk legacy data migration (old transactions) required from source platform to
new reporting platform to show the price change over previous years.
 Possible migration / consolidation of legacy EDW platform & it’s existing
interfaces to new reporting platform.
Non-functional Requirements
 Application classification : business critical
 Information classification : business / personal confidential
 Compliances : GDPR, SOX
 Security : Solution must be secured in data, system, network etc.
layer as per org. security policy.
 Data privacy : Personal data (if any) needs to be secured as per
organizational data privacy policy.
 No. of users : max. 500
 Performance: Ingestion to reporting in 10 Min. / end users UI
response max. 2-5 sec. across regions.
 Authentication : single sign on (SSO) / MFA
 Sizing : as per requirements
 Scalability/ Performance: Solution must scale & perform as per
performance benchmark.
 Environments: Production/ DR, Dev & Test (QA)
 Standard backup, monitoring
 Availability : 99.5%
 Support SLA: 24x5
 RTO : 4 hours / RPO : 15 mins
 Access control : restricted to domain users only.
 Data retention : 5 years
 Following multi languages support required:
 English
 German
 Spanish

Risks
 Based on high level functional requirements for Phase 1,
this proposed solution has been designed but at later
stage once detailed business requirements are clear then
it may need to revisit this design (to introduce new
components, integration etc. which may impact cost,
timelines).
 Any changes in design assumptions or confirmation of
open items from Business Team may impact proposed
design or solution.
 Phase 1 will be setup with limited number of integrations
with ERP only as a source system but in case this
integrations requirement changes then it may impact
overall cost, timelines etc.
 Additional licenses for Tableau may be required to
purchase at later stage if existing unused licenses are not
sufficient.
 Possible risk/ impacts due to future ERP migration etc. or
any in flight projects etc.
Assumptions
 Assuming following are the existing
applications in ABC IT landscape which
will play role in the overall solution:
 EDW Platform (Informatica &
Teradata)
 Tableau
 SAP ERP / QAD ERP
 IBM Middleware
 Assuming ABC’s ERP system holds all
stock master data, transactional data.
 Assuming that we have understanding
of ABC’s Technology Roadmap,
Strategy, IT Design Principles etc.
 Refer to following slides for detailed
design assumptions / rationales.
Open Items
 Detailed functional requirements need to gather for Phase
1.
 Detailed functional requirements & design needs to be
finalized for Phase 2, 3 & accordingly, the overall solution
components, sizing, performance etc. (including Tableau)
of Phase 1 needs to be re-assessed.
 Bulk legacy transactions migration or legacy EDW
migration (if at all) strategy, approach & solution needs to
be looked at in Phase 2, 3.
 Any decommissioning strategy for any existing legacy
applications (e.g. EDW) needs to be assessed during
detailed design phase of Phase 2 & 3.
 Confirm ERP application roadmap, transactional volumes
they handle on daily basis & decide which ERP needs to
be integrated first with the new reporting platform in Phase
1.
 Need to confirm existing Tableau license covers non-
english language for dashboard/ reporting.
Key Risks, Assumptions and Open Items

Key Design Assumptions
9
Sl. No. Design Assumptions Rationales
1
ABC has existing EDW platform (On Prem) built on Informatica / Teradata &
visualization layer provided by Tableau but EDW won’t be used for this new
requirements.
Because legacy EDW platform has limitation in terms of scalability,
performance etc. & also takes high deployment time for even a small change
in the system. Annual run cost, upgrade cost, license cost are comparatively
high. As of now, they don’t have any application roadmap / plan for EDW to
migrate due to high data volume, legacy solution complexities, criticality,
budget etc. & also they are not sure what can be their strategic platform for
EDW in cloud.
As per CBA (cost benefit analysis) it has been found that “New Financial
Reporting/ Analytics Solution” on Azure Cloud scalability, performance, sizing
flexibility, cost optimization (future run cost) etc. will be beneficial in long term.
Also in future, if Azure Cloud based “New Financial Reporting/ Analytics
Solution” proves to be beneficial then legacy EDW platform can be migrated
in Phase 3 to strategic cloud based solution.
2
Phase wise design / deployment (total 3 phases) strategy is recommended
to deploy and evolve “New Financial Reporting/ Analytics Solution” over a
period of 2 years as per below:
• Phase 1 : Initial setup of the platform & proof of value
• Phase 2: Bulk migration of legacy transactions
• Phase 3: Possible migration of legacy EDW migration
Phase wise approach has been considered to provide value realization of the
new cloud based solution & for making a strategic decision whether this new
platform will be better suite for organizational business/ technical strategy
before legacy EDW can be migrated/ decommissioned.
Also, it’s not clear with business on the detailed functional requirements at
this stage.

10
3
“New Financial Reporting/ Analytics Solution” will be setup using Azure Data
Factory, Azure Data Lake Storage (ADLS), Synapse Analytics & Tableau
Except Tableau all other components are PaaS services offered by Azure
which does not have any limitations in terms of availability (no need of DR
environment), scalability, performance, sizing etc. & also it provides better
security features (e.g. access over private endpoint rather than public rest
API) also it costs pay as you go model..
So finally, when volume of transactions will increase over the period of 5
years or in next Phase 2, accordingly your run cost will increase but client
does not need to invest huge for running this setup initially. Additionally, all
non-production environments can be paused/ stopped so that per hour
compute cost can be reduced (only data storage cost to be paid / GB/ month
basis).
4
Deployment model for “New Financial Reporting/ Analytics Solution” will be
as PaaS Azure Cloud.
As per CBA (cost benefit analysis) it has been found that “New Financial
Reporting/ Analytics Solution” deployment as PaaS on own Azure Cloud will
be beneficial in long terms of cost, security etc. with respect to IaaS, SaaS
deployment model.
5 Existing Azure Cloud platform / setup will be used for hosting new reporting
solution for financial reporting requirements.
ABC already has it’s own Azure Cloud Platform/ Tenant / Landing Zone where
all business & mission critical applications are already running. Their one of
the technology strategy is to go “cloud first” and they have number of
applications e.g. ERP, DSPA Sourcing Platform etc. to migrate over to Azure.
6 Target reporting platform will be hosted in Azure cloud (US Region).
ABC’s ERP landscape, Tableau & critical applications are based in US so
avoid any network latency issues, it’s decided to host reporting application in
US. Also 40% users are from US, 40% from EU & 20% from APAC regions.

11
7
ABC has global users across US, EU, APAC regions & number of users for
each Phases as below:
• Phase 1 : 50
• Phase 2: 150
• Phase 3: 500
As per business requirements global users are considered & to better use
existing unused tableau licenses, priority/ cost of phases limited number of
users are considered in each phases.
8
ABC has multiple existing SAP, QAD ERP Platform that holds all stock
master data, transactional records from multiple sources, stock exchanges
etc. There is an initiatives running where client is planning to consolidate &
migrate it’s ERP landscape to Azure Cloud
New financial reporting platform will need stock master data, transactional
data from their existing SAP, QAD ERPs so as to do analyse & produce the
report for price changes.
9
Existing Tableau will be used for visualization of cost changed related
reporting. But under this initiative Tableau will be remediated from Kerberos
based users authentication to SSO/ MFA based to enforce more security.
Tableau existing licenses are under utilized today & it can be used for this
new demand. Also Tableau is their strategic application for any future
reporting, visualization solution so it’s recommended to use SSO(as per their
technology roadmap) instead of Kerberos.
10
Start Integration of new “New Financial Reporting/ Analytics Solution” with
SAP or QAD ERP systems (which handles most transactions) and will not be
migrated soon to Azure Cloud (refer to Application Roadmap for ERPs.)
To get much value out of integrations & avoid any immediate risk of migrating
the new interfaces from on prem to cloud. Also this will help client to limit the
scope in initial phase & realize the value out of the solution quickly.
11
All integrations with ERP systems (multiple instances) will go through
existing IBM Middleware (on prem) i.e. . IBM DataPower Gateway / Sterling
Secure Proxy.
As per client’s Technology / Architecture Guidelines. Also this will help to
secure all connections with critical applications like ERP and also to avoid
redundant multiple interfaces with multiple ERP instances.
12
HTTPs interface will be used between QAD & target “New Financial
Reporting/ Analytics Solution” whereas SAP Connector (REST API) will be
used between SAP & target “New Financial Reporting/ Analytics Solution”
There is no QAD connector but SAP Connector (REST API) supported by
Azure Data Factory (ADF).

12
Sl. No. Design Assumptions / Context Rationales
13
“New Financial Reporting/ Analytics Solution” will be integrated with SAP &
QAD ERPs via. IBM Middle uni-directionally for stock master data,
transactional data transfer over either HTTPs or SAP Connector (REST API).
Both stock master data, transactional data from ERP systems need to be
transferred to “New Financial Reporting/ Analytics Solution” as soon as it’s
generated in ERP.
14
“New Financial Reporting/ Analytics Solution” will be integrated with Tableau
Server uni-directionally over HTTPs interface using Tableau pre-built plug-in
for Azure Synapse.
Data refresh, views will be created based on the use case & functional
requirements in Azure Synapse Analytics and Tableau will pull the data for
visualization purpose as per the schedule.
15
Tableau platform will be remediated to enforce more security in terms of
users access so Azure AD (IdP) will be integrated with Tableau for SSO /
MFA login over SAML 2.0 interface & will replace Kerberos authentication.
ABC’s security policy recommends SSO/ MFA for any new application, hence
SSO/ MFA will be used new reporting application.
16
Development, QA, Prod/ DR environments will be setup for “New Financial
Reporting/ Analytics Solution”
Standard environments setup has been recommended to maintain current &
future project software delivery for this new / strategic reporting platform. For
cost optimization non-productions. Existing Tableau Dev, QA & Prod
environments will be used in overall solution.
17
No bulk legacy data from ERP (except initial full set of master data) platform
will be migrated in Phase 1 to target reporting platform in Azure.
As per business team initial requirements & priority, it has been decided to
use this new platform initially for current transactions (with initial load of stock
master data) to showcase return on investment & value realization quickly.
18
Multiple languages (English, German, Spanish) will be configured to support
(including GUI) in using reporting platform.
Business & global users requires these minimum set of languages to be
configured in reporting application.
19
“New Financial Reporting/ Analytics Solution” will be available to be
accessed over Desktop based Web GUI & Mobile App by end users over
private encrypted HTTPs interface within network or remotely over Site to
Site VPN.
ABC’s security recommends, using encrypted HTTPs interface for any
applications GUI access by end users. Hence it will be used for reporting
application as well.
21
Customer (CMK) owned encryption keys & SSL certificates will be used for
data encryption in rest / transit.
ABC’s security recommends this for any application deployment in 3rd party
DC or cloud infrastructure.

13
22 Stock dada will be retained in new reporting platform for 5 years.
Business team wants to retain all transactional data related to 2
million stocks in the target platform as per regulatory requirements,
compliances & business requirements.
23
Azure PaaS (Azure Data Factory, Azure Data Lake Service, Synapse Analytics )
private links will be used to setup all interfaces for the solution.
For keeping any communications with Azure public services secured
& internal to the ABC’s network.
24
Only ABC’s domain users will have access to new solution GUI & no local users will
be provisioned/ maintained in new platform. All users authorization will be managed
locally in new reporting platform using claim attributes from Azure AD.
As per ABC’s security policy, it’s domain users only to access it’s own
IT applications.
25
All system/ users credentials, SSL, encryption keys, TDE keys to store centrally in
Azure Key Vault.
As per ABC’s security recommendation & policy all credentials, keys
must be stored centrally rather than storing in individual PaaS etc..
26
All network communications between Azure Cloud Vnet (Virtual Network) & On Prem
Applications (ERP, Tableau) will be secured through existing Azure Express Route
using port/ IP based rules in respective Data Center / Azure Storage Firewall, Azure
Synapse Firewall.
Notes: ASG, NSG Firewalls can’t be used with PaaS services.
As per ABC’s security recommendation & policy, if there is no strong
business requirements all network connectivity must be restricted to
private network.

Design Overview (1/6)
New multi-tier stack of “New Financial Reporting/ Analytics Solution” platform will be built & hosted on ABC’s Azure Cloud Subscription / Landing Zone as a Platform as
a Service model (PaaS) in US region.
 Web Tier Components
 Tableau (IaaS)
 Application Components
 Self Hosted IR (IaaS)
 Azure Data Factory (PaaS)
 Data Tier Components
 Azure Data Lake Storage (PaaS)
 Azure Synapse Analytics (PaaS)
“New Financial Reporting/ Analytics Solution” will use one dedicated “Self Hosted IR” of Azure Data Factory (ADF) to interact with on prem based SAP ERP systems
over SAP Connector REST API or QAD ERP over HTTPs via. IBM Middleware for fetching stock master data, daily transactions related to all stock purchase, update
etc. as per link services, pipelines with copy/ data flow (data / file transformation) jobs are setup in ADF and load into ADLS in JSON format before the file can be
uploaded into Synapse Analytics tables using SQL loader based on schedule or data refresh frequencies.
Link Services will be created in Azure Data Factory (ADF) with “Copy” , “Data Flow” activities & schedulers for connecting with “Self Hosted IR” using HTTPs over Azure
ExpressRoute for secured data transfer whereas over public HTTPs for message exchange over Azure Service Bus (due to technical limitation of ADF).
Finally, Tableau will be interfaced with Synapse Analytics using HTTPs over Azure ExpressRoute over in-built Tableau connector for Synapse & pull the data from views
for reporting/ analytics purpose to show price changes per stock etc.
End users will successful authenticate using SSO/MFA tokens from ABC’s Azure AD, will be able to access the Tableau application within ABC’s network or remotely
via. site to site VPN using either Mobile App or Web Portal. All HTTPs (encrypted) web traffic from end users GUI client (e.g. Web GUI or Mobile App) will passthrough
Data Center based firewall & land into Tableau applications.

Azure Data Factory (ADF)
Name ABCDataFactory01
Region US East
Type Data Factory (V2)
Private Endpoint Enabled
Azure Data Lake Storage Gen2
Name ABC ADLS 01
Region US East
Tier Standard/Cool
Storage Replication ZRS
Type StorageV2
Container Access Level Private
Data Lake Storage Gen2 Enabled
Firewalls Enabled
Azure Synapse Analytics
Name ABCSynapse01
Region US East
Following are the high level technical profile details of production ADF, ADLS & Synapse Analytics PaaS services:

 API & Interface Details:
SOURCES DESTINATIONS INTERFACES DIRECTIONS PHASES USE CASES
QAD ERP ADF https uni-directional phase # 1
For capturing stock master data, transactions (e.g. stock
purchase, stock sell, stock price change etc.) from QAD ERP into
reporting platform component i.e. ADF.
SAP ERP ADF REST (https) uni-directional phase # 1
For capturing stock master data, transactions (e.g. stock
purchase, stock sell, stock price change etc.) from SAP ERP into
reporting platform component i.e. ADF.
Self Hosted IR ADF https uni-directional phase # 1 IR sends copied data/ files to ADF
ADF Self Hosted IR https uni-directional phase # 1
IR checks for control info from Azure Service Bus (ADF).
ADF ADLS REST (https) uni-directional phase # 1
ADF passes the JSON files to ADLS for storing it for further
processing in particular path.
ADLS Synapse REST (https) uni-directional phase # 1
JSON files are parsed & loaded into target tables in Synapse
Analytics (Serverless SQL Server).
ADF, ADLS,
Synapse
Azure AD saml 2.0 uni-directional phase # 1
For secured authentication & authorization purpose using
centralized IdP (Azure AD).
Tableau Azure AD https uni-directional phase # 1
Transformed/ processed data are published to Tableau for further
reporting purpose.

 Data Security:
 Data in Rest will be encrypted in following Platforms using CMK (Customer Managed Keys) by generating data encryption key (DEK) from Azure Key Vault.
 Azure Data Factory (ADF)
 Azure Data Lake Storage Gen2 (ADLS)
 Azure Synapse Analytics
 On Prem Self Hosted IR
 Data in Transit will be encrypted for all https interfaces (both Private & Public APIs) using SSL Cert. (ABC / Microsoft Managed Cert).
 Enable TDE (Transparent Data Encryption) in Azure Synapse Analytics (Serverless SQL Pool) for encrypting database files.
 ABC’s data will be segregated / isolated logically from other customers data in Azure PaaS platform.
 Legacy transactions from ERPs to this new platform will be done over secured synchronous (HTTPs) or asynchronous (sFTP) APIs.
 All transactional data, reports etc. will be retained in Azure PaaS platform for 5 years.
 Client’s data must be removed/ destroyed during retirement of Azure PaaS platform in future.
 Network Security:
 Existing Azure Subscriptions (Prod & Non-Prod) with respective security zones (Vnet) & private subnets will be used for deploying managed instances of Azure
ADF, ADLS & Synapse Analytics.
 All IP Connectivity’s will be secured using Firewalls in Data Center, Azure Storage Firewall, Azure Synapse Firewall.
 End users HTTPs traffic will be internal to ABC’s Network & routed from ABC’s DC to Azure Platform. Externally, all such access will be allowed only over IPSec
VPN Tunnel to ABC’s DC.
 Azure PaaS (ADF, ADLS, Key Vault etc.) services will be accessed over Azure Private Links/ Private Endpoints.
 All network connectivity’s between ABC’s DC & Azure Platform Landing Zone will be via. Azure ExpressRoute Circuit using Azure vWAN.
 Only trusted Azure services or IP traffic from Azure Vnet/ On Prem DC (via. ExpressRoute) can access Azure Data Lake Storage Gen2 or Azure Synapse
Analytics.

 System Security:
 Only managed instances of multi-tenant Azure PaaS services (Azure ADF, ADLS & Synapse Analytics) will be deployed.
 All Azure PaaS services will be registered, managed & controlled from ABC’s Azure AD dedicated tenant.
 Secured Azure ADF connectors (SAP etc.) will be used for encrypted connectivity with SAP, QAD ERP systems.
 Credentials, SSL, encryption keys, TDE keys to store centrally in Azure Key Vault.
 Azure PaaS systems are patched periodically (as per Microsoft Azure schedules).
 Azure cloud monitoring is enabled for all Azure PaaS services.
 All end user's mobile devices must be secured, controlled using ABC’s MDM software (Microsoft iTunes) before installing Tableau Mobile App & having access
to ABC’s stock related data.
 Identity & Access Management:
 All users access control (authentication/authorization) to Self Hosted IR via. On Prem AD.
 All users access control (authentication/ authorization) to Azure PaaS platforms (Azure Data Factory, Data Lake Storage, Synapse Analytics & Key Vault) via.
Azure AD / RBAC (Role Based Access Control).
 Privileged users access to be secured via. Azure SSO/ MFA.
 All App/ PaaS to App/ PaaS authentication/ authorization will be controlled using Azure AD Service Accounts (SPN) or managed ID.
 Azure Key Vault will only be Accessed by Data Factory, Data Lake Storage & Synapse Analytics using managed IDs.
 Least possible users' permissions will be provisioned in Active Directory.
 Only ABC’s domain users will have access to the target reporting & analytics platform.
 No local users will be provisioned/ maintained in the platform.
 End users web access will be available via. Azure My App Portal (SSO & MFA) or using Mobile App.

 Hosting & Operational Details:
Key Operational Factors Azure PaaS Services On Prem Tableau Server
Sizing / Dimensions Fully managed PaaS environments (no sizing required)
Additional sizing has been considered (ref. to following slide)
based on additional users & transactional data.
Tenancy Azure cloud (multi tenancy) N/A
Performance
Fully managed PaaS environments (will auto scale to
meet performance benchmark)
Additional sizing has been considered (ref. to following slide) to
cater the performance benchmark.
Scalability Fully managed PaaS environments On prem based Tableau has limited scalability.
High Availability Fully managed PaaS environments (HA) On prem based Tableau server is Highly Available
DR (RTO/ RPO)
Fully managed PaaS environments (ZRS) with inbuilt
HA, DR setup & will meet RTO : 4 hrs & RPO : 15 mins
requirements.
On prem based Tableau server does not have a DR setup but
needs to be planned after Go Live to expedite this solution
delivery.
SLA 24x7 24x7
Availability 99.5 % 99%
Backup & Recovery
All backups are managed automatically and maintained
in Azure blob storage.
Database : daily incremental & weekly full backup
Application : daily full backup.
Monitoring Azure monitoring tools On premises DXIM monitoring tools.
Notes: Self hosted IR instance has a standard sizing (vCPU - 2, RAM - 4 GB, Storage - 100 GB) for integration purpose

Dimensions & Sizing for Legacy Tableau Server
Dimensions Web Server Application Server Database Server
vCPU 2 Cores 2 Cores 2 Cores
Memory 6 GB 8 GB 6 GB
Storage 500 GB 500 GB (Internal HDD) / 3.5 TB (Ext. Azure) 1 TB
Operating System Windows Server 2019 Standard Windows Server 2019 Standard Windows Server 2019 Standard
Database NA NA Microsoft SQL Server Enterprise Edition 2019
Dimensions Web Server Application Server Database Server
vCPU 4 Cores 4 Cores 4 Cores
Memory 10 GB 16 GB 12 GB
Storage 1 TB 2TB 4 TB
Operating System Windows Server 2019 Standard Windows Server 2019 Standard Windows Server 2019 Standard
Database NA NA Microsoft SQL Server Enterprise Edition 2019
o New Tableau Server Sizing (Production):
o Existing Tableau Server Sizing (Production):
Key Factors (Transactions Vol., Interfaces, Users etc.) for Phase 1 Performance Benchmark / Retention
o Add. users : 500
o Add. concurrent users.: 10% 500 = 50
o Daily transactions / stock: 10
o Stock master data records : 2M
o Daily transactional for 2M stocks: 20M
o No. of reports : 25
o No. of interface : 1
o Transactions growth Y-o-Y : 10%
o Master data growth Y-o-Y: 10%
o Avg. size of transaction : 10 KB
o Avg. size of reports: 1 MB
o Ingestion to reporting in 10 Min.
o End users UI response max. 2-5 sec.
across regions.
o Retain data up to 5 years.

SAP ERPs
Architecture Overview (1/2) – Building Blocks/ Context Diagram
QAD ERPs
Synapse reconciles, merges records with
master data & produce views for Tableau
Report
Data
Transactions &
master data
ETL Layer
Source of stock master,
transactions data
ADF ingests millions of data daily from ERP, transform the file, data & load into ADLS.
Finally data gets parsed & loaded into Synapse SQL pool tables as per data refresh
schedule.

Architecture Overview (2/2) – Component Diagram
24
Azure Vnet / Default Private Subnet
Data Center # 2
HTTPs (Private Link)
over ExpressRoute
over ExpressRoute
On Prem AD
Kerberos
Self Hosted IR
Private Link
Azure Key Vaults
Private Link
Private Link
Azure Cloud (US East)
Private Link
Private Link
REST API
REST API
REST API
HTTPs (Public Endpoint)
Data Center # 1
Middleware
QAD ERPs
IIB/
Data
Power
Gateway
SAP ERPs
Data Factory Azure Synapse Analytics
Data Lake
HTTPs
RFC (IDoc)
RFC (IDoc)
Web Portal Access
Mobile App Access
HTTPs (On Network)
HTTPs (Site to Site VPN)
Developer/
Azure Admin Console or CLI Access
Cloud Security
HTTPs
HTTPs (Public)
SAML 2.0 (Public)
Azure AD Tenant
SAP Connector
(REST API)
over ExpressRoute

High Level Cost & Timelines (MVP)

Initial Project Timelines (Phase 1)
Sprint 1 (6 Weeks) Sprint 2 (8 Weeks) Sprint 3 (10 Weeks)
 Detailed functional requirements (critical
reports in scope).
 Perform high level design, low level design,
interface design as per scope.
 Setup initial Azure PaaS Env, Azure Key
Vault & Integrations.
 Manual sample transactions, master data
loading into Azure Blob Storage for ADF to
ingest locally.
 Configuration/ develop Azure PaaS with use
cases, rules, business logic and connect
with Tableau (existing).
 Provide user access to Tableau.
 Develop 1 or 2 critical reports in Tableau for
showing immediate outcome.
 Add. functional requirements.
 Setup IR & integrate with ADF.
 Setup interfaces with Middleware, SAP/
QAD ERP instances.
 Bulk upload of all master data, start
transactions/ master data flow from ERP to
ADF.
 Develop additional use cases, rules,
business logic in Azure PaaS Env.
 Remediate Tableau Env. (in place upgrade)
with additional hardware & SSO integration.
 Develop all required reports as per business
requirements in Tableau.
 Final functional requirements.
with additional hardware.
Minimum Viable Product (MVP)
(Priority -1)
(Priority -2)
(Priority -3)
6 Months
reports in scope).
ingest locally.
QAD ERP instances.
ADF.
(Priority -1)
(Priority -2)
 Final functional requirements.
with additional hardware.
reports in scope).
ingest locally.
QAD ERP instances.
ADF.
(Priority -1)
(Priority -2)

Initial Estimate (Phase 1)
Key Notes:
1. All costs above are assumed based on few assumptions / notes, added for each line items
2. This total cost only consider Phase 1 scope (Prod, Dev & QA)
3. Additional 20% contingency considered as low level requirements are not clear & 3rd party vendor final quotes may change.
4. Any additional licenses (if required) for Tableau is not included here.

Cost Benefit Analysis (CBA) – Phase 1 Scope
Sl. No
Key Comparison
Factors
Option -1
Existing EDW Platform
Option -2
Azure Cloud PaaS
Option 3:
SaaS Application
1 License Cost Existing No Additional Cost Additional Cost
2 Deployment Time ~ 9 Months ~ 6 Months ~ 5 Months
3
Future Infra Upgrade
(3 Years +)
Additional Cost No Additional Cost No Additional Cost
4
Future App Upgrade (3
Years +)
Additional Cost No Additional Cost No Additional Cost
5 Scalability Additional Cost No Additional Cost No Additional Cost
6 High Availability Additional Cost No Additional Cost No Additional Cost
7 Disaster Recovery Additional Cost No Additional Cost No Additional Cost
8 Up Time SLA Additional Cost per SLA 99.5% 99.95%
9 Solution Complexity High Medium Low
10
QA / Dev
Environments
Existing Additional Cost No Additional Cost
11
Project Cost (One
Time)
$550,250 $395,640 $425,000
12 Annual Run Cost $90,000 (Additional) $45,000 $70,000 (License + Support)
5 Years
Savings
(Run Cost)
($225,000)
Immediate
Savings
(Project
Cost)
($154,610)
Long Term
Run Cost
Optimization
(post EDW
Migration)
Key Long Term Benefits:
1. Highly scalable, adaptable reporting & analytics solution as per ABC’s “technology roadmap & strategy”, which can be used for
legacy EDW migration in Phase 3 for building centralize reporting platform for ABC by reducing complexity, adding agility in
business & optimizing existing annual run cost etc.
2. Address longer time to market (T2M) concerns of legacy EDW platform by business team.
3. Business benefits from stock price change related report & statistics based on historical data.

Proposed Global Financial Reporting Platform

Recommended

Recommended

More Related Content

Similar to Proposed Global Financial Reporting Platform

Similar to Proposed Global Financial Reporting Platform (20)

Recently uploaded

Recently uploaded (20)

Proposed Global Financial Reporting Platform