What does architecture decide before feature work starts?
Architecture should come before features because a product needs clear rules for data, ownership, integrations, permissions, and failure before new screens can remain dependable. A feature list describes what users may see; architecture establishes whether those promises can still be kept when usage grows, requirements change, or an external system fails.
What this prevents
Without those rules, each feature quietly invents its own assumptions. Customer data may have several owners, permissions may be checked differently across screens, and integrations may fail without a recovery path. The cost appears later as rework, inconsistent behaviour, and slower releases.
A practical example
A booking screen looks like one feature, but it depends on availability ownership, time zones, payment state, cancellations, notifications, and staff exceptions. Deciding those relationships first makes the interface easier to build and the operation easier to trust.
How do you map a business flow before building software?
Map the business flow by tracing one real piece of work from its trigger to its final outcome. Identify every participant, decision, handoff, source of information, exception, and required record. The result should show how the operation actually behaves, including manual work and failure paths, rather than only describing the ideal customer journey.
Evidence to collect
Use current forms, spreadsheets, support messages, reports, approval rules, and conversations with the people doing the work. These reveal exceptions that a high-level feature list usually misses, such as refunds, duplicate requests, delayed provider events, or decisions that require a human.
Turn the flow into a system model
Mark which system owns each important fact, which events change state, and where people need visibility or control. This creates a shared model for product scope, data design, integrations, administration tools, and the first useful release.
Which architectural constraints should a team choose?
Choose the smallest set of architectural constraints that keeps the product understandable and safe. Define clear data ownership, permission boundaries, integration contracts, deployment expectations, and the few system boundaries that genuinely reduce coupling. A good constraint narrows dangerous choices while leaving ordinary product changes straightforward.
The important caveat
More boundaries are not automatically better. Splitting an early product into many services can create deployment, monitoring, and data-consistency work before the business needs it. A modular application with explicit internal boundaries is often the calmer starting point.
How to make the decision
Tie every major constraint to a known risk or operating need. If a choice cannot be explained through security, scale, team ownership, reliability, compliance, or expected change, it may be unnecessary complexity rather than useful architecture.
What should a team ask before development starts?
Before development starts, ask which information must never be wrong, who can change it, what happens when dependencies fail, which decisions need an audit trail, and what must remain true as usage grows. Also identify what can safely change later. These answers expose the decisions that deserve architecture work before feature delivery begins.
A useful readiness check
The team should be able to explain the primary workflow, system of record, user and organisation boundaries, critical integrations, failure handling, release path, and first measurable outcome. The explanation can be concise, but the ownership should not be vague.
When to begin building
Architecture does not require predicting the entire future. Begin once the costly and hard-to-reverse decisions are understood well enough to support a useful first slice. Continue testing the model against working software and revise decisions when real evidence changes the picture.