Commerce Architecture Review Checklist

Summary

A structured checklist for auditing existing commerce architectures before replatforming, optimization, or integration work. Use this to surface hidden risks, undocumented dependencies, and decision points that derail projects when discovered late.

The Problems Live in What Isn't Documented

Most commerce architecture reviews focus on what's documented. That's the wrong target.

Teams inherit systems with years of accumulated decisions, some intentional, some accidental, most undocumented. Integration points multiply. Data flows get patched. Business logic migrates to unexpected places.

A surface-level audit catches the obvious. This checklist targets the gaps that cause scope explosions mid-project: the custom middleware nobody owns, the pricing logic buried in a third-party connector, the nightly batch job that holds everything together.

How to Use This Checklist

Work through each section with the people who actually operate the system, not just the architects who designed it. Document answers with evidence, not assumptions. Flag anything that gets a vague response or conflicting answers from different stakeholders.

Vague answers are findings.

Platform Core

Who Made the Decisions, and Are They Still Here?

Who made the last three significant architectural decisions, and are they still at the organization?
When was the platform last upgraded, and what was skipped or deferred?
Which features are running on deprecated or unsupported versions?
What customizations exist that would break on a standard upgrade path?

Where Business Logic Actually Lives

What percentage of business logic lives in platform configuration vs. custom code?
Which customizations duplicate functionality that now exists natively?
Are there customizations that override core platform behavior in ways that aren't immediately visible?
What's the process for determining whether a new requirement gets configured or coded?

When Performance Degrades

At what transaction volume does the current architecture degrade?
Has this been tested, or is it theoretical?
Which components become bottlenecks first under load?
What's the recovery process when performance thresholds are exceeded?

Integration Points

What's Actually Connected

How many active integrations exist, including those not in official documentation?
Which integrations are point-to-point vs. routed through middleware?
What's the source of truth for the current integration inventory?
When was the last time someone validated that inventory against reality?

How Data Moves and When

For each critical integration: is data pushed, pulled, or both?
What triggers each data exchange, events, schedules, or manual processes?
Which integrations are synchronous and blocking vs. asynchronous?
What's the actual latency of "real-time" integrations under normal and peak conditions?

What Happens When Integrations Fail

What happens to an order when the ERP integration fails mid-transaction?
Which integrations have retry logic, and which fail silently?
How are failed transactions surfaced to operations teams?
What's the manual remediation process, and how often is it used?

Credentials and Access Scope

Where are integration credentials stored, and who has access?
When were credentials last rotated?
Which integrations use deprecated authentication methods?
Are API keys scoped appropriately, or do they have broader access than needed?

Data Flows

Customer Data Ownership

Where does customer identity live as the system of record?
How many places store customer data, and how are they synchronized?
What happens when customer data conflicts between systems?
Which system wins, and is that documented?

Product Data Path to Storefront

Where is product information mastered, and what's the publication flow to commerce?
How long does a product data change take to appear on the storefront?
What enrichment happens between the master and the commerce platform?
Who owns the enrichment logic, and where does it run?

Where Pricing Gets Calculated

Where is pricing calculated, in the commerce platform, ERP, or somewhere else?
Can pricing differ between product display and cart, and under what conditions?
What's the source of truth for active promotions?
How are promotion conflicts resolved, and is that logic documented?

Order Lifecycle Across Systems

What's the complete path of an order from placement to fulfillment?
At which points can an order be modified, and by whom?
Where does order data get transformed, and what's lost in translation?
How are order amendments and cancellations propagated across systems?

Hidden Dependencies

The Batch Jobs Holding Everything Together

What batch processes run nightly, and what breaks if they don't complete?
Which jobs have grown beyond their original scope?
What's the monitoring and alerting coverage for scheduled jobs?
When a job fails at 3am, who finds out and how?

Manual Processes That Became Permanent

What operations require manual intervention that should be automated?
Which "temporary" manual processes have become permanent?
What tribal knowledge is required to run day-to-day operations?
If the operations lead is unavailable, what stops working?

Third-Party Service Dependencies

Which third-party services would cause immediate customer impact if unavailable?
What's the contractual SLA for each critical external service?
What's the actual historical uptime, and does it match the SLA?
Are there fallback options, and have they been tested?

Risk Indicators

Code Nobody Wants to Touch

Which areas of the codebase are avoided because they're fragile or poorly understood?
What's the test coverage on critical business logic?
Are there components that only one person can safely modify?
What's been on the "fix later" list for more than a year?

What Breaks and How Often

What breaks most often, and what's the mean time to resolution?
Which incidents required changes to prevent recurrence, and were those changes made?
What's the blast radius of a single component failure?
Are there single points of failure that aren't documented as such?

Security and Compliance Gaps

When was the last security audit, and what findings remain open?
Is PCI scope clearly defined and minimized?
How is PII handled across all integration points?
Are data retention policies implemented, or just documented?

Documentation and Knowledge

Does Documentation Match Reality?

Does current architecture documentation reflect the actual system?
When was documentation last validated against implementation?
Who is responsible for keeping documentation current?
What's documented only in someone's head?

Can Someone Else Run This?

Do runbooks exist for common failure scenarios?
Have runbooks been tested by someone other than the author?
What's the onboarding time for a new engineer to handle on-call responsibilities?
Which procedures exist only as institutional knowledge?

Using the Findings

A completed checklist is a diagnostic tool, not a deliverable.

Group findings into three categories:

Blockers: Issues that will derail a project if not addressed upfront
Risks: Problems that need mitigation plans and contingency time
Debt: Items to address but not project-critical

Map blockers and risks to specific project phases. Build contingency into timelines based on the number and severity of vague answers you received.

Anything that got inconsistent answers from different stakeholders needs reconciliation before planning proceeds.

How DigitalStack Structures Architecture Reviews

DigitalStack treats architecture reviews as traceable assessments. Findings connect directly to stakeholder input, requirements, and downstream decisions, when a risk surfaces, it links to the objective it threatens and the architecture decision it affects.

Survey orchestration captures input from operations, development, and business stakeholders in a structured format. You're not relying on a single interview or whoever happened to be in the room.

Outputs update as findings evolve, so you're not maintaining a slide deck that's outdated by the time it's presented.

Next Step

Run your next architecture review in DigitalStack. Structure findings from day one so they connect to decisions, not just documentation.