A solution design document (SDD) is the master technical specification that translates approved business requirements into a precise, build-ready system design — covering application configuration, integration architecture, data migration approach, security model, environment strategy, and non-functional requirements fulfilment. It is the primary governance artefact for the build phase of an ERP or EPM implementation: everything that is built must be traceable to the SDD, and everything in the SDD must be built. Deviations from the SDD — configuration decisions made during build that differ from the approved design — must be formally change-controlled and the SDD updated, not silently implemented and subsequently discovered by a tester or an auditor.
SDD Structure for ERP and EPM Implementations
A solution design document for a finance system implementation covers the following sections:
- Solution overview: The design philosophy, the scope of what is being built, the systems in scope, and the key design decisions made during the design phase with their rationale
- Application design: For each module in scope — the configuration decisions, the business rule implementations, the calculation designs (for EPM applications), the workflow definitions, and the reporting outputs delivered by the module
- Integration design: The integration architecture, with interface specifications referenced for each interface in scope
- Data design: The data migration approach, the data mapping decisions, the master data design (dimension structures, hierarchies, account classifications), and the data governance model that will operate post-go-live
- Security design: The role model, access control configuration, audit logging design, and regulatory compliance attestation
- Environment and infrastructure design: The environment strategy, infrastructure sizing (based on NFRs), and backup and recovery design
- Testing approach: The testing strategy, the test types planned for each phase, and the acceptance criteria derived from the NFR document
Common Gaps and Failure Modes
The specific failure that undermines the SDD’s value as a governance artefact is an SDD produced at a design level that does not distinguish between design intent and configuration decision. A section that states “the account hierarchy will be configured to support management reporting” has described an intent. A section that states “the account dimension in PBCS will contain three rollup levels: Natural Account → Reporting Line → P&L Summary, with the specific hierarchy members defined in Appendix C” has documented a configuration decision. The former is unusable as a build specification and as a test baseline. Acceptance test cases cannot be written against an intent; they can be written against a defined hierarchy structure. An SDD that cannot be used to write test cases is not a design document; it is a requirements summary with a different name.
How Loop Wise Solutions Produces This
Loop Wise Solutions produces SDDs to a configuration-decision level of precision — every section is written so that the build team can implement directly from the document, and the test team can derive acceptance test cases from it. We conduct a formal SDD review with the client’s business and IT representatives before build begins, with a sign-off process that confirms both the technical accuracy of the design and the business alignment of the configuration decisions. The signed-off SDD becomes the contractual baseline for build scope; any change to the design after sign-off is subject to formal change control.
Answers before you ask.
The master technical specification for an ERP or EPM implementation — translating approved business requirements into a precise, build-ready system design covering configuration, integration, data migration, security, and environment strategy. It is the primary governing artefact for build quality and the baseline against which acceptance testing is judged.
Because it defines precisely what is to be built across every dimension — configuration, integration, migration, security, environments — so the build has a definitive specification to construct against and be checked against. Building without an SDD means constructing on assumptions; the SDD is what makes build quality assessable against an agreed design. It anchors the whole build.
The SDD is the baseline for acceptance testing — the tests confirm the built system matches the approved design. Without the SDD as a reference, testing has nothing definitive to check the build against. The document defines what 'correct' means for the implementation, so acceptance is judged against it rather than against subjective expectation.
The SDD is the master design covering the whole implementation — configuration, integration, migration, security, environments; an interface specification details one integration point within it. The SDD is the overarching specification; interface specs are components beneath it. Confusing the scope — treating an interface spec as the whole design — leaves most of the build unspecified.