Weighted Scoring Analysis in Software Architecture

This article explains weighted scoring analysis (WSA) for architecture decisions — including a sample matrix and exam-relevant points.

In a Nutshell

Weighted scoring analysis helps you select an appropriate software architecture by comparing alternatives (such as monolith, microservices, n-tier, or event-driven) against defined and weighted criteria.

Definition

The process:

Define project goals
Identify alternatives
List criteria (for example: scalability, maintainability, security, effort)
Weight the criteria
Rate each alternative (scale 1–10)
Calculate scores (weight × rating) and sum them

The result is a decision framework that stakeholders across teams can understand and discuss.

Key Points for Certification

Criteria: scalability, maintainability, complexity, security, cost
Weighting depends on project needs
Use a consistent rating scale
IHK certification: methodical proof of decision (matrix + justification)
Address security aspects explicitly as a criterion
Supplement with total cost of ownership (TCO)
Document all calculation steps

Core Components

1. Goal Definition

Before rating anything, you must be clear on what problem the architecture solves. Typical goals include:

Cover functional requirements (use cases, user stories)
Meet non-functional requirements (performance, security, availability)
Stay within budget and timeline
Handle scaling needs (user growth, data volume, transactions per second)

Without clear goals, criteria become arbitrary and the WSA loses credibility.

2. Identify Alternatives

Define at least two, ideally three to five realistic architecture options. Examples:

Monolith — all modules in a single deployable unit
Microservices — independent services, separate database per service
Layered (n-tier) — tier-based architecture (presentation, business, data)
Event-Driven Architecture (EDA) — asynchronous communication via events
Serverless — functions-as-a-service, no infrastructure management

Each alternative should have a brief description so evaluators share the same understanding.

3. Criteria List

Criteria must be measurable, independent, and relevant to your project. Typical criteria for architecture decisions:

Criterion	Question	Scale
Scalability	Can the system handle growing load?	1–10
Maintainability	How easily can we fix bugs and apply updates?	1–10
Security	How well can we integrate security controls?	1–10
Effort / Cost	What are implementation and operational costs?	1–10
Extensibility	How readily can we add new features?	1–10
Performance	How low are latency and response times?	1–10
Team Familiarity	How comfortable is the team with this approach?	1–10
Fault Tolerance	How robust is the architecture during outages?	1–10

Important: Criteria should not overlap. “Performance” and “scalability” are related but distinct — performance measures latency under load, scalability measures growth potential.

4. Weighting (%)

Each criterion gets a weight in percent, with all weights summing to 100 %. Weighting is project-specific:

E-commerce platform: Scalability 30 %, Performance 20 %, Security 20 %, Maintainability 15 %, Effort 15 %
Banking system: Security 35 %, Maintainability 20 %, Fault Tolerance 20 %, Scalability 15 %, Effort 10 %
Prototype / MVP: Effort 40 %, Team Familiarity 25 %, Maintainability 20 %, Scalability 15 %

Discuss and document the weighting with your team to reduce bias.

5. Rate Each Alternative

Score every alternative per criterion on a scale of 1–10 (1 = very poor, 10 = excellent). Back up each rating with:

Real experience from similar projects
Benchmarks or prototype results
Expert opinion or published research

6. Calculate Scores (Weight × Rating)

The score for each cell is:

Score = (Weight in %) × (Rating 1–10)

The total score for an alternative is the sum of all cell scores.

7. Compare Total Scores

The alternative with the highest total score wins. The gap should be significant (at least 10 % difference), otherwise the decision is unclear.

8. Interpretation and Justification

Explain the result:

Which alternative wins and why?
Which criteria were decisive?
What are the chosen architecture’s weaknesses?
What risks remain?

9. Supplement with Risk Analysis

WSA alone is not enough — add a risk analysis to identify:

Technical risks (new technology, team inexperience)
Organizational risks (team size, knowledge transfer)
Economic risks (vendor lock-in, licensing costs)
Dependencies (external services, third-party libraries)

10. Document the Decision

Capture the entire WSA as an Architecture Decision Record (ADR):

Context and problem statement
Alternatives considered
Criteria and weighting (with justification)
Scoring matrix
Total scores
Decision and rationale
Risks and mitigation

Example (Scoring Matrix)

Three architecture options for an e-commerce platform:

Criterion	Weight	Monolith	Microservices	Layered (n-tier)
Scalability	25 %	6	9	7
Maintainability	20 %	5	8	7
Security	15 %	6	7	6
Effort	20 %	9	5	7
Extensibility	20 %	6	8	8

Score calculation:

Criterion	Weight	Monolith	Microservices	Layered
Scalability	25 %	0.25 × 6 = 1.50	0.25 × 9 = 2.25	0.25 × 7 = 1.75
Maintainability	20 %	0.20 × 5 = 1.00	0.20 × 8 = 1.60	0.20 × 7 = 1.40
Security	15 %	0.15 × 6 = 0.90	0.15 × 7 = 1.05	0.15 × 6 = 0.90
Effort	20 %	0.20 × 9 = 1.80	0.20 × 5 = 1.00	0.20 × 7 = 1.40
Extensibility	20 %	0.20 × 6 = 1.20	0.20 × 8 = 1.60	0.20 × 8 = 1.60
Total	100 %	6.40	7.50	7.05

Result: Microservices wins at 7.50 points despite higher effort (only 5/10), because scalability and maintainability carry more weight. The gap to layered architecture (7.05) is small at 0.45 points — a risk analysis here would be prudent.

Strengths and Weaknesses

Strengths

Transparent decision-making — every calculation step is documented
Compares technical and financial criteria in one matrix
Works well in stakeholder workshops — structured discussion, transparent weights
Minimizes gut-feel decisions — forces you to think through criteria and priorities
Reusable — adapt the criteria list for similar decisions later

Drawbacks

Subjectivity is inevitable — ratings and weightings depend on the evaluator
Consensus can be time-consuming — especially in larger teams with diverse perspectives
Criteria may overlap — requires active management (e.g., performance versus scalability)
The scale is arbitrary — a 1–10 range is ordinal, not metric
Can create false precision — a score of 7.50 versus 7.05 implies accuracy that subjective ratings cannot deliver

Common Exam Questions (with Brief Answers)

What is an architecture NWA used for? A structured comparison of architectural approaches based on weighted criteria.
How is utility value calculated? Weight × score, then sum all criteria for each alternative.
How do you reduce bias? Team validation, clear criteria definitions, consistent scales, and justification for every score.
What matters in weighting? Sum must equal 100%, be project-dependent, discussed as a team, and documented.
Why is risk analysis important alongside NWA? NWA captures only measurable criteria, not unknown or hard-to-quantify risks.

Free-Form Answer

In IHK projects, an NWA can make your “Alternative Evaluation” section significantly stronger when criteria, weightings, and calculations are documented transparently. Especially in AP2 project proposals, an NWA is an excellent tool to methodically justify your architecture decision. Examiners immediately see that the choice wasn’t made “from the gut” but resulted from systematic comparison.

Learning Strategy

Define three architectural alternatives (e.g., monolith, microservices, layered).
Write five non-overlapping criteria.
Set weightings (sum = 100%) and justify them.
Calculate the matrix, interpret the result, and explain your reasoning.
Add a risk analysis and document it as an ADR.

Continue at https://www.irc-coding.de/nutzwertanalyse-grundlagen-kriterien-gewichtung

FAQ — Frequently Asked Questions about Utility Analysis in Software Architecture

What is a utility analysis in software architecture?

Utility analysis (NWA) is a method for systematically evaluating and selecting architectural alternatives. Multiple options (e.g., monolith, microservices, n-tier) are compared using defined, weighted criteria such as scalability, maintainability, security, and effort. Each alternative receives a score of 1–10 for each criterion; utility value is calculated as weight × score and summed across all criteria.

How is the total utility value of an architectural alternative calculated?

Total utility value is the sum of all individual utility values. Each individual value is calculated as weight (as a percentage) × score (1–10). For example: scalability 25%, score 9 → utility value = 0.25 × 9 = 2.25. All utility values for an alternative are added together. The alternative with the highest sum wins.

What criteria are typical for an architecture NWA?

Typical criteria include scalability, maintainability, security, effort/cost, extensibility, performance, fault tolerance, and team experience. Criteria must be measurable and independent of each other. Overlaps (e.g., performance versus scalability) must be avoided, as they lead to double-weighting.

Why must the sum of weightings equal 100%?

A sum of 100% ensures that all criteria together form a complete evaluation profile and total utility values remain comparable. Without this normalization, alternatives with different weighting sums would be compared unfairly. Moreover, the 100% rule forces prioritization: a higher weight for one criterion automatically means a lower weight for another.

How do you reduce subjectivity in utility analysis?

Subjectivity is reduced through team validation (multiple evaluators), clear criterion definitions, consistent rating scales, justification for each score, use of benchmarks or prototype results, and transparent documentation of the entire process. A sensitivity analysis (varying weights and checking whether results remain stable) also helps.

What is an Architecture Decision Record (ADR) and how does it relate to NWA?

An ADR is a structured document that captures an architecture decision including context, alternatives, rationale, and consequences. The NWA provides the methodological foundation for the ADR: criteria, weightings, the scoring matrix, and total utility values are incorporated into the ADR, making the decision traceable and audit-proof.

What if two alternatives have very similar total utility values?

If the difference is less than 10%, the result should be treated as inconclusive. A sensitivity analysis (slightly varying weights and checking whether the ranking remains stable), a supplementary risk analysis, or the addition of discriminating criteria may help. You may also need to defer the decision until more information becomes available.

Is utility analysis relevant in IHK exams?

Yes. In the IHK final exam for IT specialists (especially the AP2 project proposal), an NWA can methodically strengthen your “Alternative Evaluation” section. The examiner sees that a systematic, traceable decision was made. All calculation steps must be documented: criteria, weightings, scoring matrix, calculations, and decision rationale.

Can utility analysis be used for decisions other than architecture questions?

Yes. Utility analysis is universally applicable: for selecting frameworks, databases, cloud providers, CI/CD tools, or even in make-or-buy decisions. Wherever multiple alternatives need to be compared using weighted criteria, NWA works. The criterion list must be tailored to the specific decision.

What additions to utility analysis are recommended?

Recommended additions include a risk analysis (identifying non-quantifiable risks), a total cost of ownership (TCO) calculation (capturing long-term costs), a sensitivity analysis (checking result stability when weights vary), and a proof of concept (validating assumptions through a prototype). Together, these create a robust decision framework.

Täglicher Artikel