Addressing the Pipeline Curse


17 June 2015 | Jet Info, Speaker: Igor Samsonov


The current situation at the telecom market is anything but healthy. Operators keep fighting with third-party service suppliers for their share in user consumption. New services that emerge almost every day shrink the telecom operators’ business to merely maintaining a pipeline that serves other suppliers.

Operators follow the PCC concept (Policy Control and Charging) to expand this stripped-down business into such service suppliers themselves. This evolution is by no means easy or fast. On the positive side, however, an operator can take advantage of certain assets already at his disposal to accelerate it. For instance, operators own interactive channels connecting them to users, enjoy customer loyalty and have access to updated information on user geolocation. Of enormous value are also data on client profiles, product consumption statistics and user traffic structure.

Based on these assets, an operator can increase user spending and improve the cost to benefits ratio by deploying new popular services. On the other hand, dealing with such projects in-house does not make much sense for many reasons including (a) rapid changes in the user service market, (b) the availability of a vast number of existing services ranging from universal to exotic, and (d) the need to hire a large team of dedicated experts (analysts, software developers and testers).

A much wiser option is to find a partner who specializes in specific user services. Such partners require a convenient interface with the operator’s system to take full advantage of its opportunities. This need is met by SDP class (Service Delivery Platform) solutions, offered, in particular by Jet Infosystems (Jet Digital Service Platform or JDSP). It was developed by our company for a reason. First, Jet Infosystems’ corporate portfolio included certain platforms that had already been developed and deployed such as Jet CDP (Content Delivery Platform) and Jet CPA (Content Provider Access). These solutions could be used as a basis for the new platform. Second, Jet Infosystems as a consummate systems integrator had found a number of flaws in commercially available SDP products.

Fig. 1. Jet Digital Service Platform: Architecture
Jet Digital Service Platform: Architecture

JDSP was conceived to ensure a very short time to market. Individual business scenarios can be deployed fast without the entire platform. Newly added scenarios have no effect on those already installed.

Jet Infosystems’ engineers designed the platform to:

  • Provide Unified Customer Experience, with the operator and the partner pursuing identical service policies (supply authentic information on products and their costs, terms of use, cancellation and extension rules etc.);
  • Ensure proactive customer protection from possible abuse by partners;
  • Send any anonymous infor-mation on users and their activities upon request from partners;
  • Take full advantage of the existing operator’s platform to reduce the deployment of new systems and platforms to a minimum;
  • Involve a flexible SLA to maintain limits on partners’ interfaces and limits on client services including dynamic thrott-ling mechanisms;
  • Operate an integrated front office for all services;
  • Operate an integrated back office for customer support department and partners;
  • Feature built-in mechanisms to calculate consumption of operator services by partners and generate a variety of responses;
  • Ensure flexible configuration of business processes and services by means of a BPM (Business Process Management) engine;
  • Be capable of easy integration with existing systems and modules via standard interfaces.

The internal architecture of the platform and its external interfaces are based on open standards and protocols.

JDSP architecture may be visualized as consisting of several layers (Fig. 1), each with its design and functions.

Transports and Routing Layer

A subsystem that is responsible for interaction with external systems ran by the operator and the partners. This level involves transformation, enrichment and normalization of incoming and outgoing requests followed by their routing to the business logic level.

Domain Services Layer

A variety of services based on individual business logic elements. All domain services have a public API and may be used in many scenarios and operating schemes (including those that involve external systems).

Business Logic Layer

Business logic scenarios materialize as BPM processes (diagrams) generated by the BPM engine. Applied tasks such as notification or account debiting are addressed by using domain services. BPM generates declarative descriptions of interaction scenarios and runs them in a controlled environment.

Reporting and Monitoring Support Layer

This layer features an interface to access the business logic layer event log (processing of requests from users and providers). It also collects system performance and status indicators to supply them to external systems.

Back Office Layer

The Back Office of the system consists of a thin client with a web-based interface to provide access to key functions of the platform.

With the help of JDSP operators can effectively deal with the «content pipeline» curse and move towards marketing a variety of specialized services.

More information: http://jet.msk.su/en/about/


back

READY TO TALK ABOUT YOUR NEXT PROJECT?

×

Hello!

See examples of Jet Toolbar messages!

Find the icon in the bottom right-hand corner of this page.

Click on it and see some examples of messages that can be created with Jet Toolbar