Backstory
A friend of mine, about 20 years ago, stated, and I’m paraphrasing, the quality metric of an architecture design is inversely proportional to the number of components affected by common or likely change cases.
That is, every time a requirement is added or changed, very few architectural components should be modified to support the addition or change.
The premise here is that architecture is not sculpture. Architecture is done (mostly) up front, it is not something hidden in a piece of granite you the artist/architect must find.
Architecture is the connecting of disjoint things in useful ways.
Architectures are heterogenous.
So as an architect you should ask what makes an architecture complex. The test above is one such way, if you prescribe the the idea that loosely coupled systems are less complex.
The point of computing systems, and resulting architectures, is to make less valuable data more valuable. From noise to signal to information to knowledge.
If you go along with this for now, anything that a computing system or architecture does to data doesn’t (necessarily) add value, it (hopefully) improves some ‘-ility’ (quality, maintainability, etc) of the system, at the expense of making the system more complex.
Caching makes valuable data available at a lower latency, making it possibly more valuable, but it doesn’t transform data with no inherent or potential value to magically having value.
Data goes through transitions. And an architecture supports those transitions, and a good architecture supports them in a way that is cost effective and maintainable by an organization.
State Transitions
So what are these transitions?
A Value Transition (Tv) is when the data itself is converted to new data through the application of business logic. 2 + 2 = 4, or fullName = firstName + lastName. This of course assumes the model and phase remain the same.
A Phase Transition (Tp) is when dynamic, malleable, or fluid data becomes static, stiff, or frozen, through serialization for example. Or frozen data becomes fluid, that is, it is de-serialized into a runtime data structure. The direction of the transition is irrelevant, it is still costly.
A Model Transition (Tm) is when data is contained in one meta-model and translated into another. For example, you convert a DOM instance into a set of POJO instances.
A Location Transition (Tl) is when data moves from one component of a system, to another component. Where components are separated by some boundary that prevents direct memory access between them.
Applied
So arguably, the more transitions your data goes through, the more complex your application and your resulting architecture. This complexity isn’t a bad thing, but it should be minimized. Maybe there should be a budget. Maybe a distance measure would help:
Dcomplexity = sqrt( Tv^2 + Tp^2 + Tm^2 + Tl^2 )
Consider the move to micro-services from monoliths. A monolithic application by these measures result in a very simple architecture, but for many organizations they may have come up against the inherent limitations of monoliths, so have decided a micro-services architecture is the way to go. If they are large enough to absorb the complexity, they can expect a payoff of added organizational agility (does that make micro-services simply a forcing function?).
To improve the quality of an architecture, both coupling must be minimized, as should the overall data transition complexity.
The thing I still need to ponder is, as coupling is minimized between the components of an architecture, does localized complexity matter overall?