Turn architecture uncertainty into decisions and a staged roadmap.
For commerce leaders planning modernisation, integration strategy or a target architecture while the current system must keep operating.
System contextActors · systems · data
Decision recordOptions · trade-offs · choice
RoadmapDependency · risk · evidence
Architecture consulting should end in decisions your delivery team can use.
- Typical first step
- Frame the blocked investment or modernisation decision.
- Inputs we need
- Business goals, system access, diagrams, incidents, roadmap, constraints and stakeholder context.
- Outputs
- Current-state map, decision records, target boundaries and phased roadmap.
- Working format
- Assessment, target architecture or ongoing decision support.
Select the format that matches the decision.
A broad review is not always the right first purchase. Each format has a distinct output.
Architecture assessment
For unclear risks, dependencies and ownership.
Outputs: current-state map, risk register and priority questions.Target architecture
For a defined business change or platform direction.
Outputs: system context, boundaries, decisions and transition states.Modernisation roadmap
For sequencing change around a live system.
Outputs: phases, dependencies, risks and evidence gates.Integration strategy
For ownership and data-flow decisions across systems.
Outputs: source-of-truth map, contracts and operating boundaries.Move from diagrams as documentation to decisions as working assets.
- Diagrams show components but not ownership or failure boundaries.
- Technology choices are separated from business constraints.
- The roadmap lists projects without dependencies or evidence gates.
- Modernisation assumes a big-bang target state.
- System context links actors, data and responsibilities.
- ADRs record options, trade-offs and decision triggers.
- Roadmap phases expose dependencies, risks and validation needs.
- Transition states keep the live business operable.
Example Architecture Decision Record.
Illustrative structure only — not a client case or a performance claim.
01ContextDecision pressure, constraints and affected capabilities
02OptionsRealistic alternatives and operating consequences
03DecisionChosen direction, owner and rationale
04Follow-upRisks, evidence gate and revisit trigger
Architecture work from evidence to sequence.
Current-state assessment
System, data, dependency and risk map.
Boundary: Not a full code audit unless scoped.Target architecture
Capabilities, boundaries and transition states.
Boundary: Implementation is a separate workstream.Decision records
Options, trade-offs, choice and revisit trigger.
Boundary: Executive approval remains client-owned.Modernisation strategy
Incremental replacement and coexistence path.
Boundary: No rewrite recommendation without evidence.Integration strategy
Ownership, contracts and failure boundaries.
Boundary: Connector implementation is separate.Delivery roadmap
Phases, dependencies, risks and evidence gates.
Boundary: Dates require team capacity and scope evidence.Frame → Map → Decide → Sequence
Frame
Business decision, constraints and stakeholders.
Define criteria and questions that must be answered.
Engagement frame and evidence request.
Map
Systems, data, incidents and team context.
Model dependencies, ownership and failure boundaries.
Current-state context and risk map.
Decide
Realistic options and decision criteria.
Compare trade-offs and document choices.
ADRs and target boundaries.
Sequence
Decisions, dependencies and delivery capacity.
Define transition states and evidence gates.
Phased roadmap and open risks.
Outputs
Included
- 01System context diagram
- 02Capability and ownership map
- 03Architecture Decision Records
- 04Risk and dependency register
- 05Target-state and transition views
- 06Phased roadmap with evidence gates
Team shape
An architect working with technical owners and the relevant domain specialists; the decision to be made determines the team.
Code and IP
The client owns the project-specific code and agreed deliverables after payment; third-party licenses and pre-existing tools keep their original terms.
Handoff and support
Handoff includes agreed repositories, documentation and knowledge transfer. Ongoing support is a separate scope unless included in the engagement.
Not included by default
Full implementation, vendor procurement, legal compliance sign-off, fixed delivery dates and guaranteed business outcomes unless separately scoped and evidenced.
Price factors
System breadth, stakeholder count, documentation quality, access constraints, decision count, required depth and roadmap detail.
Start with the decision the team cannot close.
Is this only for greenfield projects?
No. It is often most useful when a live system must evolve without a full rewrite.
Do you automatically recommend microservices?
No. We recommend the simplest boundaries justified by ownership, change and scaling needs.
Will you implement the roadmap?
Implementation can be scoped separately; the consulting engagement itself ends with agreed artifacts and handoff.
What is needed to start?
The blocked decision, key stakeholders and available system evidence are enough for an initial review.
Start with the decision the team cannot close.
After contact we clarify constraints, stakeholders and available evidence, then propose the appropriate engagement format.
Discuss an architecture decision →