Solution Architecture Definition (SAD) | Template Download
Objective and Contents
The Software Architecture Definition (SAD) document describes the subsystems and components of the solution by presenting a number of architectural views. Each view shows a different aspect of the system to address different concerns and is described in a separate section.
Assumptions and Constraints
Section 4 documents significant constraints, assumptions and requirements that influence the architecture of the solution.
Consider including subchapters on architecture components which are In Scope and Out of Scope.
Section 5 gives a high-level representation of the system's main components, the different user types, and interactions with external entities. It describes the boundaries of the solution.
Interactions between external systems, even if they are to carry out e-commerce functionality, are out of scope. They should only be documented if they are relevant to the SAP Commerce Cloud solution and only in summary form.
Section 6 shows how key functionality relevant to the solution architecture maps to releases and milestones. It is only at a high level. It helps to understand the project's roadmap and explain some key architecture decisions.
Do not duplicate contents with the Project Management Definition or User Stories. Only reference project functionality at a high level and only to help put the architecture changes in the strategic context.
Section 7 describes the key functional areas of the project. The goal is to provide context around the architecture – all software performs some functionality and the definition of this functional scope is a very important factor to define the architecture.
Do not duplicate contents with the User Story description or their Acceptance Criteria. Only reference functionality to help put the architecture changes in the wider solution context or to justify technical change.
Section 8 shows how the various processing steps within the system fit together to implement the overall functional requirements. This is necessary if the system relies on workflow processes, forked or parallel processing mechanisms.
Section 9 describes architecturally significant changes that enable the solution to achieve the agreed non-functional requirements (NFRs). Each change is mapped to the corresponding NFR category, which is based on the ISO/IEC 25010-2011 product quality model. Examples of things to document include caching architecture, load balancing, and how the solution ensures the chosen redundancy approach.
NFRs are documented and maintained in a separate deliverable and should not be repeated in the SAD.
- Relevant NFR spreadsheet content: Page response time should not exceed 1 second.
- Relevant SAD content in this section: In order to achieve high performing page response times, the solution will use caching type X, Y and Z which are configured as follows.
Section 10 describes the core structure of the system through its components and their interactions. Typically, this will include high-level technology choices for the components. It will also include an indication of the areas requiring extension in the base SAP Commerce cloud platform to provide the functionality required by the system.
Section 11 follows the logical section and describes the interfaces that will be required to the external system integration touch points.
Some projects might have a separate repository for interface designs. In this case, this section would only describe the principles at a high level behind the integration architecture and principles.
Consider including details on the (a)synchronous nature of some integrations and integration specific assumptions which determine key effort areas.
For complex integrations, spanning across several systems, this SAD section gives the end to end view and key design decisions arising from it.
Section 12 describes and explains any lower level design concepts if required, arising from the solution. It typically includes sections on:
- SAP Commerce Cloud extension structure and dependencies
- Solr - configuration, how indexes are organized and updated, and details on relevant customizations
- Other project specific key functional areas which require high-level specifications
Section 13 describes the high-level view of the infrastructure and provides a broad perspective of the following:
- Existing system landscape and planned changes
- How the system fits into the target environment
- Main high-level dependencies
- Specifically for each component, infrastructure details which are important to the architecture.
- The test and production environments which will be used during the project.
- Component versions - a summary of all software and hardware versions which impact or are part of the solution
- Section on size, performance, and scalability, which describes how the solution will/can cope with future changes to the traffic. This section also documents SAP Commerce Cloud licensing and how they would need to change for future infrastructure increases.
Section 14 describes the processes for:
- Code deployment in test environments
- Go-live deployment
- Any migrations required by the project. For example, Search Engine Optimization (SEO) migration, customer migration
Section 15 provides an area for details on how the architecture will support the operational needs. It includes high-level details on:
- Log file management
- Monitoring and alerting
- Issue tracking
- Project specific operational requirements
Section 16 includes details on:
- How each user type will authenticate
- Authorization mechanisms to different areas of the site
- Data security - if encryption is required, what type is used and how sensitive information is handled
- Password and credentials storing policy in SAP Commerce Cloud and external systems, if relevant to the solution
- PCI-DSS requirements, if any, and how they will be fulfilled
- Credit card information management
- Network controls and topology to support security. For example, DMZ, firewalls
- HTTPS management and management of SSL certificates
- DoS attack mitigation
This section is equally important for defining responsibilities as well as to avoid confusion in case of a security breach. Even if there are no requirements or solutions for specific areas, this should be clearly documented. Examples from projects include:
- The customer is responsible for the configuration of the public internet facing web server in the live production environment.
- The customer is responsible for obtaining SSL certificate, renewing and managing them.
- The project team and solution don't offer any protection from Denial of Service attacks. This is entirely under the customer’s responsibility.
In some cases, if the customer has the responsibility for a specific security area or mitigation (for example, DoS attack mitigation) but doesn't have the solution in place, this should be tracked as a project risk.
Section 17 includes details on:
- Data flows for the main data elements, for example, products, prices, and stock. The data flows need to show the sequence of components involved, the responsibility of each of them with respect to the data and if they are responsible for or owners of specific data attributes.
- Data propagation - details the synchronization process and any relevant customizations or data publishes which are related to it.
- Data model principles of the key project data entities and customizations
- Store data model - how the SAP Commerce Cloud webstore/basestore/warehouse/PoS map to customer business entities.
- Separate chapters describing customizations to key data entities like products, delivery modes, order, and customer.
The Solution Architecture Definition document should be treated as an evolving document throughout the project. It is important to keep the content up to date especially when the projects span over multiple releases. Refer to Project Delivery Framework for SAP Commerce Cloud for other project deliverables.