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
The Solution Architecture Document (SAD) provides an end-to-end view of application and helps everyone to be on the same page. In this chapter, you will learn about various aspects of the SAD, which addresses the need for all stakeholders associated with the development of the application.
The SAD helps to achieve the following purposes:
- Communicate the end-to-end application solution to all stakeholders.
- Provide high-level architecture and different views of the application design to address the application’s service-quality requirements such as reliability, security, performance, and scalability.
- Provide traceability of the solution back to business requirements and look at how the application is going to meet all functional and non-functional requirements (NFRs).
- Provide all views of the solution required for design, build, testing, and implementation.
- Define the impacts of the solution for estimation, planning, and delivery purposes.
- Define the business process, continuation, and operations needed for a solution to work uninterrupted after the production launch.
Views of the SAD
- Business View: Architecture design is all about addressing business concerns and solving business purposes. The Business View shows the value proposition of the overall solution and product. To simplify, the solution architect may choose to detect high-level scenarios related to business and present these as a use-case diagram. The Business View also describes stakeholders and the required resources to execute the project. You can define the Business View as a use-case view as well.
- Logical View: This presents various packages on the system so that business users and designers can understand the various logical components of the system. The logical view offers a chronicled order of the system in which it should build. It shows how the multiple packages of the system are connected and how the user can interact with them. For example, in a banking application, the user first needs to authenticate and authorize using a security package, and then log in to the account using the account package, or apply for a loan using a loan package, and so on. Here, each package represents a different module and can be built as a microservice.
- Process View: This presents more details, showing how the key processes of the system work together. It can be reflected using a state diagram. The solution architect can create a sequence diagram if you want to show more details. In a banking application, a process view can present the approval of a loan or account.
- Deployment View: This presents how the application is going to work in the production environment. It shows how different components of the system (such as network firewall, load balancer, application servers, database, and so on) are connected. The solution architect should create a simple block diagram that business users can understand. You can add more details to the UML deployment diagram to show various node components and their dependencies for technical users, such as the development and DevOps teams. The deployment view represents the physical layout of the system.
- Implementation View: This is the core of the SAD, and represents architectural and technology choices. The solution architect needs to put the architecture diagram here—for example, if it is 3-tier, N-tier, or event-driven architecture, along with the reasoning behind it. You also need to detail technology choices—for example, using Java versus Node.js, along with the pros and cons of using them. You want to justify the resources and skills required to execute the project in the implementation view. The development team uses an implementation view to create a detailed design such as a class diagram, but that doesn’t need to be part of the SAD.
- Data View: As most applications are data-driven, this makes the data view important. The data view represents how data is going to flow between the different components and how it will be stored. It can also be used to explain data security and data integrity. The solution architect can use the entity-relationship (ER) diagram to show the relationship between different tables and schemas in the database. The data view also explains the reports and analytics needed.
- Operational View: This explains how the system is going to be maintained post-launch. Often, you define service-level agreements (SLAs), alert and monitoring functionality, a disaster recovery plan, and a support plan for the system. The operational view also provides details of how system maintenance is going to be carried out, such as by deployment of a bug fix, patching, backup and recovery, handling security incidents, and so on.
You may choose to include additional views—such as a physical architecture view, a network architecture view, and a security (controls) architecture view, and so on—as per the stakeholder’s requirement.