How to Evaluate an Architecture: The Five Key Dimensions

Architecture Evaluation Model

┌─────────────────────┐
                │   Architecture Evaluation Model   │
                └─────────────────────┘
                               │
          ┌──────────────────────┼──────────────────────┐
          │                      │                      │
 ┌──────▼──────┐        ┌──────▼──────┐        ┌──────▼──────┐
 │ Function    │        │ Quality     │        │ Cost        │
 │ Dimension   │        │ Dimension   │        │ Dimension   │
 │ • Requirement coverage │ │ • Performance │ │ • Development cost │
 │ • Functional completeness │ │ • Availability │ │ • Operations cost │
 │              │        │ • Scalability │ │ • Change cost │
 └──────────────┘        └──────────────┘        └──────────────┘
                               │
                ┌─────────┴─────────┐
                │                     │
          ┌──────▼──────┐   ┌──────▼──────┐
          │ Risk       │   │ Team        │
          │ Dimension  │   │ Dimension   │
          │ • Technical risk │ │ • Team capability │
          │ • Business risk │ │ • Collaboration │
          └──────────────┘   └──────────────┘

Function Dimension

Requirement Coverage

Requirement list:
[✓] Functional requirement 1 → System supports
[✓] Functional requirement 2 → System supports
[✗] Functional requirement 3 → Partially supported
[✓] Functional requirement 4 → System supports

Coverage = 3/4 = 75%

Functional Completeness

Core functions – must be satisfied

Auxiliary functions – should be satisfied

Extension functions – preferably satisfied

Functional Correctness

Verification methods:
1. Design review
2. Prototype demonstration
3. Functional testing
4. User acceptance

Quality Dimension

Performance

Response time – P50/P90/P99, target P99 < 500 ms

Throughput – QPS/TPS, target QPS > 10 000

Resource utilization – CPU/Memory/IO, target < 80 %

Availability

99 % – 3.65 days downtime (normal availability)

99.9 % – 8.76 hours downtime (high availability)

99.99 % – 52 minutes downtime (telecom‑grade)

99.999 % – 5 minutes downtime (financial‑grade)

Scalability

Horizontal scaling – add machines (low cost)

Vertical scaling – upgrade configuration (medium cost)

Service scaling – add services (high cost)

Maintainability

Code readability – easy to understand (high goal)

Module independence – low coupling, > 50 % modules without dependencies

Deployment complexity – deployment time < 30 minutes

Cost Dimension

Development Cost

Development cost = Personnel × Time × Unit price
Example:
- Team: 5 people
- Development: 3 months
- Average cost: 20 000 CNY per person per month
Development cost = 5 × 3 × 20 000 = 300 000 CNY

Operations Cost

Cloud service fee (servers, middleware) – X CNY/month

Personnel cost (operations team) – Y CNY/month

Training cost (technical learning) – Z CNY/quarter

Change Cost

Small demand – < 1 week, simple modification

Medium demand – 1‑4 weeks, involves 1‑2 modules

Large demand – > 4 weeks, involves multiple modules/architectures

ROI Evaluation

ROI = (Benefit - Cost) / Cost × 100 %
Benefit:
- Business value
- Efficiency improvement
- Risk reduction
Cost:
- Development cost
- Operations cost
- Change cost

Risk Dimension

Technical Risk

Wrong technology choice – Likelihood: Medium, Impact: High, Mitigation: POC verification

Performance not meeting target – Likelihood: High, Impact: High, Mitigation: Performance testing

Insufficient scalability – Likelihood: Medium, Impact: Medium, Mitigation: Architecture review

Security vulnerability – Likelihood: Low, Impact: High, Mitigation: Security audit

Business Risk

Requirement changes – Likelihood: High, Impact: Medium, Mitigation: Agile iteration

Traffic exceeds expectations – Likelihood: Medium, Impact: High, Mitigation: Capacity planning

Compliance issues – Likelihood: Low, Impact: High, Mitigation: Compliance review

Operations Risk

System failure – Likelihood: Medium, Impact: High, Mitigation: High‑availability design

Data loss – Likelihood: Low, Impact: High, Mitigation: Backup mechanisms

Operations incident – Likelihood: Medium, Impact: Medium, Mitigation: Standardized processes

Team Dimension

Capability Matching

Architecture complexity vs. team capability
Match assessment factors:
- Familiarity with tech stack
- Architecture design experience
- Problem‑solving ability
- Learning ability

Match → feasible
Mismatch → training needed or adjust architecture

Collaboration Assessment

Team collaboration assessment:
1. Team size
   - 3‑5 people: small team
   - 10‑20 people: medium team
   - 50+ people: large team
2. Communication complexity
   - Face‑to‑face: simplest
   - Cross‑region: moderate
   - Cross‑company: complex
3. Collaboration mechanism
   - With standards: orderly
   - Without standards: chaotic

Architecture Evaluation Matrix

Composite Scoring

# Architecture Composite Evaluation Table
| Dimension          | Weight | Score (1‑5) | Weighted Score |
|--------------------|--------|------------|----------------|
| Functional completeness | 20% | 4 | 0.8 |
| Performance        | 15% | 4 | 0.6 |
| Availability       | 15% | 5 | 0.75 |
| Scalability        | 10% | 3 | 0.3 |
| Maintainability    | 10% | 4 | 0.4 |
| Development cost   | 10% | 4 | 0.4 |
| Operations cost    | 10% | 3 | 0.3 |
| Risk               | 10% | 4 | 0.4 |
**Composite Score**  **3.95/5**

Evaluation Results

> 4.5 – Excellent – can be implemented

4.0‑4.5 – Good – can be implemented, watch improvement points

3.5‑4.0 – Average – needs improvement before implementation

3.0‑3.5 – Poor – requires major improvement

< 3.0 – Fail – needs redesign

Evaluation Practice

Evaluation Process

Define evaluation objectives (scope, standards)

Gather information (design documents, performance data, risk list)

Score each dimension (Function, Quality, Cost, Risk, Team)

Aggregate assessment (weighted calculation, conclude)

Provide suggestions (improvement measures, monitoring indicators)

Evaluation Principles

Objectivity : evaluate from multiple dimensions.

Quantitative analysis : let data speak.

Trade‑offs : no perfect architecture.

Fit for purpose : meet current stage needs.

There is no best architecture, only one that fits the current requirements, team, and cost constraints .