POSTED ON 26 OCT 2016
READING TIME: 5 MINUTES
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.
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:
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).
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:
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:
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.
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.
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: