1. The proposal summarizes the architecture for transforming Synergy Telecom's wireless billing system including conceptual data, application, infrastructure architectures and integration approaches. 2. A microservices-based architecture is proposed utilizing AWS services like EKS, RDS, Redshift with a cloud native approach. 3. The conceptual infrastructure architecture depicts high availability across two regions with active-active application servers and real-time data replication between databases.

1. Synergy Telecom
Wireless Billing System
Transformation Proposal
28th April 2023

2. Architecture Development
• Business Architecture || Data Architecture || Application||Technology
• Security – Security Architecture
• Architecture views
• Gap analysis
• Candidate Roadmaps
Business /Data/Application/Technology (Infra/Software)Architectures
2
Conceptual Architecture
Data/ Logical
Application
Architecture
Integration
Architecture
Architecture Definition
Document t
Requirement specification
document
Candidate Roadmaps
Conceptual
Infrastructure

3. Conceptual Application Architecture
New Billing System DB Layer
New Billing System Application Layer
Bill Data
Customer Data Unbilled Usage
Payments
Platform Layer
Authentication Monitoring Notifications
Product/Billing Catalogue
Customer Account Management
Payments Processing
Bill Invoicing
Bill Processing
Bill Maintenance
Unbilled Usage Processing
Order Management
Dashboard & Reporting)
Masters
Recent Bill
Reporting DB
CONCEPTUL/BUSINESS ARCHITECTURE
Internal
User
Customer
• mS architecture with individual /group of services
supporting each functions
• TMF ODA compliant facilitate - agility,
interoperability with partner systems and
accelerate cash – to cash
• accelerating concept-to-cash.
• TMF SID schema common vocabulary across
process and systems
• Inbuilt Monitoring /Cluster management tool
• PCI/SOX compliance
Admin
Key Consideration from
Convergence
Performance
Security
PCI /SOX

4. 1. Implementation at two VPC located at two different regions of AWS
2. Each region have two application servers in active-active mode and 1 RDMS database and 1 Non RD database server + 1 Reporting DB
3. If the primary site fails, the secondary site takes over and continues to serve the traffic basis to the DNS configuration.
4. At both sites, application servers are connected to a load balancer, which distributes the traffic between the servers in respective sites.
5. RDBM/Non RDBM in VPC 1 is primary and VPC2 is secondary
6. RDBMS and Non RDBMS database servers is real time replicated
7. Reporting DB and Reporting server is only in 1st VPC
8. Database replication is set up between the primary and secondary VPCs to ensure the database is synchronized in real time
9. Firewall is deployed at the edge of both the primary and secondary network to ensure security.
User
Billing VM2
Billing VM1 Source DB (Redundancy with
Secondary using a real time
Data replication)
Source DB (Redundancy with Secondary using a real
time Data replication)
Billing VM2
Billing VM1
VPC (Region 1)
User
VPC (Region 2)
VPC Peering
Connection
Load balancer
Firewall
RDBM
Non RDB Non RDB
RDBM
Reporting
DB
CONCEPTUAL INFRASTRUCTURE ARCHITECTURE
Load balancer
Firewall
DNS
DNS
Key Consideration from Vision
• Availability
• Scalability

5. Archive Policy
• Bill /Usage Data more than 12 months Old to be
archived
• Customer/Account data inactive more than 24 months
• Applicable for Report data mart as well as Application
data
Data Architecture
• From Data perspective , considering the need for a
consist and more secure database , RDBMS is
proposed to store Customer data , Order Data, Usage
data , Bill data
• Master data including product catalogue as well as
temporary bill processing data will be stored in
temporary DB .
• Similarly services like hot Bill, payment data, billed
data of current bill cycle , Credit control data of
defaulter customer will be stored in the temporary DB
Oracle RDBMS Hadoop Temporary DB
DATA ARCHITECTURE
Application Data Layer
Reporting Data Layer
Customer Data
Bill Data
Customer Data Unbilled Usage
Payments
Account Data
Bill Data
Unbilled Usage
Data
Product Catalog Payments Data
Invoice Data Order Data
Customer/Acc
ount Data
Mart
Order Data
Mart
Billed Usage
Billed Usage Data
Bill Data Mart
Catalogue &
other Masters
Recent
Bill/Usage/Pay
ment Data
Internal
User
Customer
Admin
Key Consideration from Vision
• TMF SIF – Common Language/Process
• Security - PCI/SOX compliance

6. 1. Microservice based architecture
2. Orchestrator will be used to run microservices for
processes like order provisioning, billing and payments
3. Proposed Billing system will replace legacy Vision
billing and iVision Report layer .
4. Integration with CRM/Order Management to managed
customer account and service details
5. Billing system will get rated usage records for
generating the bills. This includes postpaid and prepaid
rated CDR (from JTTR)
6. Postpaid rated records are billed and invoices will be
created and will be published to the IFE Bill formatter to
create invoice which can be dispatched do customer .
During bill process ,tax component is fetched from the
UTE system to include in the bills.
7. Wireless Bill Comparator as well as NBS bill forecast
interface with new billing system for fetching bill data
to support customer queries on usage and charges
LOGICAL APPLICATION ARCHITECTURE
Key Consideration from Vision
• Convergence
• PCI/SOX
• Scalability
• Performance
• Availability
• Interoperable
• Common Language
New Biling System DB Layer
Microservice based Business Process Layer
Application User Interface
Platform Layer
Payments Processing
Bill Processing
Unbilled Usage Processing Order Management
Journey Microservices (Interaction Layer)
HOT Bill & Payment
[Cloud/Digital Services]
Real Time Notifications Real Time Bill Enquiry & analytics
Bill Data
Customer Data Unbilled Usage
Payments
Masters
Recent Bill
Credit Control
Recent Bill
Internal
User
Customer
Admin
Authentication Monitoring
User Transaction
Component Analytics
User Profiles and validation
Auditing & Reporting
Outstanding Bill Process
Notifications
Message Queue
Adapters
SOX/PCI Controls & checks

7. New Biling System DB Layer
Microservice based Business Process Layer
Application User Interface
Next Bill Summary
(Bill Forecast)
Wireless Bill
Compare
( Recon & Settle)
ERP(GL)
Platform Layer
Authentication Monitoring Notification
JTTR
(Rating)
Payments Processing
Bill Processing
Unbilled Usage Processing Order Management
Network
UTE(Tax process)
Customer
CSR
ETG
Middleware
Layer
Customer Interface
Channels
(Web/Mobile)
Journey Microservices (Interaction Layer)
HOT Bill & Payment
[Cloud/Digital Services]
Real Time Notifications
Real Time Bill Enquiry &
analytics
Bill Data
Customer Data Unbilled Usage
Payments
Masters
Recent Bill
6. Bill
Enquiry/Payment
mS exposed as APIs
Partner Channels
8. File based
Batch Integration
for rated usage
data for billing
(.txt file)
Digital Services Marketplace
5. Digital Service –
Customer Account
Request mS as APIs
Partner
7. Partner portal –
Customer /Bill data
exposed as mS
4.Digital Service Purchase –
Request Bill –mS as APIs
9. Batch
Integration for
Bill details to
ERP- Use ETL
tool/File
IFE
Wireless(Bill
Formatter)
10. Batch
Integration for
export bill data
for invoice
formatting -XML
API Gateway
11. SOA API integration calls over ESB to get tax
calculated for each customer part of bill cycle
12. Microservices exposed as APIs over ESB to
fetch bill details and call recon process if
required
13. Microservices exposed as APIs over ESB
to get bill details
Integratio
n ID
Integration
type
Reason Pattern
4,5,6,7 mS as API
published
over API GW
No transformation required. Scalable resilient
architecture to ensure good customer
experience
Event driven
8,9,10 Batch Involves file based data transfer –Non
synchronous ;Non real time , Considerable
data records. Involve es business logic for
Txfmn
1,2,3,11,1
2,13
mS as APIs
exposed
over ETG
Middleware
ESB exist which is already connected to
application at opposite side
Need to be real time and should be
synchronous
Involves Txfmn of data
Synchronous
INTEGRATION ARCHITECTURE
CRM
Order Management 1. Customer /Account Provisioning
2. Bill Enquiry/Payment enquiry
3. One Time char
Bill Data
Key Consideration from Vision
TMF SID/microservices – Interoperability
Pattern- Event driven integrations

8. Identity Services
Bill Processing
Invoice Creation
Payment Processing
Reporting Services
Catalog Management
GL Processing to ERP
Bill Data Export and Integration APIs
AWS EBS Volume
AWS MySQL RDS
AWS Redshift
AWS EBS Volume
AWS EBS Volume
AWS MySQL RDS
AWS MySQL RDS
AWS MySQL RDS
API Services
Container
Node1
AWS EKS Kubernetes Platform
Node 2
Node 4
Cluster 2
Cluster 3
Cluster 5 (Node 8)
UI Services
Container
Cluster 4 (Node 7)
CTRA CLOUD NATIVE ARCHITECTURE
Cluster 1
Node 3
Node 5
Node 6
Internal
User
Customer
Admin

9. Synergy Telecom (VPC 1) Region 1
Internal
User
Customer AWS
Route 53
DNS
AWS Cloud Watch
AWS Cloud Watch
Synergy Telecom (VPC 2) –Region 2
VPC Peering
CTRA TECHNOLOGY ARCHITECTURE
AWS Direct
Connect
AWS Direct
Connect
On-Premise
Applications
AD Server for
Internal users
System of Records
AWS Internet GW
AWS Network Load
Balancer
AWS Firewall Manager
Front End EC2
Back End EC2
AWS EBS
Volume
AWS
MySQL RDS
Restricted Subnet Private Subnet
Private
Subnet
Auto
scale
AWS EBS Volume
Test ENV EC2
AWS MySQL
RDS
Private Subnet
Code Review
Dev
Team
Jenkins
Orchestration
Code
Collaborato
r
Code
Integration
to Main
Stream
RTC Triggers
Jenkins
Pipeline
Trigger
Unit Test
Trigger
Static
Code
Analysis
1 2
1b
3
4
5
Trigger
Build (Ant
/ Gradle)
6
On
Failure
Raise
Defect
in
RTC
Move
Binaries to
Git
Unit Test
/ Code
Coverage
One-click
Deployment
Selenium
Test
Automation
7
8
Dev Environment
9
AWS
Redshift
Data Mart
Admin