Perhaps it’s not the best acronym in IT world! It stands for Solution Architecture Document.
Think of it as the blueprint for the solution. But if done properly it’s more than just a blueprint. SAD should articulate all aspect and concerns of the target solution and transition from “As IS” to “To Be” state. In other words SAD not only defines what the end product will look like, but also the journey to get to that point.
SAD should cover 4 pillars of the architecture:
- Business Architecture – key benefits and enablers, functional capabilities, processes, business users and their functions
- Information Architecture – source of truth of data, data entities and inter-relationship between data entities and cardinality (ERD)
- Application Architecture – application context including the core application being implemented or enhanced, and other systems the core application has interaction with; as well as the key components of each system playing a role in the overall solution
- Technology Architecture – further broken down to:
- Infrastructure Architecture – servers, network, switches, environments (DEV, UAT, PROD, etc.)
- Integration Architecture – including conceptual integration model, source and target systems, data flowed between source and target systems, frequency, volume and method (e.g. batch, real-time, etc.)
- Security Architecture –Identity and Access Management, Data Encryption etc.
- NFR’s (Non Functional Requirements)
The beauty of the SAD is, although it looks at the solution from various lenses (business, information, application, technology), it maps these architecture concerns with each other. For instance,
- What component of the “application” enables certain “business” function?
- What piece of “information” (data entity) is transferred from A to B in a given “integration”
- What technology equipment is needed to “secure” what “application component” which addresses a given a set of “functional capabilies”.
In addition SAD should outline:
- Solution high level scope
- Assumptions, Constraints and Dependencies
- Key architecture decisions (including solution options, pros and cons and rationale for the decision)
- Solution Delivery Approach – development considerations and tools, deployment approach, data migration, legacy system decommissioning
- Solution Operational Considerations – support model, user on-boarding, system administration, incident management, disaster recovery, backup and restore, etc.
What shouldn’t go to SAD?
- Detailed business requirements and processes
- Solution detailed design
- Project management issues such as schedule and timeline, cost, schedule, resourcing, risks
- Project governance approach
- Contracts, Agreements, SOW’s, etc.
Solution Architect is responsible to write up SAD.
It starts right at the initiation of the project when SAD is usually kept at the conceptual level due to the level of knowledge about the target solution and it later evolves to Logical and Physical levels as more and more details are discovered. SAD is a live, working document during the life-time of the project; however it’s a good practice to have it reviewed and possibly formally approved at different milestones during the project. In most organisations the formal body responsible to review and endorse SAD is called ARB (Architecture Review Board) which has representative from different areas including the Business, Enterprise Architecture, Infrastructure and IT Operation Management teams.
Click the link below for the complete template; feel free to use it, extend it or tailor it to your project needs.
Solution Architecture Document (SAD) – Template
Contact ali.nobar@integture.com.au for more information.