I was reflecting on recent progress made on open standards vis-à-vis current state of off-the-shelf billing and customer management products. Probably, we all tend to agree that softwares with open interfaces are preferable in the sense that they can be inter-operated with other softwares without involvement from vendor. Thus, life of expensive software can be elongated even when the eco-system has changed substantially. Open interfaces also enable service providers to use their in-house software development resources and minimize maintenance cost.

We also probably admit that integration is almost a routine affair for any CSP. Integration need is typically initiated by a. change in business processes to cater to specific customer segments b. to improve efficiency of operation by process simplification c. to provide holistic view of operation by extracting and presenting data from different systems d. to include new service elements into the network.

It’s a known fact that CSPs spend substantial amount of effort, time and money in continuous integration activities – most of the time integration expenses exceed cost of acquiring new softwares. Even though we agree that there have been substantial advances in software development based on open standards, the situation on the ground remained more or less same. So, what could be the problem?

If we think little carefully, we may understand the problem. Probably, it is simple to discern that when we talk about integration, we mostly allude a. linking of data and b. synchronization of processes. While the first issue is addressed by open interfaces, the second one brings us back to core issue of flexibility. A ‘partial’ solution for process independence can be thought of quickly – workflow based business support system. Workflow allows process components to be changed / developed by CSP IT group. However, it is a ‘partial’ solution since it presents us a new problem. Is it fair to expect CSP IT to dedicate resources to develop/code new process components on their own? I personally tend to disagree.

So, where does the solution lie? It lies on ‘inherent flexibility’ of your business support system, meaning basic design paradigm supports extension in a natural way. Precisely speaking - Meta programming – process functionalities are not hard coded, rather they are provided as an aggregation of domain concepts linked via simple and compact representation.

If we agree that ‘Requirements vary’ and ‘Integration is costly’, then CSPs need to a take a fresh look at their Billing and Customer management infrastructure with a view to extract more value from those and strategize for the future. On our part, Zinnia Systems is committed to provide Billing and Customer Management solutions with unprecedented flexibility to enable CSPs to create extensible and maintenance-free business support system.