Some service types require equipment or some other allocated resource, e.g. a phone number. They also need to be managed so that if we need to activate a data service for a cable subscriber, we will need to allocate this resource from (typically) an inventory database.
For such service types, this order management step should check to see if resources are available to fulfill the order. Typical resources include customer premise equipment, port availability, telephone numbers, and so on. If resources are not available, then the order should be pushed to an error-handling subprocess.
Validating a subscriber’s order may involve integration of the following components:
For successful service activation, we need to connect to the various network servers and devices in order to activate the desired service. The complexity here is that there are many different types of servers using many different communications protocols, such as SOAP, REST, CORBA, TL1, and so on. Usually new servers will use newer communications protocols but there are still many older protocols in use today.
With service activation, the trick is to abstract the communications protocol from the business process logic. This abstraction provides the ability to plug and play adapters to third party systems with minimal or even no changes to business processes. For example, if a service provider changes from one vendor’s TV CAS (Conditional Access System) to another vendor’s equipment, the core business logic can stay intact but the adapter to the third party system will change.
The business logic can usually be broken down into the following:
Typical network servers include:
With resource allocation and service activation complete, we now move onto the next processes in our order management cycle, Installation and Activation Validation. These will be covered in the next part of the Service Order Management Series.