The diagram looks complete
Systems are connected by arrows, but the design does not explain who owns a state change, how failures recover or what happens to duplicate messages.
04 / Solutions & Technical Architecture
Resolve the hard system decisions before they become rework.
Independent architecture advice for connected commerce and enterprise systems. Clarify boundaries, integration contracts and failure handling before delivery assumptions become expensive.
Independent advice. A clear scope. Decisions your team can act on.
CommerceStoreCustomer service
Business domainsOrders · inventory · customersAssign an authoritative owner to each fact.
Integration contractsEvents · APIs · recovery rulesDefine what happens when a dependency fails.
Systems of recordERP · OMS · CRMKeep boundaries explicit and supportable.
Make failure paths part of the design.
Illustrative decision framework
Retail & DTC focusIndependent of platform vendorsAdvisory shaped around your decision
Will this design hold up when systems and teams disagree?
Architecture risk often sits between components: an unclear owner, an assumed response time or an integration that only describes the successful path.
Delivery teams are making different assumptions
Partners agree on the target solution while interpreting responsibilities, integration behaviour or non-functional requirements differently.
A change has unexpected consequences
A seemingly local release affects several systems. Dependencies and interfaces have grown without a shared view of the boundaries they cross.
Get close to the work.
Make the decision clearer.
We work with the people who own the outcome and the teams who will deliver it. Your constraints shape the recommendation.
- 01
Set the boundary
Agree the business outcome, systems in scope and decisions that must be resolved. Review existing designs and known production constraints.
- 02
Trace representative transactions
Follow key workflows through normal operation, timeouts, duplicates and partial failures. Test the design against the consequences that matter to the business.
- 03
Make the design actionable
Document ownership, interfaces and decisions. Review the outputs with delivery and operational leads so open questions have a clear next step.
A recommendation you can put to work.
Create architecture decisions that delivery teams can implement and operating teams can understand.
A system responsibility model
Define which system owns each capability and state transition. Identify overlaps, coupling and decisions that need an accountable business owner.
Critical integration contracts
Describe the required exchanges, timing, identity, retry behaviour and failure ownership for the interfaces that carry the most business risk.
Architecture decision records
Record the options considered, constraints, chosen approach and consequences. Give future teams the reasoning behind the design.
A delivery readiness review
Assess security, resilience, observability, migration and operational support assumptions. Prioritise unresolved risks and evidence needed before implementation.
Put it to the test
One order, several versions of its status
Illustrative scenario: commerce accepts an order, the OMS allocates stock and the ERP creates the financial record. A timeout occurs after the ERP accepts the request, leaving the calling system unsure whether to retry.
The questions worth answering
- How is the same business transaction recognised across retries?
- Which system is authoritative for each stage of order progress?
- How will support identify and reconcile a partial failure?
The design defines recovery behaviour and ownership before implementation, making the integration contract useful beyond the happy path.
Related case study
Read the case study Architecture in the context of a platform decision
See a related case study where the operating model and system boundaries matter as much as the platform selection.
A few practical questions.
Scope, ownership and the next step should be clear before an engagement begins.
Can you review another partner’s architecture?
Yes. A review can test assumptions and identify gaps while preserving useful work. Findings should give the delivery team specific decisions to resolve.
Do you build or operate the integrations?
JM Digital provides architecture advisory and review. Implementation, testing and production operations remain with your team or delivery partner, with responsibilities documented in the handoff.
How detailed will the outputs be?
The level of detail follows the decision. An executive option assessment needs different artifacts from a critical integration review; scope and expected outputs are agreed upfront.
Let's talkBring the decision
Bring the decision
you need to make.
Tell us what is changing, what is at stake and where you need an independent perspective. We will discuss the right starting point and agree the scope before work begins.
Still framing the problem?
The free Retail Architecture Risk Score can help surface where systems, ownership or delivery capacity need a closer look.
Start with the Risk ScoreThe work rarely stops at one boundary.
Where we work
Independent advice for your regional team.
Partners and internal teams need the same understanding of system ownership and integration behaviour. We make those decisions explicit before delivery assumptions become rework.
Remote collaboration, with workshop and meeting arrangements agreed during scoping.