Orthogonality refers to the different dimensions that are addressed by the components of the system. Typically, these dimensions will look something like: data storage, data processing (i.e., computing and updating), data presentation (GUI and reporting), communications (transport, synchronization), implementation (servers, workstations, end-user terminals) and so on.
Come up with a set of dimensions that represent your product. Each dimension will have a major characteristic as well as sub-dimensions, attributes that contribute to the overall dimension. For instance, communications as a dimension will have sub-dimensions of reliability, quality of service, speed, etc. Then, take the inventory of components that you hinted that you have, and produce an impact matrix -- for each component, what impact does it have on each dimension. A very good spreadsheet or set of spreadsheets can help you with this.
The impact that you provide in each cell identifies how effectively the component addresses that dimension, the costs and drawbacks.
Lack of orthogonality is indicated in such a matrix by smearing and clustering -- "smearing" occurs when some components tend to dominate multiple dimensions. "Clustering" occurs when multiple components address specific dimensions with significant overlap between components.
Data Storage Dimension Example
Let's use the "data storage" dimension, with sub-dimensions of "quantity", "speed of update", "speed of reading", "redundancy", " "ongoing deployment cost", and "flexibility" (just as a starter set). Let's use "local storage" and "network storage" as components.
For each sub-dimension we will provide a 0 to 10 figure of merit, with larger as better, a dimensionless number that we can use for comparison purposes. So, starting with "local storage":
- "quantity" - 6 - individual computers are limited in space
- "speed of update" - 9 (10 if using SSDs everywhere)
- "speed of reading" - 9 (10 if using SSDs everywhere)
- "redundancy" - 1
- "ongoing deployment cost" - 6
- "flexibility" - 6
Then for "network storage":
- "quantity" - 10 - disk farms can be dynamically resized
- "speed of update" - 4
- "speed of reading" - 6 (depending on communications)
- "redundancy" - 8-10 (depending on network storage implementation)
- "ongoing deployment cost" - 9
- "flexibility" - 5
I presume also that when you say "local storage" you mean that there are many local storage mechanisms being used. Each mechanism will count as a component and you need to evaluate them all.
Once you have this spreadsheet, you have a whole bunch of numbers on your hands and won't be sure what to do with them. There are a number of ways of looking at such a thing. You can treat it as a requirements assessment matrix, or you can create a heat map from it.
When you propose a solution, you should be able to produce a before and after impact matrix that allows you to describe the overall impact of your proposed improvements.
On the other hand, you may realize what the experts are already telling you, that the solution they have is "good enough".