> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.5-phase-4-plan-design-the-target-architecture.md). # 4.5 Phase 4, Plan — design the target architecture Between the gaps and the roadmap sits the deliverable the whole EA is for — the target architecture: a future-state picture of the capabilities, the data owners. {% embed url="" %} EA lifecycle Phase 4: design the target architecture before you build the roadmap (\~4 min) {% endembed %} **Watch first (\~4 min).** Then come back for the play. The video's recap slide carries an on-screen practice box — it is not narrated — and this page is where that box points. > **Single message.** Between the gaps and the roadmap sits the deliverable the whole EA is for — the target architecture: a future-state picture of the capabilities, the data owners, the shared platforms and the integration map your government should have. Design it by applying your principles to the gaps, and the roadmap finally has somewhere to go. ## The concept Between where Progressa is today and how it gets somewhere sits the deliverable the whole architecture exists to produce: the target architecture, the picture of the future state you are building toward. Skip it, and you sequence a roadmap to a destination nobody drew. The target architecture is the future-state picture, drawn in the same four layers you used for the current state — but designed, not observed. The target capability map: each capability owned by exactly one body, the duplicates resolved. The target data domains: one authoritative owner for the learner, the person, the result — the three lists collapsed to one. The target shared platforms: the identity platform and the data-exchange backbone every sector will consume. And the target technology standards. It is the current-state picture's mirror — what the sector should look like once the gaps are closed. You do not invent the target from imagination. You design it by applying the principles you adopted in Adapt to the gaps you found in Assess. Once-only says the three learner lists become one — so the target has a single authoritative Learner Registry. Reuse-before-build says education consumes the national identity rather than minting its own — so the target shows the Examination Authority consuming the Identity Authority. One-owner-per-domain resolves who owns what. The principles are not decoration; they are the design rules. Apply them to the current state, and the target architecture almost draws itself. The target adds one artefact the current state never had: the integration map. It names which bodies need to exchange which data, over what mechanism, in what priority order. On Progressa: the Examination Authority reads the learner from the Learner Registry and the identity from the Identity Authority, both over the Digital Government Authority's data-exchange backbone, replacing the paper re-entry. The integration map is the target's connective tissue — the picture of a government whose systems finally talk to each other. Here you draw it as a first cut; designing those exchanges in full detail is the interoperability work that the next knowledge product covers. One discipline keeps the target useful. It must be reachable, not a fantasy. Every element of the target should trace back to a gap it closes and forward to a sourcing decision — build, buy or share — that obtains it. A target capability with no way to build or acquire it is a wish, not an architecture. So the target architecture and the sourcing decisions are designed together: the target says what the future state is; the sourcing says how each piece is obtained. Signed off together, they are the agreed destination the roadmap then sequences. ## Do this on your own sector — Design a first-cut target architecture from your gaps {% hint style="success" %} **✍️ Drafting play · produces A25 Target architecture** **Bring:** the ranked gaps, the adopted principles, and the sourcing postures. From **A24, A11, BB status register** (see [Your country workbook](/experience-digital-transformation/gea/your-country-workbook.md)). **Get:** a first-cut target architecture in four layers, an integration map, and a trace from each element to a gap and a sourcing decision. As text in the chat, not a file or a chart. **Time:** \~25 min · **Assistant:** any; the plays are tool-neutral. **With the kit:** no skill in this release, so the prompt runs bare in any assistant. **Watch for:** The target is a hypothesis produced by applying principles to your gaps — validate each owner assignment and each integration with the bodies that will live with them before sign-off. {% endhint %} ✍️ **Drafting play.** You give a few facts; the play produces a first draft of a document you will edit. **What it does.** An architect who has run Assess needs to turn the ranked gaps and adopted principles into a designed future state — the target architecture — rather than jumping straight to a roadmap toward an undrawn destination. {% tabs %} {% tab title="Prompt" %} Copy the prompt, replace the bracketed parts with your own context, and run it in the AI assistant of your choice. Never paste personal data or unpublished documents — see [How to use the plays](/experience-digital-transformation/gea/start-here/how-to-use-the-plays.md). ``` Below are my ranked gaps for [country X]'s [sector] sector, my adopted architecture principles, and my sourcing postures [paste the gap analysis, the principle list, and the build/buy/share matrix if you have it]. Design a first-cut target architecture by applying the principles to the gaps. Produce: (1) the target capability map — each capability with exactly one owning body, duplicates resolved; (2) the target data domains — one authoritative owner each, with the duplicate registries collapsed; (3) the target shared platforms every body will consume (identity, payments, data exchange); (4) the target technology standards; (5) a first-cut integration map — which bodies exchange which data domains, over what mechanism, in what priority. For every target element, note the gap it closes and the sourcing decision (build / buy / share) that obtains it; flag any element with no path to acquire it. Output: the four target layers, the integration map, and the gap-and-sourcing trace. ``` [Open in Claude](https://claude.ai/new?q=Below%20are%20my%20ranked%20gaps%20for%20%5Bcountry%20X%5D%27s%20%5Bsector%5D%20sector%2C%20my%20adopted%20architecture%20principles%2C%20and%20my%20sourcing%20postures%20%5Bpaste%20the%20gap%20analysis%2C%20the%20principle%20list%2C%20and%20the%20build%2Fbuy%2Fshare%20matrix%20if%20you%20have%20it%5D.%20Design%20a%20first-cut%20target%20architecture%20by%20applying%20the%20principles%20to%20the%20gaps.%20Produce%3A%20%281%29%20the%20target%20capability%20map%20%E2%80%94%20each%20capability%20with%20exactly%20one%20owning%20body%2C%20duplicates%20resolved%3B%20%282%29%20the%20target%20data%20domains%20%E2%80%94%20one%20authoritative%20owner%20each%2C%20with%20the%20duplicate%20registries%20collapsed%3B%20%283%29%20the%20target%20shared%20platforms%20every%20body%20will%20consume%20%28identity%2C%20payments%2C%20data%20exchange%29%3B%20%284%29%20the%20target%20technology%20standards%3B%20%285%29%20a%20first-cut%20integration%20map%20%E2%80%94%20which%20bodies%20exchange%20which%20data%20domains%2C%20over%20what%20mechanism%2C%20in%20what%20priority.%20For%20every%20target%20element%2C%20note%20the%20gap%20it%20closes%20and%20the%20sourcing%20decision%20%28build%20%2F%20buy%20%2F%20share%29%20that%20obtains%20it%3B%20flag%20any%20element%20with%20no%20path%20to%20acquire%20it.%20Output%3A%20the%20four%20target%20layers%2C%20the%20integration%20map%2C%20and%20the%20gap-and-sourcing%20trace.) *(experimental deep link: pre-fills the prompt in a new claude.ai chat; check the bracketed parts before sending)* *Input, output and the kit skill are in the box above.* {% endtab %} {% tab title="Example on Progressa — coming" %} {% hint style="warning" %} **Worked example pending.** The prompt above is final and runs today. The Progressa worked example, the annotated reading and the what-next notes are added when this module's examples are run (Module 1 shows the shape). {% endhint %} Run the play on [Progressa](/experience-digital-transformation/gea/start-here/progressa-the-demonstration-country.md) yourself in the meantime: paste the sections named in **Bring** above, and read the result against **Watch for**. {% endtab %} {% tab title="What next" %} File the output as **A25** in your country workbook once you have worked it the way **Watch for** asks. A fuller what-next is added with the worked example. **This artefact feeds:** [4.6 Sequence your roadmap into waves](/experience-digital-transformation/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.6-phase-4-plan-sequence-the-roadmap-and-cost-it.md) See the full chain in [Your country workbook](/experience-digital-transformation/gea/your-country-workbook.md). {% endtab %} {% endtabs %} ## Sources * PAERA v1.0 §5.4 (Organisational Assessment & Roadmap) — * PAERA v1.0 §3.4.3 (Interoperability) — * PAERA v1.0 Annex 2 (Metamodel) — --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/gea/module-4-progressa-end-to-end-the-method-on-one-sector/4.5-phase-4-plan-design-the-target-architecture.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.