The traditional OSS/BSS (Operational and Business Support Systems) enterprise systems and architectures currently deployed with most of the telecom service providers (TSP’s) are unable to satisfy the TSP’s need to introduce new value-added services or bundles of services at a fast pace to fight churn and ensure higher average revenue per user (ARPU).
The OSS/BSS systems for Next Generation Service Providers need to support:
These traditional OSS/BSS architectures require a lot of custom integration effort, which makes it unsuitable for satisfying the ever-changing business requirements of telecom service providers.
This article aims to introduce a generic enterprise architecture for integrating the OSS/BSS systems for a telecom service provider. It talks about the proposed architecture, its benefits, and how it overcomes the limitations of the legacy OSS/BSS architectures. The proposed architecture is based on Service Oriented Architecture (SOA), which helps the individual components and systems be loosely coupled. The services are independent of the language in which they are implemented, the location they are placed, and the platform they are built on.
The business process workflows have been designed using Business Process Management (BPM), which makes the management and maintenance of the processes easy.
Fig 2.1 Traditional OSS/BSS Architecture
Originally, these were mainframe-based, stand-alone systems designed to support the telecom company’s staff members in their daily jobs.
As depicted in Fig 2.1 above, these systems used to be very complex and tightly coupled with each other. A small change in one system could affect all the interfacing systems.
In today’s scenario, the next-generation service providers are required to manage a much more complex set of products and services in a dynamic and competitive marketplace. These systems ultimately help in enabling next-generation service providers to reduce costs, provide superior customer service and accelerate their time to market for new products and services.
The flow from placing an order for service to getting that activated involves various systems like ordering, inventory, provisioning, and activation.
Once services have been ordered, engineered, and provisioned (or designed and assigned), the services are activated on the network.
The traditional OSS/BSS architecture includes custom development of integration code, which is inadequate in satisfying the requirements of telecom service providers. Integrating systems when multiple TSPs collaborate is also a challenge. Common problems in traditional OSS/BSS architecture are:
The proposed enterprise architecture, as shown in Fig 4.1, consists of components like InAdapters, OutAdapters, Transformers, Web Services, queues and uses a BPM tool.
Considering the example of account creation, a user will access the customer care portal to submit a request for Account creation. The AccountCreation request will be placed in the ApplicationQueue of BPM. BPM will initiate a business process defined for it. It will then place a creationRequest in all the required connector queues, like billing and CRM queue. The OutAdapter of each connectorof the respective external system will process the request placed in the connector queue and will call the web service to create an Account after the appropriate transformation. The Response of the web service will be again placed in the application queue and execution of the BPM process will resume.
The proposed enterprise architecture offers number of advantages over the traditional OSS/BSS architectures:
In this example, we discuss the process flow for a typical order processing and fulfillment required by a TSP, which involves the integration of a number of systems like: CRM System, Billing System, Inventory Control System and some external systems.
The Fig 5.1 below shows the end-to-end business process flow for the ordering .
Fig 5.1 Order Process Flow
The ordering flow starts with the receipt of Customer information by the Customer Service Representative (CSR) or through the Self Care Portal. Once the details of the customer are received, the following tasks are performed till the time order gets completed:
1. CSR (Customer Service Representative) receives the customer’s relevant information. This will initiate a pre-defined business process in BPM.
2. Receipt of the customer’s information leads to Pre-Qualification of account, which includes certain checks like network/service availability in the customer’s area, validation of the customer’s address, etc. Pre-Qualification is a process in itself and starts with the validation of customer-supplied information. As a standard approach to invoke external services, BPM puts a request in GIS queue, which is consumed by the GIS OutAdapter. Like all other OutAdapters, it invokes the related (i.e. validation service) web services and puts the response in the Application queue, from where BPM picks it up and resumes the same business process.
Fig 5.2 explains the pre-qualification subprocess.
Fig 5.2 Pre-Qualification sub-process
3. Successful Pre-Qualification of a new customer leads to the creation of a customer account in the Billing system, CRM system, and other systems. To start with, Account creation sub-process puts an account creation Request in the Billing queue, Billing Out Adapter processes this request, and invokes the account creation web service in the Billing system, and places the response back into Application queue. BPM processes this response and resumes the process. If the response received from the Billing system is positive (i.e., the account gets created in Billing System) then BPM proceeds with creation of accounts in other systems, i.e, CRM system, LDAP, and Content Management system. The same process is used to create an account in all external systems, whereas account creation in internal systems is done directly, like for LDAP. However, if account creation in any of the external systems fail, then the whole process can be rolled back by BPM depending upon the rules set.
Fig 5.3 Account Creation sub-process
4. Once the account of the customer is successfully created or found (in the case of old customers), the order is created in the system followed by order validation and execution process.
5. Before the actual execution of an order, a mandatory check is performed for the customer in the billing system. This check includes checking customer’s balance, credit limit, etc. Billing connector is used for this purpose.
6. If the customer’s credentials are found valid then an Inventory check is done in the Inventory management system and relevant inventory/devices are marked reserved for the order.
7. Inventory booking is followed by the Physical Installation of devices, which are a must for the service provisioning at the client’s site.
8. A network engineer’s visit is scheduled for the physical installation of the device or customer premise’s equipment (CPE)
9. Provisioning followed by activation of services is done for the order. Provisioning includes configuring devices, network equipment, etc., for the services, and then activation of customer services is done. Here, Provisioning connector invokes various provisioning-related services provided by the Provisioning system. As a standard approach, Provisioning adapter uses its Out Adapter and puts the result back in Application Queue.
10. Provisioning and activation would require an interaction with network elements belonging to different vendors. Since, usually in a telecom network, there are heterogeneous network elements belonging to different telecom OEM vendors. There would be separate provisioning connectors for each of these external systems.
11. Once the services get activated, a notification is sent to the billing system to start the billing for the activated service. This would make sure that at the time of generation of the bill, this service is billed to the customer.
12. Activation of services necessitates the need of updating Inventory status. Hence, a notification (through Inventory connector) for updation of inventory is sent to the Inventory Management system.
13. This marks the successful completion of the order.
The benefits of service-oriented architecture for a telecom service provider have been made evident with examples quoted above. The use of connector-based architecture for communication to each of the external systems, like Billing, CRM etc., in the OSS/BSS ecosystem has made the architecture very loosely coupled. Any change in the external systems would be absorbed at the connector level without affecting the rest of the ecosystem. The use of a Business Process Management (BPM) tool makes the management and maintenance of the business processes easy.
This certainly adds to the advantage of TSP where the business processes are changing frequently due to changes in the market conditions, either due to the competition or launch of new services. Since the BPM tools deploy the business processes on a J2EE application server as an EAR, the architecture gets the benefits of all the J2EE server features like security, transaction, JNDI, remote connectivity, etc.