The Architecture Does Not Have One Number

Organizations like numbers.

Numbers fit into dashboards. They can be trended, ranked, compared, colored red or green, and placed in front of an executive committee. A number appears to compress ambiguity into something actionable.

That convenience creates a recurring temptation in architecture

Can we calculate a single number that tells us whether the architecture is good?

The question is understandable. It is also usually malformed.

An architecture may

Impose high cognitive burden on one team while remaining easy for another to operate
Preserve many future options while accumulating substantial verification debt
Exhibit strong local modularity while losing fidelity between business intent and software realization
Be reliable under familiar operating conditions but brittle when ownership, scale, regulation, or mission assumptions change

These are not merely different observations of the same scalar property. They are different architectural conditions, encountered in different localities, at different resolutions, by different agents, for different purposes.

The architecture therefore does not possess one number waiting to be discovered. It has a structured diagnostic state that can be projected into numbers.

That distinction matters.

The Attraction of the Composite Score

The desire for a single architectural score is part of a much broader measurement pattern. Whenever a complex phenomenon must be governed, compared, funded, or communicated, pressure develops to combine many observations into a composite indicator. National competitiveness, university quality, organizational performance, creditworthiness, health outcomes, software quality, sustainability, and project health are all routinely represented this way.

Composite indicators can be useful. They summarize large quantities of information, reveal broad patterns, and support communication. The OECD and European Commission’s Joint Research Centre nevertheless warn that composites can mislead when their construction hides weak data, disputed weights, compensatory assumptions, or sensitivity to normalization and aggregation choices [NSS+08]. The resulting value may appear objective even though it embodies a sequence of modeling and policy judgments.

The difficulty is not simply that a composite score loses detail. All measurement loses detail. The deeper problem is that aggregation introduces a new claim.

Suppose an architectural evaluation produces measures of

Encountered cognitive complexity
Total technical debt
Option preservation
Representation fidelity
Verification burden
Governance latency
Operational resilience
Cross-layer causal continuity

Combining those measures into a score such as

$S(A) = \sum\limits_{i=1}^{n} w_i M_i(A)$

does not merely summarize the architecture. It asserts that the measures are commensurable after transformation, that the selected weights represent their relative significance, and that strength in one dimension may compensate for weakness in another.

Those are substantial claims.

A low verification burden might compensate numerically for severe loss of mission traceability. High reliability might offset low adaptability. Strong modularity might balance accumulated decision memory loss.

But should it?

The equation cannot answer that question. The aggregation rule has already answered it, usually without making the answer visible.

Measurement Does Not Begin With the Number

Measurement theory has long distinguished between an empirical phenomenon and the numerical representation assigned to it. The number is meaningful only because a mapping preserves selected relationships in the empirical system. The permissible interpretations and mathematical operations depend on the structure preserved by that mapping [Ste46].

This means that measurement should not begin by asking

What number can we assign?

It should begin by asking

What distinction are we trying to preserve?

A measure of architectural coupling may preserve one set of relationships. A measure of option loss preserves another. A measure of encountered complexity may depend on the locality, expertise, responsibilities, tools, and decision horizon of the encountering agent.

Even where the results are all expressed numerically, they do not automatically measure interchangeable quantities.

Systems and software measurement standards reflect this need to connect measurement to information requirements and decision processes. ISO/IEC/IEEE 15939 defines measurement as a process supporting systems and software engineering and management rather than as the indiscriminate collection of available numbers [Int17].

The essential question is not whether an architecture can be quantified. It can.

The question is what each quantification means, what relationships it preserves, and what claim it is capable of supporting.

A Metric Has a Target

A recurring error in architectural measurement is to speak as though a metric describes “the architecture” without specifying which architectural feature, relation, burden, or capability is being measured.

A metric should instead be associated with a declared target of measurement and context. We can write this schematically as

$M_i(A; \ell, t, \rho, q)$

where

$A$ is the architecture or architectural state
$\ell$ is the locality from which it is encountered
$t$ is the relevant time or lifecycle position
$\rho$ is the resolution at which distinctions are represented
$q$ is the question the measurement is intended to inform

The same architecture may produce different values when any of these change.

A maintenance engineer and a program executive do not encounter the same effective architecture
A prototype and a certified operational system do not present the same obligations
A component-level model and a cross-enterprise model do not preserve the same causal distinctions
A metric intended to support near-term staffing does not necessarily support a platform replacement decision

This is not measurement failure. It is architectural locality.

The mistake is to suppress the contextual arguments and treat

$M_i(A)$

as though it were a timeless intrinsic property.

Quality is Already Plural

Software engineering has repeatedly confronted this problem through quality models. Standards and research commonly decompose software quality into characteristics such as reliability, security, maintainability, performance, usability, and compatibility rather than treating quality as a directly observable scalar.

Empirical work continues to find that metric relationships vary across applications, languages, platforms, versions, and measurement methods. A metric associated with quality in one context may not behave consistently in another, and even apparently similar metrics may be dependent or non-monotonic [MNM20].

This plurality is not an inconvenience to be eliminated. It reflects the structure of the architecture and the diversity of the questions being asked of it.

An architecture can be more maintainable and less secure
It can be easier to deploy and harder to verify
It can reduce local development effort while increasing enterprise coordination burden

The measures may conflict because the architecture itself contains a trade, a displacement, or an unresolved causal tension. Forcing those values into one score can erase the very condition the measurement process was supposed to reveal.

When the Measure Begins to Govern the Architecture

A second danger appears when a diagnostic measure becomes a management target.

Goodhart observed in monetary policy that an empirical regularity used for control could lose the stability that made it useful in the first place [Goo75]. Campbell made a related observation in social evaluation: the more a quantitative indicator is used for decision-making, the more pressure it creates for corruption of the process it is intended to monitor [Cam76, Cam79].

Architectural metrics are not exempt.

If teams are rewarded for reducing interface counts, they may consolidate interfaces while creating large, semantically unstable contracts
If modularity is rewarded, they may create nominal modules that retain hidden temporal, data, deployment, or organizational coupling
If technical-debt closure is targeted, they may relabel, defer, subdivide, or close debt records without removing the causal burden
If requirements traceability is scored, they may produce dense link structures that preserve little actual decision meaning

The organization improves the number by changing the relationship between the number and the underlying condition. In many cases, this act is not intentional.

This does not imply that metrics should never become targets. It means that a metric used for control becomes part of the causal architecture it measures. Once attached to authority, incentives, funding, promotion, compliance, or acceptance decisions, the metric is no longer a passive observer. It becomes an intervention.

Any serious architecture-measurement framework must account for this reflexivity.

The Architecture As a Plural Metric Field

The alternative to a single architectural score is not a pile of unrelated measurements. It is a structured plural diagnostic representation.

Let the architectural diagnostic state be written as

$M(A; \ell,t,\rho,q) = \begin{bmatrix}M_{\text{CCC}} \\ M_{\text{TTD}} \\ M_{\text{opt}} \\ M_{\text{fid}} \\ M_{\text{ver}} \\ M_{\text{gov}} \\ \vdots \end{bmatrix}$

where the entries might represent encountered cognitive complexity, total technical debt, option preservation, representational fidelity, verification burden, governance latency, and other quantities relevant to the question.

Calling this a field emphasizes that the values need not be uniform across the architecture.

Encountered complexity may be concentrated at an integration boundary
Technical debt may accumulate in the mapping between business assumptions and implementation commitments
Verification burden may be low within components but high across timing interactions
Governance latency may emerge only when a decision crosses organizational or regulatory boundaries.

The useful diagnostic representation is therefore not merely a vector of enterprise-wide averages. It may vary over

Architectural locality
Organizational role
Lifecycle phase
Vertical layer
Decision horizon
Operational condition
Resolution of observation

Averages can still be calculated. But an average is then recognized as a projection of the field, not the field itself.

Disagreement Between Metrics is Evidence

Traditional scorecards often treat disagreement between measures as a nuisance. One metric says the architecture is improving while another says it is deteriorating. The natural reaction is to adjust the weights until the dashboard produces a clear answer.

This simple act may destroy the most important information available.

Suppose a redesign produces

$\Delta M_{\text{CCC}} < 0, \quad \Delta M_{\text{TTD}} > 0$

The design reduces the complexity encountered by the current team but increases total technical debt. That is not necessarily contradictory. The team may have simplified its local work by moving complexity into infrastructure, operations, verification, future migration, or another organizational locality.

Similarly,

$\Delta M_{\text{opt}} > 0, \quad \Delta M_{\text{ver}} > 0$

may indicate that preserving more future options has increased the burden of proving acceptable behavior across those options. The measures disagree because burden has moved or because one architectural benefit carries another architectural cost.

The disagreement is a diagnostic signature. It asks us to investigate the causal mechanism that relates the measures.

Architecture is Not a Compensatory System By Default

A weighted sum is a compensatory model. A poor value on one criterion can be offset by a sufficiently good value on another.

Some architectural decisions legitimately permit compensation. Cost, schedule, performance, and maintainability may be traded within a bounded decision context.

Other conditions should be treated as constraints rather than preferences

A safety invariant cannot necessarily be traded for greater adaptability
Loss of legal compliance cannot be balanced by improved developer productivity
A critical security exposure may not be offset by excellent modularity
Failure to preserve a mandatory interface obligation cannot be averaged away by reducing technical debt elsewhere.

A more faithful decision model separates at least three structures

$\mathcal{D}(A) = (M(A), \mathcal{C}(A), \mathcal{P})$

where:

$M(A)$ is the plural diagnostic state
$\mathcal{C}(A)$ is the set of constraints, invariants, thresholds, and non-compensable obligations
$\mathcal{P}$ is the declared preference or decision structure used for a particular choice

Only after inadmissible alternatives have been excluded by $\mathcal{C}$ should the remaining diagnostic dimensions be interpreted through \mathcal{P} $.   This is where multi-criteria decision analysis (MCDA) becomes relevant. MCDA comprises methods for structuring and supporting decisions in which several, often conflicting, criteria must be considered together [BS02, KR93, Roy96]. It does not eliminate judgment. Instead, it makes criteria, preferences, constraints, uncertainty, and permissible tradeoffs more explicit. Its strongest use is often not the mechanical production of a ranking, but the structuring of the decision problem, exploration of alternatives, facilitation of learning, and exposure of disagreement.   The output of such a process may be a number. But that number belongs to the decision model, not intrinsically to the architecture.   <h2 class="wp-block-heading">A Decision Index Is Not An Architectural Property</h2>   This distinction lets us use composite measures without confusing them with reality.   For a particular decision$ d $, we may define  $ I_d(A) = F_d(M(A), \mathcal{P}_d) $  where$ F_d $is an aggregation or evaluation rule constructed for that decision and$ P_d $contains the relevant preferences, thresholds, and trade assumptions.   The subscript matters.   <ul class="wp-block-list"> <li>A decision index for selecting a near-term migration strategy is not the same as an index for assessing long-term platform resilience</li>   <li>A score used to prioritize refactoring is not the same as one used to establish certification readiness</li>   <li>A measure useful to a product team is not automatically valid for enterprise governance</li> </ul>   <blockquote class="wp-block-quote"> <em>The architecture does not have one number.</em> </blockquote>   A decision process may create a number for a declared purpose. That number should travel with its provenance   <ul class="wp-block-list"> <li>What question was it created to answer?</li>   <li>Which measurements were included?</li>   <li>At what locality and resolution were they obtained?</li>   <li>How were they normalized?</li>   <li>Which weights or preference functions were used?</li>   <li>Which dimensions were allowed to compensate for others?</li>   <li>Which obligations were treated as non-compensable?</li>   <li>What uncertainty or missing evidence remains?</li>   <li>Under what conditions does the result cease to apply?</li> </ul>   Without that information, the apparent precision of the index exceeds its architectural meaning.   <h2 class="wp-block-heading">Preserve Incomparability</h2>   Organizations often assume that every pair of alternatives must be rankable.   <blockquote class="wp-block-quote"> Architecture does not guarantee this. </blockquote>   One alternative may preserve more options while another reduces current operational burden. One may provide stronger assurance evidence while another improves evolvability. Neither need dominate the other.   In multi-objective reasoning, such alternatives may remain on a Pareto frontier, i.e., each is better in at least one dimension and worse in another. The inability to collapse them into an unquestioned ranking is not analytical failure. It indicates that a preference, policy, constraint, or additional probe is required.   Preserving incomparability can be more honest and more useful than manufacturing a score. It tells the decision authority where judgment must occur. It also prevents the weights hidden inside a formula from making a governance decision that no accountable person has explicitly made.   <h2 class="wp-block-heading">Metrics as Probes, Not Verdicts</h2>   The most productive role for architectural metrics is diagnostic.   A metric is a probe into a selected aspect of architectural state. Multiple probes reveal different features of the causal structure. Their values, gradients, discontinuities, residuals, and disagreements suggest where further investigation is required.   <ul class="wp-block-list"> <li>A rise in encountered complexity may indicate loss of modularity, but it may also indicate inadequate representation, unfamiliarity, changing responsibility, or a cross-layer fidelity failure.</li>   <li>An increase in technical debt may reflect deferred work, but it may also reflect newly exposed obligations, a shift in mission intent, accumulating governance delay, or the exhaustion of previously preserved options.</li> </ul>   <blockquote class="wp-block-quote"> The measurement does not announce the cause.   It constrains the set of plausible explanations. </blockquote>   This leads to an iterative process  $ \text{probe} \, \rightarrow \, \text{residual} \, \rightarrow \, \text{hypothesis} \, \rightarrow \, \text{new probe} \, \rightarrow \, \text{intervention}$

The residual, the portion of architectural behavior not explained by the current metric model, is especially important. It tells us where our measurements, localities, assumptions, or representations are insufficient.

A mature metric system therefore does not seek to eliminate interpretive work. It makes that work more disciplined.

What An Architectural Dashboard Should Show

A useful architecture dashboard should not imitate a credit score.

It should reveal architectural structure. That may include

The values of several diagnostic measures
The locality and resolution of each measure
Uncertainty and evidence quality
Threshold violations and non-compensable obligations
Trends and rates of change
Transfers of burden between layers or teams
Metric disagreement
Sensitivity to weights or decision assumptions
Regions where evidence is missing
Alternatives that remain incomparable

The purpose of such a dashboard is not to declare that the architecture is a 74.

Its purpose is to show where the architecture is becoming difficult to understand, expensive to change, hard to verify, causally discontinuous, organizationally misaligned, or dangerous to govern.

That is less visually convenient than one number.

It is also more architecturally faithful.

The Number Belongs to the Question

There is nothing wrong with summarization.

But there is something wrong with forgetting what has been summarized.

A composite score can support a specific decision when its measurement targets, transformations, trade assumptions, constraints, uncertainty, and intended use are explicit. It becomes dangerous when it is reified as an intrinsic property of the architecture.

Architecture is plural because its consequences are plural.

It is encountered differently across localities
It creates obligations across time
It preserves some futures while foreclosing others
It moves burden between people, layers, organizations, and lifecycle phases
It can improve in one diagnostic dimension while deteriorating in another

No single scalar can preserve or represent all of those relationships.

The correct response is not to abandon metrics. It is to use them with greater architectural discipline

Declare the measurement target and question
Preserve locality, time, and resolution
Distinguish constraints from compensable preferences
Retain multiple diagnostic dimensions
Treat disagreement as evidence
Create composite indices only for explicit decisions
Preserve the provenance and limits of every result

The architecture does not have one number.

The decision may require one.

Those are not the same claim.

References

[BS02] Valerie Belton and Theodor J. Stewart. Multiple Criteria Decision Analysis: An Integrated Approach. Kluwer Academic Publishers, 2002.

[Cam76] Donald T. Campbell. Assessing the impact of planned social change. Occasional Paper 8, Public Affairs Center, Dartmouth College, 1976.

[Cam79] Donald T. Campbell. Assessing the impact of planned social change. Evaluation and Program Planning, 2(1):67–90, 1979.

[Goo75] Charles A. E. Goodhart. Problems of monetary management: The U.K. experience. In Papers in Monetary Economics, volume 1. Reserve Bank of Australia, 1975.

[Int17] International Organization for Standardization. ISO/IEC/IEEE 15939:2017 Systems and Software Engineering—Measurement Process, 2017.

[KR93] Ralph L. Keeney and Howard Raiffa. Decisions with Multiple Objectives: Preferences and Value Trade-Offs. Cambridge University Press, revised edition, 1993.

[MNM20] Arthur-Jozsef Molnar, Alexandra Neamţu, and Simona Motogna. Evaluation of software product quality metrics. arXiv preprint arXiv:2009.01557, 2020.

[NSS+08] Michela Nardo, Michaela Saisana, Andrea Saltelli, Stefano Tarantola, Anders Hoffman, and Enrico Giovannini. Handbook on Constructing Composite Indicators: Methodology and User Guide. OECD Publishing, 2008.

[Roy96] Bernard Roy. Multicriteria Methodology for Decision Aiding. Kluwer Academic Publishers, 1996.

[Ste46] S. S. Stevens. On the theory of scales of measurement. Science, 103(2684):677–680, 1946.