T h e Te l c o R e v e n u e A s s u r a n c e H a n d b o o k

Monitoring Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .325

Scorecard Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Reconciliation Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Audit Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Specialized Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
Challenges of Building a Revenue Assurance System . . . . . . . . . . . . . . . . . . . . . .327
Build Versus Buy and the Role of COTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .327
Alternative Architectures: Hard-coded Versus Layered Applications . . . . . . . .328
The Traditional Hard-Coded Approach . . . . . . . . . . . . . . . . . . . . . . . . . . .328
The Layered Architectural Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
Step One: Architecture Design – Determining the Information Sources . . . . . . . . . .329
Operational Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .329
What Information is Needed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .331
Difficulties in Determining Information Requirements . . . . . . . . . . . . . . . . . . .332
Defining Information Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .333
Objectives for Revenue Assurance Systems Design . . . . . . . . . . . . . . . . . . . .334

Section 6 : Chapter 2 Revenue Assurance Architectural Design . . . . . . . . . . . . . . .337

Designing Architecture for Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .337

Direct Access to Operational Systems . . . . . . . . . . . . . . . . . . . . . . . . . . .339
Leveraging the Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .340
Access Layer Leverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341
Storage Layer Leverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .341
Designing Architecture for Reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .343
About COTS Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
Figure 6.2.8 Reconciliation systems design . . . . . . . . . . . . . . . . . . . . .345
Creating Architecture for Investigation and Auditing . . . . . . . . . . . . . . . . . . . .347
Issues with architecture development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
User-Interface Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
Single Point of Access/Consistent Look and Feel . . . . . . . . . . . . . . . . . . .350
Good Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .350
Data Storage and Post–Processing Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
Realities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
Political Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352
Contention Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .352