D365 Solution Blueprint

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

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.