Measuring Architecture Characteristics

Key Insight

Organizations frequently struggle with vague or inconsistent definitions of architecture characteristics, making it difficult to design for concepts like 'agility' or 'deployability'. Even within a single organization, different departments may have varying interpretations of critical features like 'performance'. Furthermore, many desirable characteristics are composite, meaning they can be broken down into smaller, measurable components; for instance, 'agility' can be decomposed into 'modularity', 'deployability', and 'testability'. Establishing objective, organization-wide definitions for these characteristics creates a ubiquitous language, resolving these definitional challenges and allowing teams to unpack composite traits into objectively measurable features.

Operational characteristics often have direct but nuanced measurements. For 'performance', average response time is a common metric, but it may fail to capture outliers, such as 1% of requests taking 10 times longer than others; thus, maximum response times are also crucial. Beyond general performance, organizations establish specific performance budgets, like an optimum 500 ms for first-page render, a critical metric for modern sites aiming to capture users. K-weight budgets for page downloads, which define maximum allowed bytes for libraries and frameworks, derive from physics constraints and are especially relevant for mobile devices in high-latency areas. Scalability can be monitored using statistical models that detect deviations from predicted behavior, indicating either a model inaccuracy or a system anomaly. Evolving metrics like 'first contentful paint' and 'first CPU idle' provide deeper insights into user experience on mobile devices.

Structural characteristics, such as modularity, are less straightforward to measure objectively, though some tools address narrow dimensions like code complexity. Cyclomatic Complexity (CC), developed in 1976, provides an objective measure for the complexity of code at various levels (function, method, class). It is calculated by applying graph theory to decision points in code, with CC = E - N + 2 (edges minus nodes plus two) for a single function. A function with no decision statements has a CC of 1, while a single conditional yields a CC of 2. For example, a given C-like function with two 'if/else if' conditions and one final 'else' has a CC of 3. High CC values are universally considered a 'code smell' that harms modularity, testability, and deployability. While a CC under 10 is often deemed acceptable, a value under 5 is preferred for cohesive, well-factored code. Tools like Crap4J indicate 'crappy' code if CC exceeds 50, regardless of code coverage. Engineering practices like test-driven development (TDD) inadvertently lead to smaller, less complex methods with lower CC by focusing on discrete behaviors and test boundaries.