Architecture Review: How to Determine Whether a System Is Built on a Sound Foundation#

What Architecture Actually Means#

Architecture is often reduced to diagrams of servers and databases.

That is only part of it.

Software architecture describes the important structural decisions that determine how a system behaves and evolves.

It can include:

• application boundaries;
• data ownership;
• APIs;
• authentication;
• authorization;
• infrastructure;
• storage;
• communication;
• deployment;
• external dependencies;
• failure handling;
• security boundaries;
• operational responsibilities.

Architecture is therefore less about drawing boxes and more about making consequential technical decisions explicit.

Why Architecture Reviews Matter#

Many technology problems become expensive because architectural decisions were made implicitly.

A project may start with:

"Let's build a quick version."

That can be completely reasonable.

The problem appears when the quick solution becomes critical infrastructure without anyone revisiting the assumptions behind it.

Architecture review creates a deliberate point to ask:

• Does the current architecture still match the requirements?
• Which assumptions have changed?
• Where are the main failure points?
• Which components are becoming bottlenecks?
• Which dependencies are becoming difficult to replace?
• Is complexity justified?
• Can the system evolve without a major rewrite?

Architecture Should Follow Requirements#

There is no universally best architecture.

A system can be:

• a monolith;
• modular monolith;
• microservices;
• event-driven;
• serverless;
• distributed;
• hybrid;
• or some combination.

The correct choice depends on the problem.

The Major Areas of an Architecture Review#

System Boundaries#

First identify what belongs to the system and what does not.

For example:

Users
  ↓
Client Application
  ↓
API Layer
  ↓
Application Services
  ↓
Database

External Providers
  ├── Authentication
  ├── Payments
  ├── Email
  └── AI

The important questions are:

• Who owns each component?
• Which components can fail independently?
• Where does data cross boundaries?
• Which boundaries are security boundaries?
• Which dependencies are essential?

Data Architecture#

Data is often one of the longest-lived parts of a system.

Review:

• data ownership;
• schemas;
• relationships;
• storage;
• retention;
• backup;
• migration;
• access;
• synchronization;
• consistency requirements.

A good architecture should make it reasonably clear:

Where does important data live, who controls it, and what happens when the system changes?

API and Integration Architecture#

APIs are contracts between systems.

Review:

• authentication;
• authorization;
• versioning;
• error handling;
• rate limits;
• retries;
• timeouts;
• idempotency;
• observability;
• backward compatibility.

For external integrations, consider:

What happens when the provider is slow, unavailable, changes its API, or returns unexpected data?

Authentication and Authorization#

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

They should not be treated as the same problem.

Architecture review can examine:

• identity providers;
• session handling;
• roles;
• permissions;
• service accounts;
• privileged operations;
• administrative access;
• tenant boundaries.

A system may have strong authentication while still having weak authorization.

Failure Architecture#

Every dependency eventually fails.

The useful question is not:

"Can we prevent all failures?"

It is:

"What happens when an expected dependency fails?"

Consider:

• database unavailable;
• API timeout;
• payment provider failure;
• AI provider outage;
• network interruption;
• corrupted data;
• expired credentials;
• deployment failure.

Possible architectural responses include:

• retry;
• timeout;
• queue;
• fallback;
• graceful degradation;
• cached response;
• manual intervention;
• controlled failure.

Not every system needs every mechanism.

Security Architecture#

Security should be part of architecture rather than something added at the end.

Review:

• trust boundaries;
• authentication;
• authorization;
• secrets;
• encryption;
• network exposure;
• data isolation;
• privileged operations;
• logging;
• administrative interfaces.

A useful question is:

If one component is compromised, what can it reach?

That question often reveals architectural weaknesses.

Observability#

A system cannot be reliably operated if nobody can understand what it is doing.

Depending on the system, architecture may need:

• logs;
• metrics;
• traces;
• health checks;
• alerts;
• audit records.

Observability should be designed around operational questions.

For example:

Why did this request fail?

Which dependency is causing latency?

Did the payment actually complete?

Which deployment introduced the regression?

Architecture and Cost#

Architecture has financial consequences.

A design can affect:

• infrastructure cost;
• third-party API costs;
• database costs;
• bandwidth;
• storage;
• operational staffing;
• development time.

A review should therefore ask:

What will this architecture cost to build, operate, and change?

A technically elegant system that is economically unsuitable is not a successful architecture.

Architecture and Team Size#

Architecture should also match the organization operating it.

A system requiring twelve specialized operational teams may be inappropriate for a company with three engineers.

Likewise, a tightly coupled monolith may become difficult to manage when many independent teams need to work on it simultaneously.

Architecture and organizational structure influence each other.

Technical Debt and Architectural Debt#

Architectural debt appears when a structural decision creates future constraints or costs.

Examples:

• tightly coupled modules;
• unclear ownership;
• database shared across unrelated services;
• undocumented dependencies;
• provider-specific assumptions;
• manual deployment;
• authentication embedded throughout the application.

Not every shortcut is bad.

The important question is:

What future limitation does this decision create, and is that limitation acceptable?

Common Architecture Review Mistakes#

"Microservices are better."#

Not necessarily.

They can introduce network boundaries, operational complexity, distributed failure modes, and additional deployment overhead.

"Serverless is cheaper."#

Sometimes.

Costs depend on workload, provider, architecture, data transfer, and operational requirements.

"We need Kubernetes."#

Maybe not.

Infrastructure should follow requirements rather than fashion.

"The diagram looks clean."#

A clean diagram does not prove that the implementation behaves correctly.

"The application works."#

Functional success does not prove architectural suitability for future requirements.

A Practical Architecture Review Process#

1. Understand the Business Requirements#

Document:

• users;
• workflows;
• critical operations;
• data;
• availability expectations;
• growth assumptions;
• security requirements;
• operational constraints.

2. Map the Current Architecture#

Document:

• components;
• dependencies;
• data flows;
• external providers;
• infrastructure;
• trust boundaries.

3. Identify Architectural Decisions#

For important decisions, ask:

• Why was this chosen?
• What alternatives existed?
• What assumptions were made?
• Are those assumptions still valid?

4. Identify Risks#

Focus on risks that can materially affect:

• reliability;
• security;
• scalability;
• maintainability;
• cost;
• ownership.

5. Recommend Proportionate Changes#

Not every issue requires immediate redesign.

Classify recommendations by urgency and consequence.

A Useful Architecture Review Output#

The Goal of Architecture Review#

An architecture review should not produce a perfect diagram.

It should produce better understanding.

After the review, stakeholders should be able to explain:

• how the system works;
• why its important decisions exist;
• where its boundaries are;
• what happens when dependencies fail;
• what risks are present;
• what changes may be required;
• and what should not be changed unnecessarily.

Actionable Checklist#

• Document the actual business requirements.
• Map system boundaries.
• Identify major components and owners.
• Map important data flows.
• Review authentication and authorization boundaries.
• Identify critical dependencies.
• Examine failure and recovery behavior.
• Review security boundaries.
• Examine observability.
• Consider operational and infrastructure cost.
• Evaluate architecture against expected growth.
• Identify architectural debt.
• Record important assumptions.
• Separate necessary changes from optional improvements.
• Document review limitations.