Processing dimensions influence throughput and ability to scale

Summary

The ability to achieve a desired processing goal, either in billing or in migration, can be prevented by the processing dimensions that describe its performance boundary. These limiting dimensions can include time (overnight processing window, weekend migration window), space (storage of a data table in memory), physical resources (disk, hardware), people (staff to validate results, perform error correction, backfill during training), computational complexity (exotic discounting algorithm, hierarchy size) or any other parameter that plays a part in processing.

Identification of the constraining limits (where they exist) allows for their evaluation for possible remediation. If remediation is uneconomic or impractical, the publication within the business / team of the limiting factor (the what) with its reason (the why) provides the rationale for slower / longer / larger solutions. Publication of the identified limits to a wider audience may also have the benefit of extracting alternative solutions based on their diverse experience.

What are the dimensions of a process?

At the micro-level, a process can be decomposed into its constituent steps. Execution of these steps will require specific information (data needs) that is manipulated / evaluated in some manner (algorithm), before being used to generate a result (e.g. database update, file output).

In this example, relevant dimensions could be based on the size of the reference or customer data needed, the processed number of records, the processing characteristics of the 'algorithm' (e.g. how it scales, how its performance varies and on what basis), and the nature of the process' 'results'.

At the macro-level, the accumulation of processes forms end-to-end execution flows. These flows could be to generate customers' bills, or migrate data between systems. The dimensions at the macro-level are less about the detail of individual processes, and more about the elapsed time of their end-to-end execution. For example, the time to calculate an individual bill is less important than the window available to calculate all of today's bills.

The dimensions of the macro-level are based around the fixed and variable components of processing times and how they vary:

The processing time to bill residential customers (little or no hierarchies, small call volumes, standard pricing) can be quite different to those of commercial customers (small to large hierarchies, high call volumes, complex pricing).
The processing effort to migrate a business' five largest customers from a legacy system versus its five million basic customers.

Should a process be performed manually, or automated?

Based on a process' initial dimensions, a manual solution may be appropriate. However the process' dimensions should be examined to test its ability to scale (if required). This is especially important if one or more dimensions can quickly increase, or the manual effort per widget is large.

In billing, new products may be manually billed when initially introduced. In migration, an error may be fixed manually at low volume. However, as the new product becomes popular, or the migration error more prevalent, an automated solution is desirable to avoid a 'small army' of staff performing the now larger manual workload. This is especially true in applications such as billing where external forces (i.e. customers) can quickly increase demand. i.e. What happens if customers actually like and buy what we offer...?!

Manual processes can be used to address the short-term need whilst the long-term automated solution is developed, but if planned the automated solution should be delivered in a timely manner.

How can dimensions affect a migration event?

In performing a migration, the data (widgets) migrated will be specific to the business application. The widgets could be customers, dockets, call records, property title records or customer orders. Whatever the data migrated, the principles applied are common.

What is the available window for the migration event? - With a fixed processing window (overnight, a weekend), an estimated maximum number of migrated data widgets can be made. The final answer for the migration event could impact other aspects of the end-to-end migration process such as staff training and customer communications.

When is the decision point for GO / NOGO? - This predetermined time can be affected by the (relatively) fixed time to backout updated databases, and the (possibly variable) time required to complete a successful migration event. The variable time to complete a migration may be proportional to the number of data widgets migrated. The specifics of each migration event can determine different decision points.

How does this migration event differ from the last one? - When migration events are performed repeatedly, the mix of data widgets can vary (e.g. from five large customers to five million small customers). As well, performance and process tuning may allow additional data widgets to be migrated per event.

What error rate is too high? Why? - For most migration events one error would not trigger a backout, but one million errors might. Somewhere between these two numbers is the cutoff point allowed for a successful migration event. The cutoff point may be based on the number of customers impacted, types of errors generating different customer and/or business impacts, or the effort required to fix the different errors (SQL, online screens, custom written programs, available staff for corrections).

How will the newly migrated data affect the target application's processing? - The target application will have run to a service level based on a given number of customers, users or other data widgets. After the migration event, each of these may be changed. What is the impact to the application's regular processing?

How do dimensions affect billing?

Can all transactions be processed inside a specified window? - If an actual or desired processing window exists, an understanding of a process' dimensions and time to process each transaction is the raw data for understanding its processing profile. If specific dimensions are expected to grow, when will they break the processing window? What is the variation in each dimension? Will the window be consistently breached at end-of-month?

Where should tuning be applied first? - Understanding processing's dimensions will allow a prioritisation of the tuning effort. High-cost / long-duration processes that involve high-growth dimensions should be examined earlier than static processes.

What will the impact of a data migration or a new product be? - The same information that supports prioritisation of tuning can be used to understand the impact of a data migration, or the processing impact of a new product and its additional transaction load.

What is the processing impact of software enhancements / new functionality? - Billing systems are continuously enhanced to provide competitive advantage to their owners. What is the impact of a planned change? Should it be performed in a different location, or in a different way?

Tags: Billing, Migration