Stephen Jones writing on Billing and Application Migration
Following the billing hierarchy approaches outlined previously can result in hierarchies of different dimensions, with the complexities a series of tradeoffs decided or forced on the biller.
Mass market customers probably with simple needs do not require a hierarchy to exist, and can be supported (if necessary) with a single (service) hierarchy point.
The question for the biller is for their small business and larger (corporate and government) customers, what additional benefits will be generated for the additional business costs that a hierarchy brings. Examples of costs include:
Processing Effort: A billing hierarchy needs to be walked to find the parent/child and grouping relationships used to support the benefits listed previously. This generalised processing may need to be deployed in multiple locations for a custom system, be provided as a callable function, or be 'baked in' to a productised billing solution. This allows the billing processes (e.g. rating, pricing, invoicing) to obtain generically the appropriate property's value at any point in the hierarchy, taking into consideration defaulted and inherited values.
Investigation Costs: When there is a processing error (or at least a problem docket / inquiry has been raised), the biller's operational support staff will need to investigate what took place and from that determine if an error occurred, its root cause and fix the problem to prevent a reoccurrence. Part of that investigative processing may require the capture of the 'inherited' values at different points in a complex billing hierarchy.
Defect Resolution Costs: A defect in the biller's system that requires an update to the customer's hierarchy data will need to be applied carefully. The billing system's processing will expect that the relationship between nodes in the hierarchy is maintained, and that all nodes remain accessible.
User Interface Complexity: To support the application and maintenance of a billing hierarchy against a customer, the billing application's user interface will need to allow for the presentation of a hierarchy to the business user, and its subsequent manipulation and update. Where the biller allows their customer to view and perform (minor) manipulation of their own hierarchy (accounts, service, products), then this capability would also need to be built (in some fashion) into the customer's self-service interface/portal.
At scale, the 'shape' of large retail and wholesale hierarchies can be quite different.
The retail hierarchy is likely to have some 'depth' reflecting how the biller is supporting the end customer's business including their bill presentation. The end customer's (say) retail branches across different geographical regions is likely to generate a broad and deep structure that can be understood by the biller's and end customer's staff.
The wholesale hierarchy is useful for associating large number of services together and applying consistent maintenance to them. Since wholesale services are more likely to be sold at lower margins, be numerically higher (10's to 100's thousand of services per hierarchy - depending on the industry), and related to a single reseller / retailer, the shape of their hierarchy is to minimise the costs associated with its maintenance. As a result, the wholesale hierarchy is likely to be wide and flat in nature, with large numbers of services under a single billing account, or intermediary hierarchy point.
Originally posted by
Download the FREE Book Sample
Stephen Jones is a consultant who has focused specifically on Billing and related processes for over twenty years. Recent work has included integrating a major telco's billing extracts with technical logs from call centres.
I contributed an essay on testing design assumptions in the O'Reilly book 97 Things Every Software Architect Should Know. This book was written in an 'open source' style with more than four dozen authors. The original essays of the axioms / koans / advice can be viewed on the project's wiki.
Enter your email address to follow changes and receive notifications of new posts by email.
You will be returned back to this page, and a confirmation email will be sent.