Definition & decision artefacts
- Discovery brief
- Evaluation criteria
- Candidate architecture options
- Evidence plan
- Architecture decision record
- Baselined target HLD
- Delivery roadmap
Approach
A pragmatic, evidence-based approach
Enough structure to make sound decisions. Enough agility to create value early.
Complex transformations need a sound foundation, but they should not disappear into months of analysis before anything is learned. My preferred approach combines focused discovery, rapid prototyping of solution alternatives, candidate architecture design and targeted proof with iterative delivery, consolidated end-to-end assurance and a controlled transition into stable operations.
It is a preferred starting point, not a methodology imposed on the client. I adapt it to the organisation’s governance, culture, delivery model, project leadership and existing partner landscape.
This approach runs across all five expertise areas. Selected experience shows how it is applied in practice.
Informed by selected Microsoft Success by Design principles and refined through more than two decades of international Dynamics delivery. This is my independently evolved approach, not an official Microsoft methodology.
The differentiating idea
Evidence shapes the high-level design — not just validates it.
Early models and rapid prototypes make requirements and solution alternatives tangible before the direction is narrowed. Candidate architectures then make the boundaries, trade-offs and remaining assumptions explicit. Focused technical spikes or a multi-sprint decision PoC provide evidence before the target high-level design is baselined and production delivery begins.
Explore before narrowing. Prove before committing. Deliver within a direction that can withstand scrutiny.
Progressive commitment
Increase commitment as evidence and confidence increase.
The amount of validation should be proportionate to the long-term cost of getting the decision wrong. Low-cost discovery and prototypes narrow the options first. Investment increases only when the evidence justifies it.
Progressive commitment, not premature certainty.
The shape of it
Nine stages across four phases
The process is deliberately not linear. Prototypes can refine requirements and candidate designs; PoC findings can confirm, change or reject architectural assumptions. The goal is not to eliminate all uncertainty before delivery, but to resolve the uncertainties that could materially change the decision.
InitiationOnce per engagement
Project Definition & ValidationStructured and decision-led · iterative evidence loops
- 01 Initiate Create a shared frame before architecture work fragments across domains. OutputShared outcomes, sponsorship, scope and governance.
- 02 Discover & frame Build enough shared understanding to design responsibly while creating momentum quickly. OutputBusiness outcomes, context, constraints, stakeholders and decision criteria.
- 03 Explore & prototype alternatives Use models, mock-ups and lightweight prototypes to make requirements and alternative solution concepts tangible before narrowing the field. OutputEvidence into candidate architectures.
- 04 Shape candidate architectures & evidence plan Translate the leading alternatives into coherent high-level architectures. Make boundaries, trade-offs, assumptions and the evidence still required explicit. OutputCandidate direction — not yet a production baseline.
- 05 Prove critical assumptions & refine Run focused technical spikes or a multi-sprint decision PoC. Use the findings to confirm, change or reject assumptions and refine the candidate architecture. Output1–n evidence sprints; evidence back into architecture.
- 06 Decide, baseline & phase Compare the evidence against strategy, requirements, cost/TCO, risk, security, performance and operability. Select the direction, baseline the target HLD and shape a realistic production roadmap. OutputArchitecture & Investment Decision.
- 02–04Prototype findings refine requirements, evaluation criteria and candidate architectures.
- 04–05PoC findings confirm, change or reject architectural assumptions before commitment.
▸ Architecture & Investment Decision The preferred direction has been selected, the target HLD has a defensible baseline and production delivery can be phased responsibly. Detailed design is not frozen.
Project DeliveryIterative build · consolidated assurance
Transition & SupportControlled cutover · hypercare · operational learning
- 07 Deliver iteratively Refine detailed analysis, design and development within clear architectural guardrails while learning from working increments. OutputSpecialists retain domain ownership; architecture maintains coherence.
- 08 Consolidate, test & harden Prove that the increments work together as one secure, performant and operational solution — not only as locally successful components. OutputEnd-to-end, regression, performance, security, operational readiness and cutover.
- 09 Cut over, stabilise & transition to operations Move into production with explicit cutover and rollback controls. Stay through hypercare, establish operational ownership and escalation, activate monitoring, transfer knowledge, and convert early production learning into a prioritised improvement backlog. OutputCutover and rollback plan; go-live readiness decision; hypercare and escalation model; monitoring and operational ownership; knowledge-transfer pack; prioritised improvement backlog.
- 07–08Working increments and consolidated validation refine detailed design and delivery priorities.
Continuous throughout · stages 01–09
- Governance & stakeholder alignment
- Architecture decision records
- Risk, assumption & dependency management
- Architecture, security & quality assurance
These disciplines continue throughout the engagement rather than being completed in a single phase.
Typical evidence and decision artefacts
What the method actually produces
Exact outputs vary, but the pattern is consistent: each artefact should reduce uncertainty, enable a decision or create guardrails for delivery.
Evidence & validation artefacts
- Exploratory prototypes
- PoC hypotheses and success criteria
- Technical findings
- Fit/gap assessment
- Risk and assumption evidence
- Cost and TCO comparison
- Evidence-backed recommendation
Delivery & assurance artefacts
- Iteration plans and playbacks
- Detailed functional and technical designs
- Updated architecture decisions
- End-to-end test evidence
- Performance validation
- Security-hardening evidence
- Operational-readiness assessment
Transition & operations artefacts
- Cutover and rollback plan
- Go-live readiness decision
- Hypercare plan
- Ownership and escalation model
- Monitoring and observability setup
- Knowledge-transfer material
- Improvement backlog
Adaptable by design
A preferred starting point, not a fixed methodology
The structure adapts to the client’s governance and delivery context. Some decisions need only a short technical spike; others justify a multi-sprint PoC because the architecture will shape cost, agility, operability and vendor dependency for years.
Existing teams and partners retain ownership of their domains. My role is to maintain coherence, make trade-offs visible and ensure that important assumptions are treated as assumptions until evidence supports them.
- Client governance
- Project leadership
- Delivery model
- Existing implementation partners
- Risk and regulatory context
- Cost of being wrong
Next step
Need an evidence-based route through a difficult architecture decision?
Let’s discuss the outcomes, uncertainties and realistic options — without imposing a predetermined methodology or delivery model.