Evolving B/OSS implementation considerations for CSP's

Communication Service Providers (CSPs) and Telcos represent one of the larger customer segments in Sonalake's Software Partnering business. We have developed a lot of domain experience in this vertical over many years and have built several large software solutions for clients such as Vodafone, Eir, Telia, Enet and Three among others. We have particular expertise in the area of Business and Operational Support Systems (B/OSS), and in this blog we describe evolving approaches to the deployment of these solutions.

Application based approach and license vs. service

B/OSS (and billing systems in particular) are frequently designed as frameworks requiring additional implementation services. This approach gives maximum flexibility. Customer-specific functionality can be readily introduced and planned features can be roadmapped to reflect customer demand. However:

• Deployment times are longer (software development and testing takes time), and revenue generation is usually not immediate;
• The B/OSS supplier must have excellent development tooling and management systems;
• Strong liaison between the supplier’s customer project management and product management teams is essential.

The key factor to consider is product vs. services ratio. At one extreme, we have a true common-off-the-shelf (COTS) product which requires little or no services effort to deliver (say <10% of the total vendor costs). At the other extreme is a fully custom-developed solution. Of course, most deliveries fall somewhere in between and some service costs can be buried in the license or vice versa in the vendor’s proposal. Measures, as simple as requesting access to a demo system, can help a CSP to get a good appreciation for which features are readily available and which not. A slow turnaround on offering a demo system may be a hint that it’s more designed as a framework than as an application.

Of course, the product/services ratio will vary among vendor proposals (also, as a result of mandatory customer requirements – some vendors may have corresponding features already in their products).

Extensibility

If an off-the-shelf application is purchased, the question is: how flexible is it to adapt to business changes in the future. It might be very difficult to immediately answer such a question, however the following points should be taken into consideration:

• How much configuration is supported? Is the configuration driven by GUIs or through modification of configuration files?
• Which customer-required features require modifications to the core product and which can be provided as add-ons?

In an ideal scenario, all changes should be achieved via configuration only. In practice, this is achievable only in narrow functional areas. It is nigh impossible for wider B/OSS deployments. Good software development technology does however provide solutions for solving these problems.

For instance, at Sonalake, our Verax B/OSS solutions adhere to “a core application” principle, meaning that all clients run identical NMS or Billing applications. However, we have designed our applications to be extensible without “core” recompilation in a number of ways such as:

• Application “plugins” - adding support for a new type of a device or application to the NMS or provisioning solution is simply a matter of adding a separate file archive (the plugin) to a specific directory. In this way, support for new devices, EMS systems, etc. can be quickly enabled, without costly upgrades and without interference with the core applications.
• Workflow-based application interconnection - the workflows are configurable and can be updated without impacting (or in some cases restarting) the applications themselves. This enables flexible modeling of business processes as they evolve.
• User defined reports and KPIs.

Even the Self Care Portals are built on a common framework which allows for rapid delivery of functionality that adheres to CSP-driven design considerations.

Minimizing integration hassles and protecting legacy systems

Integration of newly deployed and existing applications (or even new applications from different vendors) to reflect the provider’s business processes can be quite challenging. The problem is not primarily a coding one; more often it is in determining the integration flows, maintaining them over time as the business evolves and correct handling of the edge cases including error handling and rollback if applicable.

Which of my applications have open and documented interfaces? What degree of application functionality is accessible via the published APIs? How stable are the APIs? How many customers are using the various flavours in the real world?

What standards are used to implement these interfaces? For instance XML/SOAP or JSON/REST interfaces are generally easy to deal with; CORBA can be more difficult, completely proprietary APIs tend to pose most problems. In general, integration via database queries should be avoided.

Technically one must keep in mind that the integration of applications does not necessarily require an underlying, high end workflow engine – initial work can be done using open source packages, such as jBPM or scripting languages such as Ruby. It is important however to have a service-oriented architecture in place, to have a clean migration path to a larger system in the future.

Operating environment & scalability

CSPs tend to have different preferences and standards for their IT environments. There may be trade-offs here and there (e.g. a billing system does not run on the preferred operating system), but there are a few simple rules that can help in setting a long term roadmap:

• The B/OSS software should allow migration from a non-commercial to commercial environment;
• The software should be supported on popular OS distributions, which allows migration to the cloud/hosted services. For Linux, at least one commercial-grade distribution should be supported;
• The software should offer a choice of using both free and commercial databases (and avoid vendor-specific dependencies);
• A B/OSS application vendor should have documented sizing, scalability and high availability strategies in place to avoid performance problems and accommodating future growth.