We were brought in to look at a D365 F&O implementation that was over budget and visibly drifting, and the team handed over their SDD with some pride. It ran to forty pages. Thirty-eight of them were a module-by-module list of features to configure. The architecture principles section was a heading with a single sentence under it, the process architecture section was empty, and the assumptions and constraints section just said "TBD." They had a document called a Solution Design Document and almost none of the document that an SDD is supposed to be, and the project was paying for the difference every week.
This is the failure we see most often, and it is worth being clear that it is not really a documentation problem. It is a delivery problem wearing a documentation costume. The feature list is the easy eighty percent of the template, the part anyone can fill in, and the sections teams skip are the part that actually steers the build once the easy part is signed off. When the principles, the process architecture, and the assumptions are missing, the project has no way to settle the hundreds of design questions that come up after kickoff, so it settles them ad hoc and pays for the inconsistency later. Here is what those sections are for, and why we always look at them first.
An SDD is there to govern, not to list
The point of an SDD is to catalog the design alongside the architecturally significant requirements and the constraints that drive it. Those two phrases carry the whole idea. The document is not trying to enumerate every feature; it is trying to pin down the decisions and constraints that everything else has to respect, so that the build has something to be consistent with.
It is also meant to be a living document. The blueprint is forward-looking, and it gets updated across the life of the project, including the open issues and risks that are live at each stage. An SDD that was written once, signed, and never opened again has stopped doing its job, because the design it describes is not the design the project actually has six months in. The teams who get real value out of an SDD treat it as the current source of truth for the architecture, something they go back to and amend, rather than a gate they cleared at the start and never revisited. If your SDD is a static checklist of features, what you really have is a requirements list with the wrong name on the cover.
The architecture principles decide everything that follows
The most-skipped section is also the highest-leverage one, and it is the architecture principles. These are the handful of guidelines that act as the tie-breaker for every design decision the project is going to face, and a real D365 SDD states them out loud rather than leaving them implied. The five we see on well-run projects are worth spelling out, because each one quietly settles a recurring argument.
Configure over customize means you build within the out-of-the-box platform wherever you can, and treat customization as the exception that has to justify itself rather than the default reach. Reuse of existing capabilities means you lean on the integration middleware and process integrations that are already in place instead of duplicating that complexity, which keeps both risk and timeline under control. The focus on simplification covers both the technical side, which mostly follows from the first two principles, and the process side, where you consolidate regional differences into common requirements instead of building a separate variant for every country. Mitigating risk early means you go looking for the complex, risky components up front and isolate them for proofing, rather than tripping over them late in the build. And standardization means you keep the design coherent across workstreams, so processes stay repeatable and maintainable instead of each team inventing its own way.
The reason this section matters more than the feature list is that every meaningful build decision turns out to be an instance of one of these principles. "Should we customize this form or change the process?" is configure over customize. "Do we build a new integration or reuse the middleware?" is reuse of capabilities. "One process across all three regions or three variants?" is simplification and standardization at once. When the principles are written down, those decisions get made quickly and the same way every time. When they are not, every one of them gets re-argued by whoever happens to be in the room, and the project quietly accumulates the inconsistency it will pay to unpick later. The over-budget project we reviewed had customized dozens of things that a real configure-over-customize principle would simply have stopped.
Process architecture is the foundation, and it is usually missing
The second section teams skip is process architecture, and they skip it because it is genuinely harder than listing features. Process architecture defines the operational processes the solution is meant to run. It is the basis of scope, and every other architecture, application, data, integration, exists to support those processes rather than the other way around.
When an SDD jumps from "here are the business goals" straight to "here is the module configuration," it has quietly dropped the layer that connects the two. What you get is a build that configures features which each work in isolation and never come together into a coherent end-to-end process, because nobody defined the process the features were supposed to serve. On the project we reviewed, the empty process-architecture section sat directly upstream of their integration troubles. Each module had been configured on its own, and the handoffs between them, which are the actual process, had never been designed by anyone. Getting the order right, process first and then the architectures that support it, is not bureaucracy. It is what keeps the features in service of a working process instead of standing as a pile of disconnected configuration.
Assumptions and constraints are what make scope real
The third skipped section, the one that so often reads "TBD," is assumptions and constraints, and this is where scope stops being a conversation and becomes something concrete. It records what the design takes to be true and the boundaries it operates within.
Without it, every ambiguity that surfaces mid-build resolves in the most expensive direction available, because there is no written record of what was actually agreed. Was multi-currency in scope? Was the legacy system staying for two years or being switched off at go-live? Did the design assume the standard tax engine or a localized one? When these are captured as assumptions and constraints, a question during the build gets answered by the document and the project moves on. When they are "TBD," the same question gets answered by an argument, and the argument tends to end with someone building a thing that was never supposed to be in scope in the first place. Assumptions and constraints are not throat-clearing before the real content. They are the boundary that makes everything else in the design mean something specific rather than something still up for negotiation.
What a real SDD leaves you with
A Solution Design Document that will genuinely govern a build has architecture principles stated plainly, so every later decision has a tie-breaker, and it has assumptions and constraints written down, so scope is concrete and ambiguities resolve back to the document. It defines the operational processes in a process architecture, with the application, data, and integration architectures positioned as support for those processes rather than as the main event. It describes how data moves and where the system boundaries sit, not merely which entities exist. The module-level solution detail is in there too, but as the supporting cast, because that is the part everyone already knows how to write. It carries open issues and risks as living content, because the blueprint is forward-looking, and it has a revision habit that keeps the document matching the solution as the solution changes.
The feature list is the part every team produces. The principles, the process architecture, and the assumptions are the part that decides whether the project stays on its rails, and an SDD missing them is a document that says what to build while saying nothing about how the thousand decisions after kickoff get made. That governance is the entire reason the document exists.
