Category: Softwares

Have you heard of a judge who wasn’t a lawyer; or a chief of surgery who wasn’t a surgeon? Even after they get to what some would call the pinnacles of their career, the people holding these occupations are still expected to continue learning the new developments within their respective fields. As software architects, we should be held to the same standards.

No matter how well designed a solution is, one of the most important factors for determining the success of an implementation is getting the developers to sign on to the game plan. The quickest way to get the developers to sign on is to gain their respect and trust. We all know the quickest way to gain a developers trust: your code is your currency. If you can show your developers that you‘re not just some pie in the sky day dreamer who can‘t code his way out of a paper bag, you‘ll hear less grumbling about the hoops you‘re “making” them jump through to get data to show on the page when “I can get it done in less time by just binding a dataset to a grid.”

Even though I‘m not required to as part of my job, I will frequently pick up some of the more intricate tasks. This serves two purposes: first it‘s fun and helps me to keep my development skills sharp; second, it helps me demonstrate to my developers that I‘m not just blowing smoke where the sun doesn‘t shine.

As an architect, your primary goal should be to create a solution that is feasible, maintainable, and of course addresses the issue at hand. Part of knowing what is feasible in a solution is having knowledge of the effort involved in developing the elements of the solution. Therefore, I propose that if you design it, you should be able to code it.

An application’s design is outlined initially based on the specified business requirements, selected or existing technologies, performance envelope, 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 successfully (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 it identifies where it will break which can be highlighted to the application’s owner, or the planned infrastructure can be purchased with specific upgrade paths in mind.
• Confirming there are sufficient hours in the day to perform the processing at the expected throughput, with head room to accommodate ‘busy days’ or ‘catch up’ after an outage. A solution that cannot process a day’s processing in a day and relies on the weekend when things are quieter has no long-term future.
• Validating the data access choices that were made are still valid as the system scales. What might work for when a week’s data is held, may be unusable 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 the application can still be recovered if the data volumes are increased and/or the data is now split amongst an increased infrastructure.

Based on this examination, elements of the design may be recognised as problems 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.