NEW BSS ARCHITECTURE. Michael Levitin June 2015

Transcription

1 NEW BSS ARCHITECTURE Michael Levitin June 2015

2 CONTENT Actual state of BSS at the beginning of 2012 year Setting targets for improvement BSS architecture The solution of defined tasks Reached result 2

3 ACTUAL STATE OF BSS AT THE BEGINNING OF 2012 YEAR 3

4 THE ARCHITECTURE WITH A CENTRAL REPOSITORY FOR SHARED DATA BENEFITS Easy implementation for a small number of systems Open and centralized data Easy adaptation of «on the spot» High performance Andrey Voynov RND Director The architecture with a central repository is well suited for operators who serve less then 10M subscribers 4

5 TARGET ARCHITECTURE FOR

6 HIGH COST OF OWNERSHIP AND LOW TTM Multiple links between each one There are not transparent rules for common interaction A variety of communication protocols including proprietary ones Disadvantages of the old architecture Result It is difficult to add a new system Software changes are laborious High cost of ownership and low TTM It does not meet modern requirements of SLA 6

7 SETTING TARGETS FOR IMPROVEMENT BSS ARCHITECTURE 7

8 TARGETS FOR IMPROVING THE BSS ARCHITECTURE REDUCE THE COST OF OWNERSHIP Reduce the proportion of paid licenses Virtualization and linear scalability COTS hardware IMPLEMENT THE LAYERED ARCHITECTURE Separate logic and data Use open interfaces and protocols REDUCE TTM Attract third-party developers 8

9 REDUCE THE PROPORTION OF PAID LICENSES The use of NoSQL DB The absence of license fees Cassandra CouchBase LevelDB Product support is carried out by Peter-Service NoSQL products Cassandra DataMart CRAB CouchBase UFM Service Locator LevelDB CART MON 9

10 VIRTUALIZATION AND LINEAR SCALABILITY VIRTUALIZATION Hardware independence. Allows the use of mid-priced equipment Flexible allocation of resources between applications LINEAR SCALABILITY It allows if necessary to increase and decrease productivity by adding or reducing equipment Improved reliability and resiliency 10

11 Price USE OF COTS HARDWARE Compare of cost configuration DL Core DL Core HP-UX(64 core) 11

12 OPENAPI TRANSFORMATION BIS BIS SQL SQL SQL OpenAPI CustomerCare SelfCare Payments CustomerCare SelfCare Payments BEFORE AFTER Direct access to data via SQL Applications must «know» the BIS data structure The high cost of change The complex and expensive integration with other systems Each system has its own authorization, its routing and load control All applications communicate with each other via OpenAPI OpenAPI provides authorization, routing and balancing of requests OpenAPI allows to attract the 3 rd party developers 12

13 OpenAPI THE LAYERED ARCHITECTURE Applications SBMS CRM SCC RMS Mobile App Authorization / Authentication / DDoS Protection Cartridges Customer Subscriber Tariff Service Adapters BIS CRM SCC RMS Message Buss RabbitMQ DATA BIS CRM SCC RMS 13

14 MAIN CONCEPT OF LAYERED ARCHITECTURE The separation of data and logic Minimization of horizontal connections The use of open standards and protocols Each layer performs its task If possible, avoid direct DBlink Easier to find employees The layers interact only with adjacent layers All communication is constructed through OpenAPI Cheaper and faster deployment of new products If we are not satisfied with the product, we can easily find a replacement 14

15 OpenAPI HOW IT WORKS NOW Applications SBMS CRM SCC RMS Mobile App Authorization / Authentication / DDoS Protection Cartridges Customer Subscriber Tariff Service Adapters BIS CRM SCC RMS Message Buss RabbitMQ DATA BIS CRM SCC RMS 15

16 EXPERIENCE WITH THIRD-PARTY DEVELOPERS IMPLEMENTATION OF MEGAFON MOBILE SELCARE DEVELOPERS ARE FOCUSING ON WHAT THEY CAN DO GOOD TO DEVELOP MOBILE APPLICATIONS PETER-SERVICE TASKS Provide the access to third-party developers to infrastructure with a public API Keep the API documentation up today Ensure the continuity of API version 16

17 17 REACHED RESULT

18 RESULTS Lower TCO Support of linear scalability Use of NoSQL technologies OpenAPI implementation and attraction of third-party developers Reducing TTM 18

19 ROADMAP OF BSS TRANSFORMATION ChargesDB (Stage 1), storage of balancerelated events (charges, payments, adjustments) Integration of SBMS with ChargesDB Implementation of OpenAPI for SBMS ECT (Events to Charges Translator), subscription fee charging in the RT part DPI+TrafficDB+Personal Self-Service Portal solution for storage and analysis of information about subscribers traffic usage ChargesDB (stage 2), switching all applications to ChargesDB (except for the Billing Engine application in BIS) Implementation of OpenAPI for SBMS OCSDB, storage of all OCS objects for implementation of horizontal scaling for BRT ChargesDB (stage 3), switching the Billing Engine application in BIS to aggregates handling; no calls go through BIS 19

20 GREENFIELD TASK 7 branches The presence of different services and tariff plans More than 70M subscribers The presence of different services and tariff plans GOAL Unify services and tariffs in all branches SOLUTION Using the new BSS architecture allows not only to implement this task, but also significantly reduce the time and cost of the project 20

21 Thank you for attention. Good luck! Michael Levitin +7 (926) Конфиденциально ЗАО «ПЕТЕР-СЕРВИС», 2015