Architecture Brief: Goals, Exclusions, Assumptions, and Open Questions

Welcome back. In the previous lesson, you created a system-context diagram for the Campaign Checkout System: customers and support agents interact with it; sales channels and the Payment Provider sit outside its boundary. You also made several uncertainties visible instead of quietly turning them into design decisions.

This lesson turns that shared picture into a compact architecture brief. Its purpose is not to specify Spring Boot services or choose Kafka, PostgreSQL, or Kubernetes. It gives product, delivery, operations, and technical stakeholders a reviewable statement of what the initiative is trying to achieve, what it deliberately will not do, what is currently being assumed, and what must be answered before deeper design begins.

Plan for about 40 minutes: a short resource review, then a focused drafting pass on the campaign-checkout case.

---

A one-page brief is a framing artifact

A one-page architecture brief is a deliberately constrained document. The page limit forces prioritization: a reader should be able to understand the initiative’s boundaries and uncertainties in a few minutes, then know where discussion or discovery is needed.

It is useful before a detailed design document, an RFC, or an architecture decision record (ADR):

Artifact	Primary purpose	Typical timing
Architecture brief	Establish the problem boundary, intended outcomes, and unknowns	At discovery or initiative framing
RFC / design proposal	Compare and recommend technical approaches for substantial work	When options are ready for review
ADR	Record one architecturally significant decision and its consequences	When a decision is made
Detailed design	Specify interactions, components, contracts, failure behavior, and rollout	Once the direction is sufficiently clear

At Staff level, this distinction is important. A document that announces a solution before the team has agreed on goals and constraints does not reduce ambiguity; it merely hides it behind confident terminology.

Thoughtworks’ Enterprise Architecture Playbook describes an RFC as a lightweight, open mechanism for sharing options and gathering delivery-team input. The same mindset applies here: write a brief that creates a productive conversation, not a document that attempts to end one.

A useful test is this:

If a product lead, payment-provider contact, support lead, and senior developer each read the brief, would they agree on the intended outcome, the boundary of the initiative, and the questions they need to help answer?

If not, shorten, sharpen, or reclassify its statements.

---

The four fields: do not mix their meanings

The words goal, exclusion, assumption, and open question are often used loosely. In an architecture brief, they have different jobs.

Field	Meaning	Example for Campaign Checkout
Goal	A desired, observable business or technical outcome	“Customers receive an unambiguous outcome for a submitted checkout request, including safe recovery when payment status is uncertain.”
Exclusion	Work deliberately outside this initiative’s scope	“Replacing the Payment Provider is not part of this initiative.”
Assumption	A provisional statement being used for planning until validated	“Sales channels remain independently owned systems outside the Campaign Checkout boundary.”
Open question	An unanswered item that needs an owner and a decision or evidence	“Does the Payment Provider support an idempotency key and a payment-status lookup?”

Goals: outcomes, not implementation preferences

A goal should say what success looks like without prematurely prescribing how to implement it.

Compare these statements:

• Weak: “Build a Payment Orchestrator microservice.”
• Better: “Ensure each checkout request reaches a recoverable, auditable order outcome even if a payment response is lost.”
• Better still, once evidence is available: “Ensure $99.9\%$ of accepted checkout requests receive a final or explicitly recoverable outcome within the agreed service window.”

The first statement is a solution. The second is an outcome. The third adds a measurable quality attribute. Your earlier driver work provides the source for these measurable scenarios; copy the agreed scenario rather than inventing a latency or availability number to make the document look complete.

A brief can contain a small number of goals—usually three to five. More than that usually indicates that broad product requirements have been copied in without prioritization.

Exclusions: the boundary that protects the work

An exclusion is an intentional “not now,” not an apology for incomplete analysis. It prevents scope expansion and clarifies which responsibilities remain elsewhere.

For this case, sensible exclusions may include:

• Payment processing and Payment Provider internals.
• Replacement or redesign of independently owned sales-channel user interfaces.
• Selection of internal service boundaries, deployment topology, or cloud platform at this framing stage.
• Customer notifications by email or SMS, unless product discovery explicitly adds them.

Be precise about the type of exclusion. “We will not handle authentication” is dangerous if the system must enforce that customers can view only their own orders. Better wording is:

“This initiative must enforce customer-specific order-status access; selecting the source of customer identity is not yet decided.”

Security remains a required outcome; the identity mechanism is still an open design question.

Assumptions: temporary foundations, not disguised facts

An assumption lets discovery and planning move forward despite incomplete information. It should be plausible, consequential, and easy to challenge.

Good assumptions have three properties:

1. They are explicitly marked as provisional.
2. They affect scope, cost, risk, or design direction.
3. They have a validation path.

For example:

“Assumption: Support agents can be given a bounded, authorized view of uncertain order state without direct production-database access. Validate with the support lead and security owner before detailed access-control design.”

Do not list trivial assumptions such as “developers have laptops.” Capture assumptions whose failure would materially change the architecture.

Open questions: questions that cause action

An open-question list becomes useful only when it drives discovery. Each question should identify:

• What needs to be known or decided
• Why it matters
• Who should answer it
• By when, if the decision affects an upcoming milestone

“Clarify payment integration” is not actionable. This is:

“Does the Payment Provider offer both idempotent submission and a query API for reconciling a timed-out payment response? This determines the recovery design. Owner: Payment Provider integration lead. Needed before solution review.”

An unresolved question can later become a confirmed fact, a rejected assumption, a risk, or an ADR decision. The brief is therefore a living artifact, not a one-time ceremony.

---

Write for a reader who was not in the meeting

This short video gives a useful checklist for the wider design-document family: problem, trade-offs, goals and non-goals, assumptions, risks, and unresolved questions. For this lesson, concentrate on the framing sections rather than the proposed technical solution.

A strong brief is written in clear, complete statements. Avoid vague phrases such as “the system should be scalable” or “ensure a good user experience.” Instead, link each statement to a concrete driver already discovered:

• payment correctness and recovery;
• checkout responsiveness at campaign peaks;
• customer-specific order-status access;
• support diagnosis of uncertain orders;
• compatibility with future sales channels.

Also avoid writing implementation decisions as though they were facts. “The Checkout Service publishes Kafka events” does not belong in this version of the brief. It may become a design option later, after workload, consistency, failure, and operational needs have been examined.

---

A practical structure that fits on one page

Use this structure for version $0.1$. It should usually fit in roughly 400–600 words, excluding links to diagrams and supporting documents.

# [Initiative name] — Architecture Brief v0.1
Owner: [name] | Date: [date] | Status: Draft for discovery

## Context and scope
[Two or three sentences: the business problem, system boundary, and link
to the context diagram / driver register.]

## Goals
- [Outcome 1, preferably measurable or linked to a quality scenario.]
- [Outcome 2.]
- [Outcome 3.]

## Exclusions
- [Deliberately excluded work or responsibility.]
- [Deliberately excluded work or responsibility.]

## Assumptions to validate
- [Provisional planning assumption; how it will be validated.]
- [Provisional planning assumption; how it will be validated.]

## Open questions and next actions
| Question | Why it matters | Owner | Needed by |
|---|---|---|---|
| ... | ... | ... | ... |

The context and scope paragraph should link to your system-context diagram rather than duplicate it. The diagram is the visual map; the brief explains why the initiative exists and what agreement is needed next.

Use version numbers even for early documents. A brief labelled v0.1 — Draft for discovery communicates honest uncertainty. When a question is resolved, update the brief, retain a short change note if needed, and create an ADR only if the resolution is architecturally significant.

---

Worked example: Campaign Checkout System

The following is a credible first draft based on the work completed so far. It intentionally leaves key questions unresolved rather than pretending to know the answers.

Campaign Checkout System — Architecture Brief v0.1
Owner: Architecture lead | Status: Draft for discovery

Context and scope. Campaign customers need to submit checkout requests, receive a clear order outcome, and view the status of their own orders. The Campaign Checkout System coordinates payment processing with an external Payment Provider and supports integration by existing and future sales channels. See the system-context diagram and architecture-driver register for the system boundary and prioritized quality scenarios.

Goals.

• Provide a durable, unambiguous order outcome for each accepted checkout request, including recovery of payment outcomes that become uncertain because a response is delayed or lost.
• Meet the agreed peak checkout responsiveness and availability scenarios from the driver register.
• Ensure customers can access only their own order status.
• Enable authorized support agents to investigate uncertain orders using relevant business and payment-status information.
• Provide a stable integration boundary that can support additional sales channels without requiring a redesign of checkout capability.

Exclusions.

• Operating or replacing the external Payment Provider is outside this initiative.
• Redesigning independently owned sales-channel user interfaces is outside this initiative.
• Email and SMS notification capability is excluded unless product discovery confirms it as part of the customer journey.
• Internal service decomposition, hosting platform, and deployment topology are not decided by this framing brief.

Assumptions to validate.

• Sales channels remain external systems with their own ownership and release cadence. Validate with channel owners.
• Support agents can receive authorized access to order-investigation information without direct access to production data stores. Validate with support and security owners.

Open questions and next actions.

Question	Why it matters	Owner	Needed by
Does the Payment Provider support idempotency keys and payment-status reconciliation?	Determines whether uncertain payment outcomes can be safely recovered.	Payment integration lead	Before solution review
Which system authenticates customers and supplies the identity used for order-status authorization?	Determines the trust boundary and authorization design.	Product and identity owners	Before API design
What peak request rate, latency target, and availability target apply to campaign checkout?	Determines capacity and resilience decisions.	Product and operations leads	Before capacity design
Do sales channels need synchronous status responses, asynchronous notifications, or both?	Determines the integration contract and customer experience.	Channel owners	Before API and event design

Notice what this brief does not do. It does not choose microservices, databases, authentication protocols, or messaging patterns. Those choices would be premature because the questions that justify them are still open.

---

Drafting and review pass

Create your own version $0.1$ using the template and the campaign case. Keep the first draft short; the objective is a useful discussion tool, not polished prose.

Before sharing it, review it with this checklist:

• Every goal states an outcome, not a technology choice.
• Each exclusion is intentional and unambiguous.
• Every assumption could be proved wrong and has an identifiable validation path.
• Every open question names the decision or impact it affects.
• There is no invented performance target, stakeholder agreement, or external-system capability.
• The brief is consistent with the system-context diagram: the Payment Provider and sales channels are external, while customer order-status capability is in scope.
• A reader can identify what needs stakeholder input next.

If an open question has no owner, it is likely not ready for resolution. If an assumption has no validation plan, it is probably an unexamined risk. Both are signals to arrange focused discovery rather than to begin implementation.

---

Key takeaways

A one-page architecture brief frames an initiative before detailed solution design. Its essential elements are:

• Goals: prioritized outcomes and quality expectations.
• Exclusions: deliberate boundaries that prevent scope creep.
• Assumptions: temporary planning premises that must be validated.
• Open questions: consequential unknowns with owners and next actions.

For the Campaign Checkout System, the brief makes payment recovery, customer-specific access, support diagnosis, peak responsiveness, and sales-channel extensibility visible without prematurely selecting an implementation.

Next, you will begin the distributed-systems reasoning module by turning workload assumptions into estimates for latency, throughput, concurrency, storage, and bandwidth. The open capacity questions recorded here will become inputs to that work.