Plan an architecture review around a real decision
Start with the decision your team needs to make. Build a short planning brief, see what a useful review can produce and choose an appropriate conversation with MGCA.
Free to explore. Worksheet inputs stay in this browser tab; no account or paid API is required.

Three ways to frame the work
| Starting point | Bring | Useful outputs to agree |
|---|---|---|
| Architecture review | Decision question, current design, important journeys and known constraints. | Decision record, option trade-offs, risk priorities and an owned action list. |
| Azure migration readiness | Application inventory, dependencies, data ownership and recovery requirements. | Readiness findings, migration boundaries, evidence gaps and rehearsal priorities. |
| Enterprise AI readiness | A bounded task, data sources, permissions and evaluation expectations. | Feasibility questions, evaluation plan, release controls and next-step options. |
No fixed duration, fee or delivery result is implied by this planning tool. Scope, access, responsibilities and commercial terms require agreement.
Build your review planning brief
This creates a local draft for your own use. It does not send an enquiry or reserve an engagement.
What a review can leave behind
- 01 · FrameA named decision, boundaries and acceptance questions.
- 02 · TraceA journey through dependencies, data and ownership.
- 03 · ChallengeFailure, permission, recovery and operating evidence.
- 04 · DecideOptions, unresolved risks and accountable actions.
Experience and evidence
The worked deliverable above is fictional. For the experience already published by MGCA, see the experience page and clients and organisations page. A proposed project should connect the relevant experience to your actual constraints; this tool does not invent a case study or a client result.
Before a first conversation, identify one decision owner, one important system journey and the evidence that would change the decision. It is more useful to bring an uncertainty openly than to present a polished diagram that hides it.
Take the next step with context
Keep the question, assumptions and evidence together. These tools help organise a review; an exported record does not approve a design or certify a system.
