Prioritizing Architecture Drivers with Explicit Scoring

Good to see you again. In the previous lesson, you turned the campaign-checkout objective into measurable quality-attribute scenarios: peak checkout responsiveness, safe payment recovery, support diagnosis, and similar outcomes. Those scenarios are useful only if they influence decisions. A team cannot optimize every quality attribute equally, especially under a campaign deadline and limited operational maturity.

This lesson introduces a lightweight, explicit way to decide which scenarios are architecture drivers: the few requirements that should shape the system’s structure, early technical investigation, and trade-off discussions. Plan for about 45 minutes.

---

Prioritization is not merely a ranked backlog

An architecture driver is a requirement or constraint with enough business consequence and technical impact that it must influence the architecture early.

For the checkout case, these statements are all reasonable:

• Customers should receive a response quickly at campaign peak.
• A payment timeout must not cause duplicate payment attempts.
• Support should identify an uncertain order state without an engineer.
• A new sales channel should be added without breaking existing clients.
• An internal analytics report should complete promptly.

But they are not equally consequential. If payment correctness is weak, customers may be charged twice, orders may be disputed, and trust may be damaged. If an internal report is slow, the effect may be inconvenient but tolerable. Treating both as equally important would lead either to over-engineering or to missed risk.

Prioritization helps you answer three Staff-level questions:

1. What must shape the first architecture decisions?
2. Where should the team obtain evidence before committing?
3. Which desirable qualities are deliberately deferred or bounded?

This is not a way to declare that lower-priority concerns are unimportant. It is a way to make limits and trade-offs visible.

A crucial distinction:

Activity	Question answered	Example
Prioritizing drivers	Which requirements deserve architectural attention first?	“Payment recovery during a provider outage is H,H.”
Choosing an option	Which design best satisfies the prioritized drivers?	“Should recovery use synchronous reconciliation, asynchronous processing, or both?”
Planning delivery	What work is done first and by whom?	“Implement idempotency-key persistence in Sprint 2.”

This lesson is about the first activity. Do not jump directly from “high priority” to “use Kafka,” “use Kubernetes,” or “split into microservices.”

---

Two inputs: business value and technical effort

A practical early-stage method assigns each quality scenario a two-part priority tuple:

$$(\text{business value},\text{technical effort})$$

Each part uses a deliberately coarse scale:

• H — high
• M — medium
• L — low

The first score comes primarily from business stakeholders. The second comes primarily from technical stakeholders. Separating them matters: engineering should not silently decide what the business values most, and business should not be expected to estimate the architectural consequences.

The utility-tree image below illustrates this notation at the leaves of a quality-attribute tree.

Score business value

Business value asks: what is the consequence if this scenario is not met?

Use evidence where possible: revenue exposure, customer harm, contractual obligations, legal risk, operational cost, strategic deadlines, and impact on a critical journey.

Score	Meaning	Checkout example
H	Failure threatens a critical customer outcome, material revenue, trust, compliance, or launch viability.	A provider timeout creates duplicate charges or an ambiguous payment result.
M	Failure creates material support cost, delivery friction, or a meaningful but non-critical business limitation.	Support cannot resolve an uncertain order without escalating to engineering.
L	Failure is inconvenient but recoverable, localized, or can be safely deferred.	A non-critical analytics view is slower than desired.

Do not score based on who speaks most loudly. “High” needs a stated consequence:

“If we cannot safely recover a payment timeout, the campaign may generate duplicate charges and manual reconciliation.”

That is much more useful than:

“Payments are important.”

Score technical effort

Technical effort asks: how much architectural work, uncertainty, or cross-cutting change is needed to achieve the scenario reliably?

At this stage, it is not a detailed person-day estimate. It is a statement about architectural significance.

Score	Meaning	Checkout example
H	Requires a structural choice, unfamiliar capability, external-contract validation, or changes across several components and teams.	Durable payment state, idempotency, recovery, reconciliation, and customer-visible status must work together.
M	Requires meaningful design and coordination, but the approach is reasonably understood.	Adding an internal order-status view using established identity and observability capabilities.
L	Can likely be addressed locally using understood practices, with limited cross-team impact.	Adding a narrow diagnostic field to an existing support screen.

Technical effort should be grounded in evidence, not fear of the unfamiliar. Ask:

• Does this scenario cross service, database, team, or vendor boundaries?
• Are key facts still unknown—for example, payment-provider idempotency semantics?
• Does it constrain data ownership, deployment, security, or runtime behavior?
• Would a late discovery force expensive rework?
• Do we already have a proven capability, or are we assuming one?

A scenario can be high business value and low effort. That is good news: satisfy it, verify it, and move on. A scenario can also be low business value and high effort. That is a warning: either reduce its scope, defer it, or challenge whether it is really needed.

---

---

A repeatable workshop method

For an initiative such as campaign checkout, use the following sequence. It is lightweight enough for a 45- to 60-minute workshop, provided scenarios have already been drafted.

1. Start with scenarios, not abstract labels

Score concrete scenarios, rather than scoring broad labels such as “performance” or “security.”

Weak input:

Performance is high priority.

Useful input:

During the confirmed campaign peak, customers submitting checkout receive an unambiguous result with $p95$ response time at most two seconds.

Why? “Performance” might mean customer latency, batch throughput, database reporting speed, or internal job duration. The measurable scenario reveals the actual trade-off.

2. Remove duplicates and separate constraints

Consolidate scenarios that express the same concern. For example, these may be variants of one driver:

• payment timeout does not create duplicate attempts;
• customer retry does not create a duplicate order;
• a lost provider response can be reconciled safely.

They may later need separate tests, but initially they can be grouped under payment correctness and recovery.

Then separate non-negotiable constraints from preferences.

Examples:

• “The campaign must launch by 1 November” is a delivery constraint.
• “The Order Service must not store cardholder data” is a security/compliance constraint.
• “No customer can retrieve another customer’s order status” is a testable security scenario.

A hard constraint is a gate, not an item that can lose a popularity contest. If regulatory or contractual requirements make authorization mandatory, every acceptable architecture must satisfy it, regardless of its tuple score.

3. Let stakeholders express business value

For a small workshop, give each stakeholder a fixed number of dots. The Mini-QAW rule is:

$$\text{dots per participant}=\frac{\text{number of scenarios}}{3}+1$$

With six scenarios, each participant receives three dots. They may place all three on one scenario or distribute them.

Dot voting is not a replacement for conversation. It reveals where conversation is needed:

• A scenario with many votes is clearly salient.
• A scenario valued only by one stakeholder may represent a hidden risk, such as security or support cost.
• A sharp disagreement may mean stakeholders are assuming different operating conditions.

After voting, agree a business-value rating of H, M, or L, and record the rationale. Keep the raw vote total as evidence—especially for ties.

4. Have technical representatives rate effort independently

The architecture and delivery representatives then assign technical effort. Do this after business value is visible, but do not let it be dictated by it.

For example:

“We rate payment recovery H because we have not verified the provider’s idempotency behavior after a response timeout; the solution affects checkout, order state, payment attempts, reconciliation, and support visibility.”

That statement is much stronger than:

“It feels complex.”

5. Form the tuple and apply a published ordering

The SEI-style utility-tree method orders tuples as follows:

$$(H,H),(H,M),(H,L),(M,H),(M,M),(M,L),(L,H),(L,M),(L,L)$$

Business value comes first. Within the same level of business value, high technical effort receives earlier architectural attention because it is more likely to constrain the system or create late risk.

The ordering does not mean “build the hardest thing first.” It means:

• investigate and shape the high-value, high-effort concerns early;
• use them to evaluate structural choices;
• avoid spending architecture time on low-value concerns unless they become constraints or risks.

An $(L,H)$ scenario is especially informative. It says: “We are considering spending a great deal of technical effort on something with limited business return.” Usually that deserves a scope conversation, not enthusiastic implementation.

---

Worked prioritization: campaign checkout

Assume five stakeholders participate:

• product lead,
• campaign manager,
• payments owner,
• support lead,
• engineering/operations representative.

They score six candidate scenarios. Each receives three dots, producing 15 votes in total.

Candidate quality scenario	Stakeholder votes	Business value	Technical effort	Tuple
A. A payment timeout or customer retry never produces duplicate confirmed orders or payment attempts; uncertain cases are reconciled.	5	H	H	$(H,H)$
B. At confirmed campaign peak, checkout returns a clear outcome within agreed latency targets.	4	H	H	$(H,H)$
C. A customer can access only their own order status.	3	H	M	$(H,M)$
D. Support can determine an uncertain order’s status in three minutes without engineering intervention.	2	M	L	$(M,L)$
E. A new sales channel can submit orders without breaking existing clients.	1	M	M	$(M,M)$
F. A non-critical analytics report completes within 30 seconds.	0	L	L	$(L,L)$

Applying the published ordering produces this architecture-attention order:

1. A and B — $(H,H)$: payment correctness/recovery and peak checkout performance
2. C — $(H,M)$: order-status authorization
3. E — $(M,M)$: new sales-channel extensibility
4. D — $(M,L)$: support diagnosis
5. F — $(L,L)$: analytics-report responsiveness

This result is not an implementation plan. It tells us what must drive the initial architecture.

Interpreting the top drivers

A: Payment correctness and recovery is high value because duplicate charges and ambiguous outcomes directly threaten customer trust, revenue, and support capacity. It is high effort because it crosses application state, payment-provider behavior, retry semantics, persistence, recovery, and user-facing communication.

This driver will force early questions such as:

• What idempotency capability does the payment provider actually offer?
• What durable order states are acceptable?
• Can reconciliation query the provider after an uncertain result?
• How will the system distinguish “not attempted,” “pending,” “confirmed,” and “declined”?

B: Peak checkout performance is also high value and high effort. It affects campaign revenue, but its actual difficulty is currently uncertain because workload assumptions have not yet been validated. It will force early investigation of expected request rate, concurrency, dependency limits, database capacity, and degradation behavior.

Because A and B have the same tuple, retain both as co-drivers. Use the vote total as one transparent tie-breaker for discovery sequencing: investigate A first because it received five votes and depends on external-provider semantics that may take time to validate. Do not pretend that a difference of one vote proves payment recovery is objectively “more important” than performance.

C: Order-status authorization has high business value. If it is driven by a legal, contractual, or security-policy obligation, treat it as a mandatory acceptance gate. The $(H,M)$ tuple then helps estimate the architecture attention it needs, but never permits an option that fails the constraint.

What the ranking deliberately does not say

The ranking does not say:

• ignore support diagnosis until the end;
• deploy only after every H,H scenario is perfectly solved;
• choose a distributed architecture because performance is H,H;
• choose microservices because a future sales channel is M,M;
• accept poor analytics indefinitely.

Instead, it says that an initial design that is unable to explain payment recovery and peak behavior is not ready for approval, even if it has attractive service boundaries or clean APIs.

---

Avoid three scoring failures

1. False precision

At this stage, a score of 87.5 versus 85.0 usually conveys more certainty than the evidence supports. H/M/L is intentionally coarse. It encourages the conversation to focus on meaning:

“Why is this high value?”
“What would make effort lower?”
“Which assumption could change this tuple?”

Use finer-grained numerical weighting only when the decision truly needs it and stakeholders can justify the weights.

2. Treating the scores as permanent facts

Priorities change when evidence changes. Suppose load testing shows the forecast peak is one-tenth of the initial assumption. Scenario B may move from $(H,H)$ to $(H,M)$. Conversely, if the payment provider cannot support idempotency keys or reconciliation queries, scenario A may become even more urgent.

Record the assumptions behind every score, then revisit the top drivers at significant milestones:

• after discovery with an external provider;
• after a workload estimate or load test;
• after a security review;
• before committing to an expensive or hard-to-reverse structure.

3. Collapsing value and effort into one vague label

Avoid statements such as “payment reliability is priority 1” unless people can see why. A single number hides the main trade-off.

Compare:

Opaque statement	Useful statement
“Payment recovery is priority 1.”	“Payment recovery is $(H,H)$: failure risks duplicate charges, and safe recovery requires unvalidated external-provider behavior plus cross-service state handling.”
“Supportability is low priority.”	“Support diagnosis is $(M,L)$: it meaningfully reduces escalations and is achievable with bounded, known changes after the core recovery state is designed.”

The second form equips a Staff Engineer to explain a recommendation to product, operations, and engineering without overstating certainty.

---

---

The one-page driver register

After the workshop, create a small register. This becomes useful input for design reviews, technical briefs, and later architecture decision records.

Field	What to record
Scenario	The refined, measurable quality-attribute scenario.
Business value	H, M, or L, plus the business consequence.
Technical effort	H, M, or L, plus technical rationale.
Tuple and rank	For example, $(H,H)$, co-driver rank 1.
Evidence	Votes, production data, forecast, contract, incident history, or customer research.
Assumptions	What has not yet been validated.
Owner and next action	Who will validate the uncertainty and by when.

For scenario A, a useful entry could be:

Assumption: The payment provider accepts an idempotency key and exposes a reconciliation query for uncertain requests.
Owner: Payments integration lead.
Next action: Obtain provider documentation and run a timeout/retry sandbox test before selecting a payment workflow.

This is what turns a score from a meeting artifact into an architecture-management tool.

---

Key takeaways

• Prioritize concrete quality scenarios, not broad labels such as “performance” or “security.”
• Use a transparent tuple: $(\text{business value},\text{technical effort})$.
• Business stakeholders score consequence; technical stakeholders score architectural effort and uncertainty.
• The ordering $(H,H)$, $(H,M)$, $(H,L)$, and so on identifies what should shape architecture and discovery early.
• Treat mandatory compliance, security, and contractual requirements as gates, not items that can lose a vote.
• Preserve assumptions, rationale, disagreement, and validation actions alongside every score.
• A priority score does not choose a technology. It tells you which requirements any acceptable design must address.

Next, you will create a system-context diagram for the campaign-checkout case. The prioritized drivers from this lesson will help determine which people, external systems, and trust or dependency boundaries must be visible in that diagram.