purebill.com

Stephen Jones writing on billing and application migration

When will an open source billing platform emerge?

Summary

Billing satisfies the necessary conditions for an open source / free software project with its requirements for mission-critical performance and stability. Whilst billing is unlikely to be an 'itch' scratched by an individual developer, a large business (or industry group) may solve common billing requirements by developing (or sponsoring) a basic billing platform / application that is subsequently improved.

Core billing functions apply consistently around the world with only local variations in areas such as taxation. A business' new billing needs (or replacement of an existing platform) could use a basic, open source billing platform as a base that is customised / configured to their specific needs. Enhancements and new development performed by businesses could be donated back / shared with an open source billing project for use, testing and improvement by others. Each individual business could leverage their development budgets by benefiting from the work of others and linking into a billing community with shared needs.

A common software base could be configured into distributions catering for the complexities of different industries with, for example, separate distributions prepared for water retailers and full service telecommunication providers.

Billing solutions presents long-term business challenges

Billing systems' software selection necessitates businesses making choices with long-term technical, contractual and operational challenges. Once deployed, billing systems may operate for a decade or more. Challenges include:

Reduced vendor choices / longevity - At the high-end, billing vendors have been consolidating (by merger or acquisition) leaving businesses with fewer choices when selecting a billing platform. Smaller vendors may not have the financial strength to provide long-term support, or may be purchased by larger vendors broadening their market offerings.

As vendors' billing platforms are merged, their ongoing development cycle is often slowed as each existing software base is merged into a consolidated billing solution reflecting the 'best' of the original offerings. New development may be delayed whilst this merging process is performed. This delay is a consequence of dividing an individual vendor's finite development capacity.

Development dependencies / delays - During the merging process, the vendors' customers (i.e. billing businesses) may have their business needs delayed due to capacity constraints in development. A vendor's largest customers may have their needs attended to, but smaller billers will have to wait until the vendor's roadmap includes what they need.

Proprietary billing vendors do not make their source code available. Businesses with new billing requirements may be constrained by their supplier's (i.e. billing vendor's) ability and inclination to modify the base software to address individual business' billing specifics. Faced with these constraints, businesses may choose to build workarounds that deliver their immediate needs, but this approach weakens strategies that preferentially select productised 'off the shelf' solutions over bespoke systems.

Vendor staffing constraints - Billers must depend on the vendor's resources when a new billing system is implemented, or when major changes are made to an existing implementation. Internal staff and consultancies can assist, but some changes can only be performed by vendors. This dependency rests on the privileged access to the billing system's source code and deeper experience with the vendor's solution.

A vendor's win of a large billing project elsewhere (e.g. a business' competitor) can absorb all the vendor's (proprietary) developers, constraining other business' ability to modify their billing operations and market offerings. The vendor can hire additional staff, but these people will not be familiar with the vendor or their software impacting the level of 'experienced' assistance available to the biller's implementation.

Platform dependence - Billing vendors install their billing platform on specific hardware and operating system combinations. These combinations will become obsolete over time, with either the hardware, hardware vendor and/or operating system becoming unsupported. As each platform piece becomes obsolete, the biller's business will need to migrate to a contemporary platform secure in the knowledge that another move will be required in a few years. Sustaining older platforms can be done, but only with a price premium.

Supplier monopoly - Once a biller has chosen and implemented a proprietary billing system, their business has become dependent on the success and innovation of their chosen vendor. The biller will have invested in the purchase and integration of the chosen vendor into their operational environment. The biller's staff will have been trained in the vendor's product.

Aside from configuration changes, the biller must work through their vendor when changing the underlying system, and the timing ('roadmap') of changes will depend on the vendor's timeframe rather than the biller's. A small biller may not have enough clout to insist on a change if the 'vendor's' chosen direction and the biller's do not align.

How an open source billing platform might address these challenges

Vendor independence - A business with full access to their billing system's software code has a choice on how their support and development are performed. Some support and development may be performed in-house, other projects by outside contractors, and still others through shared enhancements with peer billers.

An open source billing project could develop a community of users (billers) and support (consultants, programmers, analysts) that would facilitate the development of new functionality, improve the existing software, and assist with problem identification and resolution. The biller could seek answers to their questions outside their own organisation, and their own staff could support others elsewhere. This approach would have the effect of increasing the pool of knowledgeable staff available to each biller.

Development choices - Billers could develop their own modifications or choose external parties to do it on their behalf. Changes specific to one business may have little applicability, but many would have applicability across the billing community. Water retailers may have specific requirements that did not apply to ISPs and vice-versa.

Businesses contributing their enhancements back to an open source project increase the pool of developers familiar with their systems, improve the chances that unseen bugs are detected and establish goodwill amongst users (billers) who might work with them to solve problems in the future.

An open source billing project would not depend on one organisation's ability to fund and perform system changes. Billers around the world would be able to make changes to their own systems as they required and would be able to use / contribute new functionality freely.

Larger developer pool - Billers would be able to choose from a wider range of developers than are available from one organisation. Developers would be able to learn about the billing system by downloading the source, installing it themselves and running it to understand its operations. Billers choosing their next billing system could also do this to see if an open source billing system met their needs.

Long-term support - An open source billing system allows the biller to decide how long their system was retained and when it was upgraded / replaced. Since the biller has access to the full source code, they could choose to retain and modify their current version, mix-and-match functionality from a contemporary version, or upgrade with each new release. Support could be delivered by the biller's choice of providers, and these arrangement can be modified over time at the biller's discretion.

The open source software could be written to minimise dependencies on specific hardware / operating systems. This would be helped if all other software components of the system were also open source.

Multiple billing instances without additional licensing costs - Billers would be free to operate as many billing instances (development, production, sandbox, training) on their choice of hardware with no additional licensing costs. If a biller's business grows, the costs of an upgraded billing platform will not depend on the billing system's software licensing costs.

Development influence - A biller with installed proprietary software can only develop business functionality at the pace of their software vendor. If the biller is not a major vendor client, their direction conflicts with the vendor's corporate direction, or the timeframes doesn't match the biller's needs there may be little the biller can do. With an open source billing application, the biller could change their application themselves using internal staff or an outside organisation. The changes might be kept within the biller if they were specialised (e.g. linkage to an internal application) or might be contributed back into an open source project.

Is billing suitable for 'open source'?

In his essay 'The Magic Cauldron' (included in the book (essay collection) titled 'The Cathedral and the Bazaar'), Eric Raymond explored the funding models and reasons why a software project might be developed using an open source model rather than a proprietary one.

In this essay he wrote that:

'In summary, the following discriminators push towards open source:

(a) Reliability/stability/scalability are critical.

(b) Correctness of design and implementation cannot readily be verified by means other than independent peer review.

(c) The software is critical to the user's control of his/her business.

(d) The software establishes or enables a common computing and communications infrastructure.

(e) Key methods (or functional equivalents of them) are part of common engineering knowledge.

Each of these discriminators are present in billing.

Reliability/stability/scalability are critical - Billing is a business' critical path for turning products and services into money. Whilst customers will be serviced by other systems (e.g. a telephone network, gas distribution, tollway or email service), billing provides the basis for justifying the money collected from customers. Prepaid totals will be depleted through billing processes; postpaid balances will be collectable based on the bills sent to customers.

Businesses require platforms that can scale as their customer base and product offerings grow. Business systems must be dependable in their operation (i.e. available and working) or the flow-on impact will hurt the business' ability to serve their customers ('the computer is down / slow') and determine accurate financial positions ('we haven't finished running EOM / the bill cycles / payment processing...').

If billing fails, falls behind or is viewed as inaccurate, a businesses' existence can be threatened. This was demonstrated in Australia where the billing of the (ex-) telephone company 'OneTel' was delayed and it failed to charge for all the calls customers were incurring. (These problems were in addition to other systemic problems present at OneTel.)

Verified correctness of design and implementation - Billing systems are complex and require careful testing and monitoring to confirm their operational correctness. New system development and configuration changes (e.g. pricing) will each introduce the potential for billing errors. Verification of complex billing (e.g. corporate customers) can require detailed manual examination to confirm that billing was performed correctly.

The software is critical to the user's control of his/her business - Businesses with more than a few thousand customers and/or services will find it expensive to perform billing efficiently without excessive manual costs. Billing is critical to how and when a business is paid for its work / products / services, and the bills sent to customers are the biller's public face. Each of these situations makes the choice of billing software critical to the accurate control of a biller's business.

Establishes or enables a common computing and communications infrastructure - The applicability of this discriminator will vary depending on the scope of a business' billing implementation. Those implementations used by only one organisation will have less of an impact when billing fails or operates badly.

There are at least two circumstance where billing is part of shared infrastructure and where failure or defective processing can generate widespread impact:

Wholesale: A business that wholesales its network and/or other offerings to other reseller (retail) businesses may use its billing system to mediate how, when and the charging of transactions sent to the resellers. In this circumstance, failure of the wholesaler's billing platform can materially impact the resellers' ability to understand what their customers have consumed and perform their own (retail) billing for those transactions.
Billing on Behalf: Billing performed 'on-behalf' of another organisation (e.g. outsourced by a retail provider) will impact the provider's market perception if delayed or incorrect. Businesses operating a billing bureau that performs billing 'on-behalf' of many retailers, will have a much broader impact on its own customers if its billing fails or performs incorrectly.

Key methods are part of common engineering knowledge - The fundamentals of billing are understood from charges (one-time, recurring, usage), to bundles, bill presentation, payments and financial postings. This knowledge allows customers to read and understand their bills and enables billers to implement productised software used across different countries and industries.

The 'rates' charged by billers may be confidential (i.e. the configuration), but the methods by which they are calculated, presented to the customer (bills) and collected (payments) will be common and widely used (i.e. the billing engine). This is demonstrated today by the deployment of proprietary solution in different industries, countries and in competing billers.

By separating the product descriptions and pricing (rates) from the mechanism, a company's 'secret sauce' can remain confidential. Their network, customer service, products and other operational systems will determine their success rather than the particular software chosen for billing.

Why would a business contribute their billing changes / enhancements?

Billers do not generate value by selling their own billing software to other billers. Billers receive value from their billing system by using it as a tool ('a means to an end') to efficiently charge for and collect their revenue. Businesses have historically each written their own billing software, moving more recently to purchase proprietary solutions developed by software vendors and sold to many other billers.

Businesses customise their billing systems to address their specific business needs and adapt to the changing business environment. The need for these changes is often more immediate than their vendor's 'roadmap' can deliver it necessitating custom workarounds. These changes and new developments may be minor fixes with little use in another business, or major new functionality with wider relevance and applicability.

Billers with a home-grown billing system must develop all their new functionality themselves and cannot take advantage of functionality developed elsewhere. There is no 'market' for their changes as no other business operates their software.

Billers operating proprietary billing systems may find it difficult to share changes / development and may be bound to operate in isolation from their peers by their vendor's licence conditions. Without access to the source code, proprietary development paid for by a biller cannot be shared - the biller may only benefit (receive value) from the resulting functionality. The primary advantage of proprietary billing systems is that billers can take advantage of functionality (i.e. R&D) developed elsewhere or by the vendor.

With access to the underlying code, their billing vendor may build the development into their base offering (improving their vendor's product's value) reducing the need to reapply a biller's specific development when the vendor's next software version is released. Other billers may benefit from the changes, but the results of this value are likely to be captured by the billing vendor.

Billers operating an open source billing system could share their software's source code with any of their peers, and benefit from the code developed by others. The development costs of the changes are already spent (sunk). Keeping the changes to themselves generates no benefit to others and is likely to incur a future cost when the next version of the billing software is released. By contributing changes back into an open source billing project the biller can share the maintenance costs of the change with other project users and may receive the benefit of improvements (including bug fixes) back in the future.

How might an open source billing platform evolve?

Start with less complex industries that do not compete - Early adopters / builders of an open source billing system are more likely to support and improve an initial billing platform if their needs are met early. As well, it will be difficult to convince businesses to share their billing needs with direct competitors.

In 'The Magic Cauldron', Eric Raymond explored the different models that could be the genesis of an open source project including cost sharing and risk spreading. An initial open source billing platform could be developed by identifying industries with less complex billing needs (development effort, product scope) and non-competitive markets (motivation). Businesses with a common need for billing systems and who did not compete against each other could pool their development budgets to generate the initial version of the billing application.

The resulting billing application could be released under an open source licence (e.g. such as the GPL or LGPL licences written by the Free Software Foundation) allowing the benefits of further development to be shared easily, allow internal development to be undertaken (since the source code is available), loosen billers' dependence on specific software vendors (pricing, vendor longevity, monopoly), and allow subsequent enhancements by other billers to be incorporated at a lower cost.

Two industries that might fulfill these requirements are water retailing and local government. By their nature they don't compete (from a billing perspective) since geography alone decides how customers map to each organisation. The billing needs of the billers within each industry are similar, with their bill presentation, rates and customer service needs particular to their location and customer bases.

Water retailers generally offer a standard product suite (i.e. water consumption plus recurring and installation charges) at a regulated price. The charging mechanisms employed are straightforward, and many of their customer bases are 'small' relative to other industries (e.g. telecommunications).

Local government charges are often based on property values (taxes, rates) with additional services such as garbage collection and animal registration levied separately. Local governments that also supplied utility services (e.g. water) could provide an early opportunity to validate the billing system's ability to address multiple networks and complex product combinations.

Once the initial needs of 'water retailers' were addressed, the software could be extended to cater for other metered billing in industries such as gas and electricity utilities. Gas and electricity are contestable in some markets and this would be an opportunity for the development of churn (change of ownership) processing.

Development to cater for billers with constant value transactions (e. music downloads) could be performed, and later extended to cater for variable value transactions such as phone calls. Each new industry and international user group would extend the billing system, increasing its functional sophistication.

Develop modular functionality - Billing covers a wide range of functions that can be developed and introduced separately. One possible division of billing is to separate rating (pricing), bill production, financial processing (debt, GL) and customer data repositories (product inventory, customer details).

For example, an open source rating module that could address complex products is one area that could precede the introduction of other open source billing functionality. A biller could upgrade the complexity of their product offerings and still retain the bill production and financial processing of their current system.

Whilst interface integration is an expensive process, modular upgrades could allow a biller to upgrade gradually without having to commit to a complete system replacement. The subset of billing functions implemented could depend on where a biller thought improvement was needed. This might just as easily be bill production or financial processing.

Industry and country specific development - The initial development is likely to be performed for a specific industry in a specific country. A different country may implement (and enhance) the initial solution in the same industry to cater for (say) local taxation. A different industry may implement the initial solution in the same country. In each case, the functionality offered will be extended.

The extension of the base release along each of these dimensions will gradually develop the functionality available and make it more suitable for the next industry or country to implement. Interface modularity will provide scope for industry-specific configurations (e.g. Telco) or country specific information (e.g. taxation). Each of these are opportunities for specialist content, configuration and support businesses.

Develop complexity - An open source billing platform's initial releases will not be suitable for the most demanding billing environments (e.g. telecommunications), but will be 'good enough' for many situations. As functionality is added and the platform is used in different industries and countries, its capabilities and performance will improve allowing more complex billing and larger installations to be addressed.

Add-on functionality - Open source billing interfaces with other business systems could be developed as add-on modules. Examples of these include credit management (debt recovery), data warehouses (BI), customer relationship management (CRM), self-service portals, and web-presentation of bills (EBPP).

What might an open source billing platform look like?

Open standards - Use of non-proprietary standards allows the billing platform to be used without licensing fees and limitations placed on shared development. Using open standards, the benefits of the open source development approach won't be constrained by a vendor's or other privileged party's ability to limit the distribution of the software.

Web-based presentation - Web-based infrastructure to enable an easily deployed 'face' to the billing function. Staff, and later customers, could access the billing system from low specification PCs. Standards compliance would ensure that staff and customers could use any web browser.

Parallel processing - Many billing functions are suitable for subdivision and concurrent execution. Dividing a large block of processing into smaller pieces allows the elapsed execution time to be reduced, and the processing to be performed on cheaper hardware. For example, rating and bill production can be performed with little or no need to share information. A large transaction file can be broken into smaller files that are individually rated. A billing cycle can be broken into separate streams that calculate and format individual bills.

Smaller billers' lower processing needs may use the performance of contemporary hardware to perform processing on a single server. Larger billers could use the throughput of High Performance Computing (HPC) to scale their large processing needs cheaply.

'Supercomputer' performance could be delivered using a cluster of commodity hardware. Beowulf clusters are an example of these and have been used in many industries to deliver high-performance processing at a low unit cost. Beowulf clusters can be extended by adding extra processing nodes as the workload increases.

Commodity hardware / software - To maintain its 'price point', an open source billing project could use an open source operating system such as GNU/Linux or a member of the BSD family. This will minimise costs as the number of processing nodes increases in a processing cluster. Using only open source software will also ensure businesses can 'sample' the open source billing system at minimal cost before making any commitments.

Commodity hardware's economies of scale will ensure that prices and availability work in a biller's favour. Moore's Law will improve the performance of the billing system as hardware is upgraded or replaced. Older hardware might be replaced in (say) the Beowulf cluster, or the cluster's performance could be upgraded by adding contemporary hardware to create additional processing nodes.

Since the billing system is open source, it could be recompiled and implemented on proprietary hardware and/or operating systems, but with adequate, lower cost hardware available these costs may not be required.

Where might a billing application originate?

Two sources where an open source billing application might be developed initially before broadening to a wider market include:

An existing software vendor - A (probably smaller) vendor might 'open source' their proprietary software code to broaden the market available to their software. This might be done if the majority of the vendor's existing revenues came from customisation and support of their proprietary code base rather than licence sales (i.e. little 'sale value' is lost). An example of where this has been done is the JBOSS application server suite. Customers are able to try the software at no cost and this provides stronger marketing than the JBOSS company could fund themselves.

Such a vendor should use contemporary technologies so that it was sufficiently appealing to new customers (billers) and potential developers. Software developed using older technologies and languages (e.g. COBOL) may not have sufficient contemporary appeal to develop a user community.

An industry association - An existing industry association whose members require billing services could initiate a common billing platform for their members. A local government organisation is an example of such a group that could reduce its members' billing development costs by sharing common functions amongst its members.

Whether other billers (businesses) and developer groups / businesses around the world begin to use such an open source billing application is likely to depend on factors such as:

Functionality: Do the included billing functions overlap the needs of other businesses? Some element of 'productisation' would be desirable so that the needs of the initial user group could be leveraged across a wider population with less effort.
Extensibility: Other billing businesses will add functionality by extending the base offering to meet their needs. The necessary development and operational 'hooks' that enable this will be required along with 'how to' guides so that it is applied consistently. For example, billers may require additional rating mechanisms or need to process data feeds with wildly different formats.
Licensing terms: The terms under which the software is released will affect the motivation of billers, vendors and developers to contribute their efforts into the project. Consideration should also be made as to how existing proprietary system would be able to call / interface / interact with the billing software without breaching licensing conditions.
Support infrastructure: Infrastructure similar to other large open source projects would be required to support bug fixes, downloads and functionality 'gifts'. Mechanisms for documentation and problem discussions would allow users and developers to leverage each others experiences and skills.
Support services: Companies and individuals who can take the base application and customise / support it in a biller's business environment. These services could be provided by local consultancies or system integrators (e.g. IBM, Infosys) depending on the biller's size and the complexity of their needs.

Tags: Billing, Free Software, Open Source, Utility, Vendor, Beowulf, Cluster