How to describe a system before the architecture exists

Architecture does not begin with a perfect requirements document. It begins with enough context to make the first set of tradeoffs visible. A useful system description gives the architect a boundary, a few important flows, the constraints that matter and the unknowns that still need a decision.

This is the difference between writing a feature list and creating architecture input. A feature list says what the product should do. Architecture input explains the operating conditions the system must survive: who uses it, what it connects to, what can fail, what must be fast, what must be secure and what is still undecided.

Name the boundary first

Before choosing services, describe what is inside the system and what is outside it. Name the users, external systems, data sources, integrations and responsibilities. A boundary turns a vague idea into something that can be designed, priced and staffed.

Good boundary language is concrete. Instead of saying "build a customer portal," describe whether the portal owns user accounts, reads from an existing CRM, writes payments to a provider, imports files, sends notifications or exposes an API to another system. Every integration changes the architecture.

Trace the critical flow

Most systems have at least one path that matters more than the others: a payment, booking, approval, upload, report, notification or internal handoff. Follow that path from the first user action to the durable outcome. That usually reveals the API, data store, background work, error handling and operational concerns the first design must include.

When the critical flow is visible, the architecture can distinguish between work that must happen immediately and work that can happen later. That distinction affects queues, retries and failure paths that should be designed early, along with database transactions, monitoring, alerts and the way the delivery plan is staffed.

Separate features from qualities

Features describe what the system does. Quality requirements describe how it must behave while doing it. Cloud architecture depends heavily on those qualities, so they should be explicit rather than implied.

• Availability: what needs to keep working when a dependency fails.
• Latency: which actions must feel immediate and which can happen later.
• Security: who can access what, and how sensitive data is handled.
• Scale: which parts grow with users, traffic or data volume.
• Operations: who will monitor, deploy and support the system after launch.

A strong architecture input does not answer every question. It makes the important questions impossible to miss.

Give constraints before preferences

Technology preferences are useful, but constraints are more important. A team may prefer Azure because of identity integration, AWS because of existing infrastructure, or GCP because of analytics tooling. Those preferences matter, but the architecture should first understand the constraints: data residency, compliance scope, team skills, target timeline, budget sensitivity and operational ownership. That is also the starting point for a useful AWS vs Azure vs GCP comparison.

A clear constraint can prevent a poor design choice early. A system with strict audit requirements needs different logging, identity and access patterns than a lightweight internal tool. A system operated by a small team may benefit from managed services even when a lower-level service appears cheaper on paper.

Make unknowns visible

Unknowns are not a problem if they are named early. Region, usage level, compliance scope, integration details and team capability can all change the design. Calling them out gives the first architecture room to be reviewed instead of pretending it is final.

A practical architecture input checklist

• Who are the users, systems and teams that interact with the solution?
• Which workflow is most critical to the business?
• Which data is sensitive, regulated or difficult to recreate?
• Which actions need to be synchronous, and which can be asynchronous?
• Which provider, region or platform constraints are already decided?
• Which assumptions should be priced or reviewed before implementation starts?

This level of input is enough to produce a useful first architecture. It does not remove review. It gives the review something concrete to improve, and it gives AI-assisted architecture tools the context they need for grounded output instead of fluent guesses.