Context, Concern, Requirements, Options, and Decision

Goal

Earlier chapters introduced patterns and the concerns they address. This section turns that knowledge into a repeatable conversation: describe the situation, identify the decision that matters, compare realistic options, and make a choice that another person can understand.

The durable idea is:

Good architecture decisions start with context and concern before they compare options.

The Short Version

Use the first half of the decision frame to move from an unclear problem to a defensible choice:

context -> concern -> requirements -> options -> decision

Each step removes a different kind of ambiguity. Context says where the decision lives. Concern says why it matters now. Requirements define what success must look like. Options make comparison possible. The decision states the choice and its reason.

Do not treat the frame as paperwork. It is a thinking tool and a compact way to make assumptions visible before they become expensive.

Five Pieces of a Clear Decision

This anatomy resembles an architecture decision record, often shortened to ADR. The format is less important than preserving the reasoning. A short record that exposes context, alternatives, and consequences is more useful than a polished diagram with no explanation.

Separate the Concern from the Proposed Solution

Teams often arrive with a sentence such as, "We need Kubernetes," "We should use events," or "We need a second region." Those statements are options disguised as requirements.

Ask one level deeper:

• Is the concern independent deployment, runtime portability, or team autonomy?

• Is the concern slow customer response, unreliable downstream processing, or broad notification?

• Is the concern regional failure, a recovery-time target, or a contractual continuity obligation?

Once the concern is clear, the option set usually becomes wider and the comparison becomes more honest.

Requirements need the same discipline. "Fast," "secure," and "highly available" express intent but cannot guide a decision alone. Stronger requirements name a target, condition, or boundary: the checkout response must meet an agreed latency objective at forecast peak load; customer data must stay within approved locations; the service must recover within the business's agreed time and data-loss limits.

Not every requirement needs a number, but every important one should be clear enough to test or review.

Example: Hosting a Commerce API

A team needs to replace an aging commerce API host. Starting with "Which runtime should we buy?" would make the conversation a product comparison. Start with the workload instead.

Context: The API serves storefront and mobile clients. Demand rises sharply during campaigns. The team is small, releases several times a week, handles customer data, and has limited appetite for operating a container control plane.

Concern: Releases and traffic peaks create avoidable operational risk. The team needs predictable scaling and safer delivery without taking on more platform work than it can sustain.

Requirements:

• meet the agreed latency and availability objectives at expected peak load;

• use private, identity-controlled access to sensitive dependencies;

• support automated rollout, rollback, logging, metrics, and tracing;

• keep runtime operations within the team's skills and support capacity;

• remain inside an agreed cost envelope.

Options:

1. Improve the existing virtual-machine deployment.

2. Move to a managed application or container runtime.

3. Build on a managed Kubernetes platform.

Decision: Use a managed application runtime because it satisfies the scaling, deployment, security, and observability requirements while keeping platform ownership proportionate to the team. Do not choose Kubernetes now; its control and ecosystem flexibility do not address a current requirement strongly enough to justify the additional operating responsibility. Keep the decision reviewable if workload or organizational needs change.

Notice what makes this decision credible. The runtime category is not declared universally better. It is better for this context, concern, and requirement set.

Write the Decision So It Can Be Revisited

A decision record should be brief enough to read and complete enough to challenge. A practical shape is:

Title and status
Context and concern
Architecturally significant requirements
Options considered
Decision and rationale
Consequences and follow-up
Owner and review trigger

Record assumptions whose failure would change the answer. In the API example, team size, traffic shape, control requirements, and platform maturity are decision inputs. If one changes, revisiting the decision is healthy design, not an admission that the original choice was wrong.

Common Mistakes

• Starting with a favored product or pattern and reverse-engineering the problem around it.

• Writing an option such as "use serverless" as though it were a requirement.

• Giving every desirable quality equal priority instead of naming the dominant concern.

• Comparing one detailed option with two vague straw alternatives.

• Recording the selected choice without the context that made it reasonable.

• Treating a previous decision as permanent after its assumptions have changed.

If Someone Asks You

What should come before an architecture decision?

A good answer is:

Start with the workload context and the concern that makes a decision necessary. Turn that concern into clear requirements, compare a small set of viable options, and choose the option whose consequences best fit the situation. Product names come after the problem and success conditions are understood.

What You Should Remember

The right decision is easier to defend when the problem is clear first.

Questions to Check Your Understanding

1. In the commerce API example, which statement is the concern and which statements are requirements?

2. Why should retaining the current design sometimes appear in the option set?

3. Which changed assumption would cause you to revisit the hosting decision?

Further Study

• Maintain an architecture decision record - See how context, options, decisions, and consequences can be kept as a durable decision log.

• ADR process - Review a practical lifecycle and content model for architecture decision records.