MGCA · Practical tool · English

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.

Conceptual title illustration for MGCA
Conceptual title image. Any real observation data is identified separately below.

Three ways to frame the work

Example engagement boundaries — final scope is agreed with you
Starting pointBringUseful outputs to agree
Architecture reviewDecision question, current design, important journeys and known constraints.Decision record, option trade-offs, risk priorities and an owned action list.
Azure migration readinessApplication inventory, dependencies, data ownership and recovery requirements.Readiness findings, migration boundaries, evidence gaps and rehearsal priorities.
Enterprise AI readinessA 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.

Your planning brief will appear here.

What a review can leave behind

  1. 01 · FrameA named decision, boundaries and acceptance questions.
  2. 02 · TraceA journey through dependencies, data and ownership.
  3. 03 · ChallengeFailure, permission, recovery and operating evidence.
  4. 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.