Recommended format Solution Design Format for your Implementation

[sachinbhasin11]

This article would be quite helpful for folks in an Architect role, or somebody who is tasked to prepare a Solution Architecture document for their customers / implementation.  

Background 

Often working as a Platform Architect I am asked about preparing a SAD (Solution Architecture and Design document) for the Governance forums review. 

These governance forums are usually Architecture Forums (AGF/GF) or so-called Technical Governance Forum (TGF) who are responsible for vetting the overall solution keeping in view the business objectives and limits of the technology in question. There are certain key elements around which these forums operate such as scrutinizing technical debt, business objectives met, resources required, understanding System Integration complexities and Roadmap. Often the stakeholders in these forums come from an Architecture background and are SME of their own domain (sometimes Enterprise Architects too) 

To present this information to these stakeholders we need a document in proper format, and we may generally use this same format as an overall Solution Architecture & Design Document (SAD) 

Here is a sample format that I’ve been following for our customers  

===================================================================================

Context  

    Background

    Security Regulatory Compliance

    Guiding Principles

Business Function Impact

Scope & Requirements  

                   In Scope  

                   Out of Scope 

                   Requirements 

Solution Design  

Current State Architecture 

Future State Architecture 

High level Solution Design  

Conceptual Design 

Data Sets 

Data Model View – ServiceNow 

Foundations Data 

Impact on Existing Systems 

Key design decisions 

ServiceNow Components  ( for e.g. Catalog, Plugins etc.)

Integrations In Scope 

Integrations Conceptual View  

Integration Details 

Data Mapping 

Mobile App  

Details 

Technology Impacts

Assumptions 

Risk & Issues  

Data Classifications 

Data Sets (e.g. for IRM Entity, Risk Exposure, Framework , Risk Indicators etc. )

Data Archival  

Data Anonymization 

Data Normalization 

Exemptions/Technical Debt 

Glossary  

References 

===================================================================================

If you think we can add more stuff, then please add your comments on this article and I'll review and add.

This format is in general that I've used for my customers across the years 

[VasanthMuthuram]

Any sample document which you can attach ?

[crystalmorgan]

This is very helpful, thank you for sharing!  I recently joined a new organization and have been asked about a technical specification template.  This came in handy.  @VasanthMuthuram I just copied and pasted to word.  

[caleb_mitchell]

I used copilot to put together an example SAD for ITSM MVP.... 

Solution Architecture & Design Document (SAD) Example

1. Context & Background
• Overview of the project: Implementing ServiceNow ITSM for a global enterprise to streamline incident, problem, and change management processes.
• Business objectives: Improve service delivery efficiency, reduce incident resolution time, and enhance user satisfaction.
• Stakeholders: IT Director, ServiceNow Admin, Business Analysts, End Users.
2. Security & Regulatory Compliance
• Security requirements: Ensure data encryption at rest and in transit, implement role-based access controls.
• Compliance standards: Adhere to GDPR, HIPAA, and ISO 27001 standards.
3. Guiding Principles
• Architectural principles: Scalability, modularity, and maintainability.
• Design principles: User-centric design, minimal customization, and leveraging out-of-the-box features.
4. Business Function Impact
• Impact on business functions: Enhanced incident tracking, improved change management, and better visibility into IT operations.
• Key performance indicators (KPIs): Reduction in incident resolution time by 30%, increase in user satisfaction by 20%.
5. Scope & Requirements
• In Scope: Incident Management, Problem Management, Change Management, Service Catalog.
• Out of Scope: HR Service Delivery, Customer Service Management.
• Detailed requirements: Integration with existing CMDB, automated incident routing, customizable dashboards.
6. Solution Design
• Current State Architecture: Legacy ITSM tool with limited integration capabilities.
• Future State Architecture: ServiceNow ITSM with integrated CMDB, automated workflows, and real-time reporting.
• High-level Solution Design: Diagram showing integration points, data flow, and key components.
• Conceptual Design: Detailed diagrams of incident, problem, and change management processes.
7. Data Sets & Data Model
• Data Model View – ServiceNow Foundations: Overview of data entities and relationships.
• Data Impact on Existing Systems: Migration plan for existing incident and change records.
8. Key Design Decisions
• ServiceNow Components: Use of Incident, Problem, Change, and Service Catalog modules.
• Integrations: Integration with Active Directory for user authentication, integration with monitoring tools for automated incident creation.
• In Scope Integrations: Active Directory, monitoring tools.
• Conceptual View: Diagram showing integration architecture.
• Integration Details: Data mapping between ServiceNow and external systems.
• Data Mapping: Mapping of fields between ServiceNow and external systems.
• Mobile App Details: Enable mobile access for incident and change management.
9. Technology Impacts
• Assumptions: Availability of skilled resources, sufficient budget for implementation.
• Risks & Issues: Potential data migration challenges, user adoption risks.
10. Data Classifications
• Data Sets: Incident data, problem data, change data.
• Data Archival: Archival strategy for old incident and change records.
• Data Anonymization: Anonymization of sensitive data for compliance.
• Data Normalization: Normalization of data for consistency.
• Exemptions/Technical Debt: List of known technical debt and exemptions.
11. Glossary & References
• Definitions of key terms: Definitions of terms like CMDB, ITSM, SLA.
• References to relevant documents: Links to related documents like the project charter, requirements document, and compliance guidelines.