This is my learning note from the book Solutions Architect’s Handbook written by Saurabh Shrivastava and Neelanjali Srivastav. All the contents are mostly distilled and copied from the book. I recommend you to buy this book to support the authors.
Another series: Fundamentals of Software Architecture: An Engineering Approach
Structure of the SAD
Solution overview: In the solution overview section, you need to give a brief introduction about the solution in a couple of paragraphs, describing the functioning of the solution and its different components at a very high level.
- Solution purpose: This provides a brief about a business concern that the solution is solving and the justification to build a given solution.
- Solution scope: This states the business scope that the proposed solution will address. Clarity describes out-of-scope items that the solution will not accommodate.
- Solution assumptions: List down all the assumptions based on which solution architect came up with the solution—for example, minimum network bandwidth availability.
- Solution constraints: List all technical, business, and resource constraints. Often, constraints come from industry and government compliances, and these need to be listed in this section. You can also highlight the risk and mitigation plan.
- Solution dependencies: List all upstream and downstream dependencies. For example, an e-commerce website needs to communicate with a shipping system such as UPS or FedEx to ship a package to customers.
- Key architecture decisions: List major problem statements and the corresponding proposed solution options. Describe the pros and cons of each option, why a particular decision was made, and the rationale behind it.
Business context: In the business context section, the solution architect needs to provide a high-level overview of business capabilities and requirements that the solution is going to address.
- Business capabilities: Provide a brief description of business capabilities for which the solution is being designed. Make sure to include the benefits of capabilities and how they will address customer needs.
Key business requirements: List all key business concerns that the solution is going to address. Provide a high-level view of key requirements and add a reference to the detailed requirements document.
Key business processes: Solution architects should show key processes with a business process document.
- Business stakeholders: List stakeholders who are directly or indirectly impacted by the project. This includes sponsors, developers, end users, vendors, partners, and so on.
NFRs: Solution architects need to focus more on NFRs as these often get missed by the business user and development team.
Conceptual solution overview: The conceptual solution overview section provides an abstract-level diagram that captures a big-picture view of the whole solution, which includes both business and technical aspects.
Solution architecture: The solution architecture section dives deep into each part of the architecture and provides different views that the technical team can use to create a detailed design and work on implementation.
- Information architecture: This section provides a user navigation flow to the application. At a high level, the solution architect needs to put in an application navigation structure.
- Application architecture: This section targets the development team. It provides more implementation details upon which a software architect or development team can build a detailed design.
- Data architecture: This section is primarily utilized by the database admin and development team to understand database schemas and how tables are related to each other.
- Integration architecture: This section mainly targets vendors, partners, and other teams.
- Infrastructure architecture: This section is primarily targeted at the infrastructure team and system engineers. The solution architect needs to include the deployment diagram, which can give a view of the logical server location and its dependencies.
- Security architecture: This section includes all the security and compliance aspects of the application.
Solution delivery: The solution delivery section includes essential considerations to develop and deploy a solution.
- Development: This section is essential for the development team. It talks about development tools, programming language, code repository, code versioning, and branching, with the rationale behind choices.
- Deployment: This section mainly focuses on DevOps engineers, and talks about the deployment approach, deployment tools, various deployment components, and deployment checklist, with the rationale behind choices.
- Data migration: This section helps the team to understand data migration and the ingestion approach, scope of data migration, various data objects, data ingestion tools used, source of data and data format, and so on.
- Application decommissioning: This section lists existing systems that need to be decommissioned and an exit strategy for the current system if the return on investment (ROI) is not being realized. The solution architect needs to provide an approach and timeline for decommissioning the old system and carry out an overall impact assessment.
Solution management: The solution management section is focused on production support and ongoing system maintenance across other non-product environments. The solution management section is primarily targeted at the operations management team.
- Operational management such as system patching and upgrades of dev, test, staging, and prod environments.
- Tools to manage application upgrades and new releases.
- Tools to manage system infrastructure.
- System monitoring and alerts; operations dashboard.
- Production support, SLA, and incident management.
- Disaster recovery and Business Process Continuation (BPC).