Stretch Key Dimensions to See What Breaks



Stretch Key Dimensions to See What Breaks

Stephen Jones

An AppliCATion’S dESign iS ouTlinEd initially based on the specified business requirements, selected or existing technologies, performance enve- lope, expected data volumes, and the financial resources available to build, deploy, and operate it. The solution, whatever it is, will meet or exceed what is asked of it in the contemporary environment and is expected to run success- fully (or it is not yet a solution).
Now take this solution and stretch the key dimensions to see what breaks.
This examination looks for limits in the design that will occur when, for example, the system becomes wildly popular and more customers use it, the products being processed increase their transaction counts per day, or six months of data must now be retained rather than the initially specified week. Dimensions are stretched individually and then in combination to tease out the unseen limits that might lie hidden in the initial design.
Stretching key dimensions allows an architect to validate a solution by:
•
•
Understanding whether the planned infrastructure accommodates these increases, and where the limits are. If the infrastructure will break, this process identifies where it will break, which can be highlighted for the application’s owner, or the planned infrastructure can be purchased with specific upgrade paths in mind.
Confirming that there are sufficient hours in the day to perform the pro- cessing at the expected throughput, with head room to accommodate “busy days” or “catch up” after an outage. A solution that cannot complete a day’s processing in a day and relies on the weekend when things are qui- eter has no long-term future.

• Validating that the data access choices that were made are still valid as the system scales. What might work for a week’s worth of data may be unus- able with six month’s data loaded.
• Confirming how the application’s increased workload will be scaled across additional hardware (if required), and the transition path as the load increases. Working through the transition before the application is deployed can influence the data stored and its structure.
• Confirming that the application can still be recovered if the data vol- umes are increased and/or the data is now split among an increased infrastructure.
Based on this examination, elements of the design may be recognised as prob- lems requiring redesign. The redesign will be cheaper whilst the design is still virtual, technical choices are not locked-in and the business data has yet to be stored in the repositories.
Stephen Jones designs solutions for Tier-1 Telco Billing and its related high-volume processes for companies such as Telstra and Optus in Australia, and the 1997 ver- sion of AT&T in the U.S. This design work included the initial implementations of Telco billing systems, redesigns of post-bill dispute and fraud billing functions, and over two years managing 24/7 production support for Telstra.