chore: publish from main

2026-08-14 21:26:54 +00:00 · 2026-08-14 03:55:39 +00:00
parent 3922912e11
commit 26487ba912
4 changed files with 801 additions and 0 deletions
@@ -146,6 +146,7 @@ See [CONTRIBUTING.md](../CONTRIBUTING.md#adding-skills) for guidelines on how to
 | [csharp-nunit](../skills/csharp-nunit/SKILL.md)<br />`gh skills install github/awesome-copilot csharp-nunit` | Get best practices for NUnit unit testing, including data-driven tests | None |
 | [csharp-tunit](../skills/csharp-tunit/SKILL.md)<br />`gh skills install github/awesome-copilot csharp-tunit` | Get best practices for TUnit unit testing, including data-driven tests | None |
 | [csharp-xunit](../skills/csharp-xunit/SKILL.md)<br />`gh skills install github/awesome-copilot csharp-xunit` | Get best practices for XUnit unit testing, including data-driven tests | None |
 | [d365-solution-blueprint](../skills/d365-solution-blueprint/SKILL.md)<br />`gh skills install github/awesome-copilot d365-solution-blueprint` | Authors a Dynamics 365 Finance and Supply Chain Management Solution Blueprint from scratch through a structured, section-by-section architect interview, establishing scope, target operating model, application and data architecture, integration landscape, migration strategy, security model, ALM, testing, deployment, and support approach, with a decision log capturing rationale and rejected alternatives. Use when the user wants to create D365 implementation architecture documentation, start a D365 implementation, design the architecture, prepare a Solution Blueprint, or identify the architectural decisions the programme must make. Do not use for critique of an existing design; that is a review task rather than blueprint authoring. | `assets/blueprint-template.md`<br />`references/section-guide.md` |
 | [daily-focus-board](../skills/daily-focus-board/SKILL.md)<br />`gh skills install github/awesome-copilot daily-focus-board` | Spin up a personal, motivating daily focus board that renders in a browser canvas and that the user drives by talking to their AI partner. Tasks track status (to-do → in progress → done) with timestamped progress notes and roll up into a "today's momentum" feed; numeric-goal tasks (pages, pomodoros, reps) render as progress-bar counters. Executive-function / neurodivergent-friendly by design: Focus mode, kind "not today" carryover (no overdue-shaming), a brain-dump box, reduced-motion, and gentle deadline countdowns. Add, reorder, and relabel tasks live, assign Eisenhower priority (Do first / Schedule / Delegate / Later), open with an above/below-the-line check-in and a daily mantra, and save an end-of-day recap. Use when someone wants to plan their day, stay focused, kick off a work session, or track progress. Progress persists in the browser (localStorage). | `assets/board.template.html`<br />`examples`<br />`references/customize.md`<br />`references/neurodivergent-design.md`<br />`references/tutorial.md`<br />`scripts/serve-board.ps1` |
 | [daily-prep](../skills/daily-prep/SKILL.md)<br />`gh skills install github/awesome-copilot daily-prep` | Prepare for tomorrow's meetings and tasks. Pulls calendar from Outlook via WorkIQ, cross-references open tasks and workspace context, classifies meetings, detects conflicts and day-fit issues, finds learning and deep-work slots, and generates a structured HTML prep file with productivity recommendations. | None |
 | [data-breach-blast-radius](../skills/data-breach-blast-radius/SKILL.md)<br />`gh skills install github/awesome-copilot data-breach-blast-radius` | Pre-breach impact analysis: inventories sensitive data (PII, PHI, PCI-DSS, credentials), traces data flows, scores exposure vectors, and produces a regulatory blast radius report with fine ranges sourced verbatim from GDPR Art. 83, CCPA § 1798.155(a), and HIPAA 45 CFR § 160.404. Cost benchmarks from IBM Cost of a Data Breach Report (annually updated). All citations in references/SOURCES.md for verification. Use when asked: "assess breach impact", "what data could be exposed", "calculate blast radius", "data exposure analysis", "how bad would a breach be", "quantify data risk", "sensitive data inventory", "data flow security audit", "pre-breach assessment", "worst-case breach scenario", "breach readiness", "data risk report", "/data-breach-blast-radius". For any stack handling user data, health records, or financial information. Output labels law-sourced figures (exact) vs heuristic estimates (planning only). Does not replace legal counsel. | `references/SOURCES.md`<br />`references/blast-radius-calculator.md`<br />`references/data-classification.md`<br />`references/hardening-playbook.md`<br />`references/regulatory-impact.md`<br />`references/report-format.md` |
@@ -0,0 +1,165 @@
 ---
 name: d365-solution-blueprint
 description: Authors a Dynamics 365 Finance and Supply Chain Management Solution Blueprint from scratch through a structured, section-by-section architect interview, establishing scope, target operating model, application and data architecture, integration landscape, migration strategy, security model, ALM, testing, deployment, and support approach, with a decision log capturing rationale and rejected alternatives. Use when the user wants to create D365 implementation architecture documentation, start a D365 implementation, design the architecture, prepare a Solution Blueprint, or identify the architectural decisions the programme must make. Do not use for critique of an existing design; that is a review task rather than blueprint authoring.
 ---
 # D365 Solution Blueprint
 You are the solution architect running the blueprint workshop series. This is a multi-session engagement, not a document-generation shortcut. The blueprint is the output of a decision process. Your job is to run that process properly, then capture the resulting architecture.
 The failure mode to avoid above all others is producing a plausible-looking blueprint full of assumptions the client never actually made. A blueprint with ten of fourteen sections drafted and eight decisions still marked open is honest and useful. A blueprint with all fourteen sections complete and no open items, where you invented the answers, is dangerous because someone will build from it.
 ## Firm standards
 If `references/firm-standards.md` is present in this installed skill, read it first and let it override the defaults here. Document numbering, estimation models, rate cards, quality gates, and client naming conventions may be firm-specific. If the file is absent, use the conventions in this skill as written and never invent a firm standard.
 ## How this engagement runs
 ```text
 Session 1   -> Track A (Foundation). Must be first. Everything depends on it.
 Session 2+  -> Tracks B-E in any order the user prefers.
 Continuous  -> Decision log, open items, assumptions, constraints, and risks.
 Final       -> Consolidation pass and independent review.
 ```
 Each section follows the same five beats:
 1. **Frame** - state in two or three sentences what this section decides and why it constrains later work.
 2. **Ask** - put 3-5 questions to the user. Never dump twenty questions at once.
 3. **Propose** - where a genuine architectural choice exists, present 2-3 options with trade-offs and give your recommendation.
 4. **Record** - capture the decision in the decision log with rationale and rejected alternatives, or mark it OPEN with an owner and date.
 5. **Draft and save** - write the section, show it, persist the working file, and update the progress tracker.
 Do not run two sections in one turn unless the user explicitly asks you to move faster. The value is in the interrogation, and it collapses if you rush.
 ## Session continuity
 The working blueprint is the durable record between sessions.
 **At the end of every session:** save or update the blueprint file in the available workspace. Tell the user which file contains the current state.
 **At the start of every later session:** read the current blueprint first. Read the **Progress tracker** and **Decision log**, confirm where the work stopped, and summarize open items before continuing. Never re-ask a question that the decision log already answers.
 If the user resumes without the working blueprint and no persistent workspace copy is available, ask for the latest file rather than reconstructing decisions from memory.
 ## Track structure
 Read `references/section-guide.md` for the per-section question sets, option sets, and trade-offs. Load only the sections you are working on.
 **Track A - Foundation** *(must be completed first)*
 1. Programme context and business case
 2. Scope - apps, modules, legal entities, geographies, phasing
 3. Target operating model and process architecture
 **Track B - Solution**
 4. Application architecture - D365 apps, ISVs, Power Platform, extension posture
 5. Data architecture - master data, financial dimensions, product model, Dataverse/dual-write
 6. Integration architecture - middleware strategy, interface landscape, failure principles
 **Track C - Data and control**
 7. Data migration - migration scope, history strategy, reconciliation, tooling
 8. Security, compliance, and licensing - role families, SoD, XDS need, licensing shape
 **Track D - Platform**
 9. Environment strategy and ALM
 10. Reporting and analytics architecture
 11. Performance, scale, and volumetrics
 **Track E - Delivery**
 12. Test strategy
 13. Deployment and cutover approach
 14. Support and operating model
 Track A first is not a stylistic preference. Legal-entity structure and phasing decisions cascade into every later section. Reversing them after Track B has been drafted means reworking the architecture.
 ## Detailed-design boundary
 This skill owns blueprint-level decisions. It should not silently expand into every detailed implementation artefact.
 When the discussion reaches detailed interface specifications, role catalogues, timed cutover runbooks, or formal project health reviews:
 - if a suitable specialist skill is installed, hand off to it while preserving the blueprint decision as the governing input;
 - if no specialist skill is installed, keep the blueprint at architecture-decision depth and clearly identify the detailed follow-on deliverable rather than inventing a full downstream methodology.
 The skill must remain fully usable on its own.
 ## Load-bearing decisions
 Eight decisions are effectively irreversible, or reversible only at significant cost. When you reach one, do not let the conversation move past it with "we'll decide later."
 1. **Legal entity structure** *(section 2)* - how many, and what sits in each
 2. **Chart of accounts and financial dimension design** *(section 5)* - dimension count, mandatory dimensions, and reporting cardinality
 3. **Single vs multiple production instances** *(section 4)*
 4. **Deployment phasing** *(section 2, reconfirmed in section 13)* - big bang, geography, module, legal entity, or pilot rollout
 5. **Product and inventory dimension model** *(section 5)* - storage and tracking dimensions, batch/serial, variant strategy
 6. **Dual-write and Power Platform scope** *(sections 4 and 5)* - which entities, which direction, and failure behaviour
 7. **Extension posture** *(section 4)* - the standard-first threshold and who can approve a gap
 8. **Historical data treatment** *(section 7)* - migrate, legacy read-only, or separate archive/data store
 Each carries a `⚑` marker in `references/section-guide.md` and `assets/blueprint-template.md`.
 If the user cannot decide one of these in the session, do three things:
 1. record it as a **load-bearing open item**;
 2. name the decision owner and the date it becomes blocking;
 3. state which downstream sections are provisional because of it.
 For example: `Sections 5 and 7 are drafted on the assumption of X. If X changes, both sections require review.`
 ## Recording decisions properly
 Every entry in the decision log carries all six fields:
 | Field | Why it matters |
 |---|---|
 | Decision | What was decided, unambiguously |
 | Rationale | Why the decision was made |
 | Alternatives rejected | What else was considered and why it lost |
 | Implications | What the decision now constrains downstream |
 | Decided by | A named person, not "the project" |
 | Date | When the decision was made |
 Classify every material statement in the blueprint as exactly one of:
 - **Decision** - made, owned, dated
 - **Assumption** - believed true, not verified; owner and validation date required
 - **Constraint** - imposed from outside and not negotiable
 - **Open item** - not yet decided; owner and needed-by date mandatory
 Never let an assumption drift into being presented as a decision. Where you are working from an assumption, mark it in the section text as well as in the assumptions register. Write open items inline as `**OPEN - [owner] / [date needed]**` and also list them in the register.
 ## Interview technique
 The pattern that produces a real blueprint rather than a questionnaire response is:
 > **Ask the design question -> probe the constraint behind it -> surface the option the client has not considered.**
 Example on legal entity structure:
 > "How many legal entities?" -> "What drives that: statutory filing, functional currency, management reporting, or historical structure?" -> "Three of those entities have the same functional currency and file consolidated. Have you considered whether they all need to remain separate legal entities in D365, given the intercompany overhead?"
 When the user gives you a solution, work back to the requirement. When they give you a requirement, propose options. When they say "the same as we do today", ask whether today represents the target operating model or merely the current one.
 Where you disagree with a decision, record the client's decision accurately and add an **Architect's note** stating your recommendation and the risk you see. Do not silently design around it and do not refuse to document it.
 ## Verification discipline
 Before asserting what Dynamics 365 does or does not support, what a localisation covers, what a licence permits, or what a future release will provide, verify the current position against authoritative Microsoft sources when a documentation, search, or MCP capability is available.
 Prefer Microsoft Learn and current Dynamics 365 release documentation. Record the source and date checked in the blueprint. If current verification is not available, mark the statement as requiring verification instead of asserting it as fact.
 This matters particularly in a blueprint because an incorrect assumption about standard capability becomes an expensive gap later in the implementation.
 ## Output
 Use `assets/blueprint-template.md` for structure. Keep the **Progress tracker** at the top of the working file, immediately after the control page.
 - Working sessions -> Markdown (`.md`)
 - Client circulation -> Markdown or another document format if the active environment supports reliable document generation
 - Filename -> `<client>-solution-blueprint-v<N>.md`, incrementing the version as the blueprint is issued or materially updated
 At the close of the engagement, recommend an independent review of the completed blueprint. The author should not be the only reviewer of their own architecture.
 ## Tone
 You are in a room with people who know their business better than you do and know Dynamics 365 less well than you do. Respect both halves of that. Explain trade-offs in business consequences rather than feature terminology. Be willing to say "I don't know, and here is who we need in the room to answer it." Never fill silence with a plausible assumption.
@@ -0,0 +1,293 @@
 # Solution Blueprint - [Client]
 | | |
 |---|---|
 | **Version** | 0.1 |
 | **Status** | In progress - Track A |
 | **Solution Architect** | |
 | **Client sponsor** | |
 | **Last session** | [date] |
 | **Distribution** | |
 ---
 ## Progress tracker
 *Read this first when resuming. Update it at the end of every session.*
 | Track | Section | Topic | Status | Last updated | Open items |
 |---|---:|---|---|---|---|
 | A | 1 | Programme context and business case | Not started | | |
 | A | 2 | Scope ⚑ | Not started | | |
 | A | 3 | Target operating model | Not started | | |
 | B | 4 | Application architecture ⚑ | Not started | | |
 | B | 5 | Data architecture ⚑ | Not started | | |
 | B | 6 | Integration architecture | Not started | | |
 | C | 7 | Data migration ⚑ | Not started | | |
 | C | 8 | Security, compliance, and licensing | Not started | | |
 | D | 9 | Environment strategy and ALM | Not started | | |
 | D | 10 | Reporting and analytics | Not started | | |
 | D | 11 | Performance and volumetrics | Not started | | |
 | E | 12 | Test strategy | Not started | | |
 | E | 13 | Deployment and cutover ⚑ | Not started | | |
 | E | 14 | Support and operating model | Not started | | |
 Status values: `Not started` | `In progress` | `Drafted - open items` | `Complete`
 **Load-bearing decisions outstanding:**
 | # | Decision | Owner | Blocking by | Sections provisional if it changes |
 |---|---|---|---|---|
 ---
 ## Decision log
 | ID | Decision | Rationale | Alternatives rejected | Implications | Decided by | Date |
 |---|---|---|---|---|---|---|
 | D-001 | | | | | | |
 ---
 ## Assumptions register
 | ID | Assumption | Impact if false | Validation owner | Validate by | Status |
 |---|---|---|---|---|---|
 | A-001 | | | | | |
 ---
 ## Constraints
 | ID | Constraint | Source | Consequence |
 |---|---|---|---|
 | C-001 | | | |
 ---
 ## Open items
 | ID | Open item | Section | Owner | Needed by | Severity |
 |---|---|---|---|---|---|
 | O-001 | | | | | |
 ---
 ## Risks
 | ID | Risk | Likelihood | Impact | Severity | Mitigation | Owner |
 |---|---|---|---|---|---|---|
 | R-001 | | | | | | |
 ---
 # TRACK A - FOUNDATION
 ## 1. Programme context and business case
 ### 1.1 Drivers
 ### 1.2 Objectives and success measures
 ### 1.3 Governance and sponsorship
 ### 1.4 The fixed constraint
 ### 1.5 History and prior attempts
 ## 2. Scope ⚑
 ### 2.1 Applications and modules in scope
 ### 2.2 Legal entity register
 | Entity | Country | Functional currency | Statutory filing | Rationale for separate entity | Wave |
 |---|---|---|---|---|---|
 ### 2.3 Countries and localisations
 ### 2.4 Explicitly out of scope
 ### 2.5 Phasing decision and wave definition
 ### 2.6 Interim-state integration implications
 ## 3. Target operating model and process architecture
 ### 3.1 Operating model summary
 ### 3.2 Process architecture mapped to modules
 ### 3.3 Process ownership
 | End-to-end process | Business owner | D365 modules | Change from current state |
 |---|---|---|---|
 ### 3.4 Standard-first posture and gap governance
 ---
 # TRACK B - SOLUTION
 ## 4. Application architecture ⚑
 ### 4.1 Application landscape
 ### 4.2 Instance strategy
 ### 4.3 ISV register
 | ISV | Purpose | One Version compliance | Support model | Contract status | Risk |
 |---|---|---|---|---|---|
 ### 4.4 Power Platform scope
 ### 4.5 Logic placement principles
 ### 4.6 Extension governance
 ## 5. Data architecture ⚑
 ### 5.1 Chart of accounts design
 ### 5.2 Financial dimension design
 | Dimension | Mandatory | Values (approx.) | Report / decision it serves | Consumer |
 |---|---|---|---|---|
 ### 5.3 Product model and inventory dimensions
 ### 5.4 Master data ownership
 | Entity | Master system | Owner | Creation process | Sync method |
 |---|---|---|---|---|
 ### 5.5 Dataverse and dual-write scope
 ### 5.6 Dual-write failure behaviour
 ### 5.7 Number sequence strategy
 ## 6. Integration architecture
 ### 6.1 Interface inventory
 | ID | Interface | Source | Target | Direction | Pattern | Volume (avg / peak) | Frequency | Tier | Owner |
 |---|---|---|---|---|---|---|---|---|---|
 ### 6.2 Pattern selection rationale
 ### 6.3 Middleware strategy
 ### 6.4 Error handling, retry, and idempotency
 | Interface | Retry policy | Poison handling | Idempotency | Alert destination | Reconciliation |
 |---|---|---|---|---|---|
 ### 6.5 Monitoring and ownership
 ---
 # TRACK C - DATA AND CONTROL
 ## 7. Data migration ⚑
 ### 7.1 Object scope by class
 ### 7.2 Historical data decision
 ### 7.3 Opening balance strategy
 ### 7.4 Data cleansing ownership
 ### 7.5 Reconciliation and sign-off model
 ### 7.6 Tooling
 ## 8. Security, compliance, and licensing
 ### 8.1 Role family design
 ### 8.2 Segregation of duties requirement and authority
 ### 8.3 Compliance and data residency constraints
 ### 8.4 Record-level security assessment
 ### 8.5 Indicative licence shape
 | Role family | Headcount | Indicative licence type | Notes |
 |---|---|---|---|
 *Indicative only. Verify against the current Dynamics 365 licensing documentation and the client's contracted entitlement.*
 ### 8.6 Access administration and joiner/mover/leaver process
 ---
 # TRACK D - PLATFORM
 ## 9. Environment strategy and ALM
 ### 9.1 Environment topology
 | Environment | Tier | Purpose | Owner | Refresh cadence |
 |---|---|---|---|---|
 ### 9.2 Golden configuration approach
 ### 9.3 Source control and branching
 ### 9.4 Build and release pipelines
 ### 9.5 Service update governance
 ## 10. Reporting and analytics architecture
 ### 10.1 Report inventory
 | Report | Consumer | Decision it drives | Required latency | Tool | Owner |
 |---|---|---|---|---|---|
 ### 10.2 Tool mapping rationale
 ### 10.3 Analytics platform direction
 ### 10.4 Statutory reporting approach
 ### 10.5 Post-go-live report ownership
 ## 11. Performance, scale, and volumetrics
 ### 11.1 Transaction volumetrics
 | Process | Daily average | Daily peak | Monthly | 3-year projection |
 |---|---|---|---|---|
 ### 11.2 Data volumes and growth
 ### 11.3 User concurrency profile
 ### 11.4 Batch windows and hard constraints
 ### 11.5 Performance targets and acceptance thresholds
 ### 11.6 Archiving and retention direction
 ---
 # TRACK E - DELIVERY
 ## 12. Test strategy
 ### 12.1 Test levels and ownership
 ### 12.2 Traceability approach
 ### 12.3 Test data strategy
 ### 12.4 Regression automation decision
 *Include the calculated cost of not automating: hours per cycle x updates per year, ongoing.*
 ### 12.5 Exit criteria by phase
 ### 12.6 Defect severity model
 ## 13. Deployment and cutover approach ⚑
 ### 13.1 Deployment approach and wave plan
 ### 13.2 Cutover window constraint
 *Validate the window against measured full-volume dry-run timings.*
 ### 13.3 Parallel running decision
 ### 13.4 Rollback position
 ### 13.5 Go/no-go authority and criteria framework
 ## 14. Support and operating model
 ### 14.1 Support model and tiers
 ### 14.2 Hypercare definition and exit criteria
 ### 14.3 Knowledge transfer plan
 | Capability | Client recipient | Transfer method | By when |
 |---|---|---|---|
 ### 14.4 Post-go-live change process
 ### 14.5 Service update ownership
 ---
 ## Appendix A - References
 | Source | URL | Date checked |
 |---|---|---|
 ## Appendix B - Architect's notes
 | # | Section | Recommendation | Decision taken instead | Risk | Accepted by |
 |---|---|---|---|---|---|
 ## Appendix C - Version history
 | Version | Date | Sections updated | Author |
 |---|---|---|---|
 | 0.1 | | Initial structure | |
@@ -0,0 +1,342 @@
 # Section Interview Guide
 Load only the sections in play. Each entry gives what the section decides, the questions to ask, option sets where a real architectural choice exists, and the trap to watch for.
 **⚑ marks a load-bearing decision.** Do not let the session move past it without either a decision or a named owner and blocking date.
 ---
 ## Contents
 **Track A - Foundation:** 1 Programme context | 2 Scope ⚑ | 3 Target operating model  
 **Track B - Solution:** 4 Application architecture ⚑ | 5 Data architecture ⚑ | 6 Integration architecture  
 **Track C - Data and control:** 7 Data migration ⚑ | 8 Security and licensing  
 **Track D - Platform:** 9 Environment and ALM | 10 Reporting and analytics | 11 Performance and volumetrics  
 **Track E - Delivery:** 12 Test strategy | 13 Deployment and cutover ⚑ | 14 Support and operating model
 ---
 # TRACK A - FOUNDATION
 ## 1. Programme context and business case
 **Decides:** why this programme exists, what success looks like, and what is genuinely non-negotiable. Everything downstream gets prioritised against this.
 **Ask:**
 - What is driving this now: legacy end-of-life, growth, acquisition integration, compliance, cost, or another factor?
 - What does the business case commit to, in measurable terms? Who owns those outcomes?
 - Who is the executive sponsor and who has decision authority?
 - Which constraint is genuinely fixed: date, budget, scope, regulation, or something else?
 - What has been attempted before and what was learned?
 **Trap:** an efficiency business case that depends on process change nobody has agreed to make.
 **Produces:** drivers, measurable objectives, sponsor and governance, fixed constraints, and programme history.
 ---
 ## 2. Scope ⚑
 **Decides:** which applications, modules, legal entities, countries, and deployment waves are in scope.
 **Ask:**
 - Which Dynamics 365 applications and modules are in scope, and which are explicitly out?
 - ⚑ How many legal entities are proposed, and what drives each one's existence: statutory filing, functional currency, regulatory need, management model, or inherited structure?
 - Which countries and localisations are required?
 - What remains on another system, and who owns that boundary?
 - ⚑ What is the deployment phasing: big bang, geography, legal entity, module, or pilot-then-rollout?
 **Options to propose - phasing:**
 | Approach | Works when | Costs you |
 |---|---|---|
 | **Big bang** | Scope is compact or highly interdependent | Highest single-point cutover risk; no learning between waves |
 | **By geography / legal entity** | Units can operate semi-independently | Longer dual-running and interim integration complexity |
 | **By module** | A clear functional sequence is justified | Temporary integration between D365 and legacy processes |
 | **Pilot then rollout** | Many similar entities support a template approach | First wave absorbs template learning and needs strong governance |
 Always ask what the interim-state integrations and controls will cost.
 **Trap:** legal-entity structure copied from the legacy system without testing whether the reasons still apply.
 **Produces:** application/module scope, legal-entity register, country/localisation scope, explicit out-of-scope statement, and wave plan.
 ---
 ## 3. Target operating model and process architecture
 **Decides:** how the business will run after go-live and which processes D365 supports.
 **Ask:**
 - Is there a target operating model, or are we designing against current state?
 - Shared services or distributed processing? Which functions?
 - Where will approval authority sit, and is it changing?
 - Which processes are genuinely differentiating and which are commodity?
 - Who owns each end-to-end process and has authority to decide?
 - Are intercompany flows changing or simply moving systems?
 **Options to propose - standard-first posture:**
 | Posture | Statement | Suits |
 |---|---|---|
 | **Strict standard** | Business adapts unless a statutory constraint requires otherwise | Cost-led programmes with strong change appetite |
 | **Standard with justified exception** | Extensions require a documented business/regulatory reason and named approval authority | Most enterprise implementations |
 | **Fit to process** | System adapts heavily to existing business process | Rarely defensible without clear value and lifecycle-cost acceptance |
 **Trap:** "use standard wherever possible" without a threshold, approval forum, or authority to reject gaps.
 **Produces:** operating model summary, process architecture, process ownership, and gap-governance posture.
 ---
 # TRACK B - SOLUTION
 ## 4. Application architecture ⚑
 **Decides:** the application landscape, instance strategy, ISVs, Power Platform role, and extension posture.
 **Ask:**
 - ⚑ Single production instance or multiple? What requirement would justify multiple?
 - Which ISVs are in scope? What is their support and service-update posture?
 - ⚑ What belongs on Power Platform rather than in Finance/SCM, and why?
 - Which existing Power Apps, Power Automate flows, or Dataverse dependencies must survive?
 - ⚑ What is the extension-approval threshold and who can approve a gap?
 **Options to propose - logic placement:**
 | Layer | Use for | Avoid when |
 |---|---|---|
 | D365 configuration | Parameters, workflow, policies, standard behaviour | The requirement genuinely needs new business logic |
 | Electronic Reporting | Documents, regulatory formats, file-generation scenarios | Complex transactional logic |
 | Power Platform | Task apps, approvals, lightweight orchestration | High-volume transaction processing requiring ERP consistency |
 | X++ extension | ERP business logic requiring transactional consistency | Standard configuration or lower-code options can meet the need |
 | External service | Specialist domains and decoupled capabilities | It creates a platform the organisation cannot operate |
 **Trap:** an ISV selected before architecture without testing update compatibility, support model, and exit strategy.
 **Produces:** application landscape, instance decision, ISV register, Power Platform scope, and extension governance.
 ---
 ## 5. Data architecture ⚑
 **Decides:** chart of accounts, financial dimensions, product model, master-data ownership, and Dataverse/dual-write scope.
 **Ask:**
 - ⚑ Is the chart of accounts shared or entity-specific, and is rationalisation part of scope?
 - ⚑ Which financial dimensions are required, which are mandatory, and what decision/report does each serve?
 - ⚑ What product, storage, tracking, batch/serial, and variant dimensions are required?
 - Who owns customer, vendor, product, and other master data? Is there an MDM platform?
 - ⚑ Which entities, if any, are dual-written and in which direction?
 - What happens operationally if dual-write or another data-sync dependency is unavailable?
 **Options to propose - dimension design:**
 | Approach | Consequence |
 |---|---|
 | Few, governed dimensions | Cleaner posting, easier adoption, simpler reporting |
 | Many optional dimensions | Flexible analysis but higher complexity, weaker data quality, and larger cardinality |
 For each proposed dimension ask: *which report or decision does it serve, and who consumes it?*
 **Trap:** product/inventory dimension decisions made in isolation from costing, warehouse, quality, and reporting teams.
 **Produces:** COA/dimension design, product model, master-data ownership matrix, dual-write scope, and failure behaviour.
 ---
 ## 6. Integration architecture
 **Decides:** the interface landscape, pattern principles, middleware direction, and failure-design standards.
 **Ask:**
 - What is the full interface inventory: source, target, direction, volume, frequency, latency, and criticality?
 - What is the business consequence of each critical interface being down for four hours?
 - What middleware strategy is intended: direct, Azure Integration Services, existing ESB, or another platform?
 - Who owns each interface after go-live and who receives alerts?
 - Which legacy contracts or external interfaces constrain the design?
 **Pattern options:**
 | Pattern | Suits | Watch |
 |---|---|---|
 | OData / custom service | Low-volume synchronous access | Throttling and synchronous coupling |
 | Data management / recurring integration | Batch and bulk movement | Latency, staging, and error handling |
 | Business events | Event-driven notifications | Duplicate delivery and idempotency |
 | Dual-write | Near-real-time F&O/Dataverse synchronization | Coupling and failure behaviour |
 | Service Bus / Logic Apps | Decoupling, retry, orchestration | Additional platform ownership and operations |
 | Analytics export/Fabric path | Reporting and analytics consumption | Not an operational write pattern |
 For critical interfaces, require retry, poison-message handling, idempotency, alerting, ownership, and reconciliation at blueprint level.
 **Trap:** interface inventory sized on average volume and designed only for the happy path.
 **Produces:** inventory, pattern principles, middleware decision, failure principles, and ownership model.
 ---
 # TRACK C - DATA AND CONTROL
 ## 7. Data migration ⚑
 **Decides:** what data moves, how history is handled, how opening balances are treated, and how correctness is proved.
 **Ask:**
 - ⚑ Historical data: migrate, retain legacy read-only, or extract to an archive/data platform? What specific obligation or business need drives the answer?
 - Which objects fall into configuration, master, open transaction, opening balance, and historical classes?
 - What opening-balance treatment is required for GL, AR/AP, inventory, fixed assets, bank, and other relevant areas?
 - Where is data cleansing happening and who owns it?
 - Who signs off migrated data and against which source/control reports?
 - Which tools and environments are intended for migration?
 **Options to propose - history:**
 | Approach | Cost | Consequence |
 |---|---|---|
 | Migrate detailed history | Highest reconciliation and database cost | Full in-system history |
 | Keep legacy read-only | Ongoing legacy access cost | Fastest migration, weaker user experience |
 | Extract to archive / analytics store | Moderate implementation cost | Often a strong reporting compromise |
 **Trap:** historical migration requested by habit rather than a legal, audit, or operational need.
 **Produces:** migration scope, history decision, opening-balance strategy, cleansing ownership, reconciliation, sign-off model, and tooling direction.
 ---
 ## 8. Security, compliance, and licensing
 **Decides:** security principles, segregation-of-duties requirements, data-access boundaries, licensing shape, and access administration.
 **Ask:**
 - What job families and user populations exist, and across which legal entities?
 - What SoD expectations apply and who is the control authority?
 - Are there data residency, privacy, or sector-specific constraints?
 - Is record-level restriction required beyond legal-entity and organisational boundaries?
 - What licences are currently contracted and what assumptions underpin the quantity?
 - Who administers joiners, movers, leavers, privileged access, and recertification?
 **Trap:** licence entitlement agreed before role design and never revalidated against actual access.
 **Produces:** role-family model, SoD expectations, compliance constraints, XDS need, indicative licence shape, and access-admin model.
 ---
 # TRACK D - PLATFORM
 ## 9. Environment strategy and ALM
 **Decides:** environment topology and how code/configuration move through the landscape.
 **Ask:**
 - Which environments are entitled and what additional capacity is required?
 - What is each environment for, who owns it, and what is the refresh cadence?
 - Where is golden configuration held and how is configuration transported?
 - What branching and source-control strategy applies across all delivery parties?
 - How are builds, releases, approvals, and production deployments automated?
 - Who owns service-update planning and the regression gate?
 **Trap:** environment planning sized for build but not for migration rehearsals, UAT, training, and cutover concurrently.
 **Produces:** environment topology, refresh strategy, golden configuration approach, branching/pipeline design, and update governance.
 ---
 ## 10. Reporting and analytics architecture
 **Decides:** which information products are required and which technologies serve them.
 **Ask:**
 - Which reports are genuinely business-critical? Who consumes them and what decision do they drive?
 - What latency does each actually need?
 - What statutory and regulatory reporting exists by country?
 - What is the analytics-platform direction: Power BI, Fabric, existing warehouse, or another platform?
 - Who builds and maintains reports after go-live?
 **Tool-selection examples:**
 | Need | Candidate approach |
 |---|---|
 | Financial statements | Financial reporting capabilities |
 | Operational documents and statutory formats | SSRS / Electronic Reporting where applicable |
 | Operational enquiry | Standard D365 views and workspace capabilities |
 | Cross-functional dashboards | Power BI |
 | Enterprise analytics | Fabric / governed data platform |
 | Ad-hoc finance analysis | Excel integration where appropriate |
 **Trap:** "real time" requested without connecting latency to an actual decision cadence.
 **Produces:** report inventory, latency requirements, tool mapping, analytics direction, statutory approach, and ownership.
 ---
 ## 11. Performance, scale, and volumetrics
 **Decides:** whether the design can support expected production load and what must be tested later.
 **Ask:**
 - What are average and peak transaction volumes per critical process?
 - What are current and projected data volumes over three years?
 - What is peak user concurrency by function?
 - What batch windows and hard deadlines exist?
 - How long does month-end or another critical business cycle take today, and what is the target?
 - Which operational deadlines create non-negotiable performance constraints?
 **Trap:** annual averages used where peak-hour or period-end demand is the real design driver.
 **Produces:** volumetric baseline, growth projection, concurrency profile, batch-window constraints, and performance acceptance targets.
 ---
 # TRACK E - DELIVERY
 ## 12. Test strategy
 **Decides:** how quality is proven before go-live and maintained through future service updates.
 **Ask:**
 - Which test levels are required: unit, functional, integration/end-to-end, UAT, performance, security, regression, DR?
 - Who writes and owns tests and how do they trace back to requirements/processes?
 - What test data and volume will be used?
 - What regression automation is required, and what is the cost of the manual alternative?
 - What numeric exit criteria apply to each phase?
 - Who signs off UAT and readiness?
 **Trap:** no regression automation and no funded manual regression capacity.
 **Produces:** test-level model, traceability approach, test-data strategy, automation decision, exit criteria, and severity model.
 ---
 ## 13. Deployment and cutover approach ⚑
 **Decides:** the shape of go-live and the constraints a later detailed runbook must satisfy.
 **Ask:**
 - ⚑ Does the phasing decision from section 2 still hold after the rest of the architecture has been understood?
 - What cutover window is available and what drives its boundaries?
 - Is parallel running required? By whom, and what will it prove?
 - What is the rollback position and point of no return?
 - Who declares go/no-go and against which measurable criteria?
 - What business freeze is tolerable?
 **Trap:** a cutover window based on preference rather than measured full-volume migration timings.
 **Produces:** deployment approach, cutover-window constraint, parallel-running decision, rollback position, and go/no-go authority.
 ---
 ## 14. Support and operating model
 **Decides:** who runs the solution after implementation and how knowledge, updates, support, and change are governed.
 **Ask:**
 - What is the target support model: L1/L2/L3, internal, partner-managed, or hybrid?
 - What are hypercare duration, staffing, and exit criteria?
 - Which named people will hold functional, technical, and architecture knowledge after go-live?
 - Who owns the service-update calendar and regression gate?
 - What is the post-go-live change process for enhancements, new entities, and new requirements?
 - Who owns the Microsoft/product-roadmap relationship?
 **Trap:** knowledge-transfer plans with roles or teams named but no actual recipients allocated.
 **Produces:** support tiers and ownership, hypercare model, knowledge-transfer plan, update governance, and change process.