Main principal of Technical Design Document (TDD) for Project Deliveries

Technical Design Document (TDD) is mostly used for product and application feature development by realizing of business requirements for solutions (maybe specific problems).

I am going to describe some practices of mine to utilize TDD for any deliveries so TDD aim's will be  evolving from definition of general/common solutions for market/sector maybe ecosystem's problems to certain client demand/expectation description.

The primary function of a TDD for solution architect (SA) , is to communicate the technical details of the work to be done to the stakeholders who are going to get involved with.  However, there is a second purpose which is just as important: the process of writing the TDD forces SA to organize client expectation/requirement/thought and consider every aspect of the design, ensuring that there are no items/subjects left.

I propose you to keep in your mind following bullets while writing TDD for project delivery;

1. PURPOSE OF  DOCUMENT
   - It is necessary to describe the document with few sentences. Why we are preparing the document so one sentence about the Project/Delivery is enough? (mandatory)
   - target audience (mandatory)
   - use of the document such as punctuation, article/document design, sections brief (optional)
   - definition, acronyms and abbreviation (optional)
   - historical version information (optional)
   - references, TDD may address other documents such as HLD (High Level Document), LLD (Low Level Document), Functional Specification Document, RFP (Requirement for Proposal) or Solution Proposal etc. (optional)
   - Appendix (optional)
2. SOLUTION SUMMARY
   - executive summary : The summary should include the major details of the solution. Few words for each item to be supposed as features, functions and properties
   - business/functional requirements : It must collect all requirements and demands of the client. We clarify the boarder of customer expectations in the section. It must contain clear answer of "what does customer expect from the solution?". Note : Use-Case is not part of the section.
   - The dependencies of the solution should be defined by listing the constraints placed upon its use by other components.
    
3. SOLUTION DESCRIPTION 
   Detailed description of the solution to be proposed to the customer according to business/functional requirements.
   proposed product, software,program (if exists) related characteristics should be added based on the customer demands. Engineers/Implementer/Developers/Technical Architects should be able to convert them easily to the Epic-Stories or Tasks. It is such as generation of Business Use-Cases (BUCs) so modules, sub-modules, functionalities, domain based scopes might be in the section.
   Compatibility matrix can be created in order to see complexity of the customization/delivery and effort estimation maybe budget.
   Section may contains re-usability analysis from other deliveries for profitability. Most of the clients are looking for previous experiences from the service providers.
4. SOLUTION ARCHITECTURE
   Draw pictures for architecture of the solution.
   - Functional Architecture : Describes Interfaces and modules of the solution and interactions among nodes based on the business use-cases.
   Data Flow and Data Model should be part of the section so share all details of the data design here.
   - Application Architecture : Architectural details with components description of the solution itself.
   - Enterprise Architecture: Describe the positions of the solution in the current system of the clients. Defines north and south bounds for smooth integrations
   - Network Architecture: Hardware perspective architectures such as nodes, servers - cloud systems, infrastructure, deployment model (internet facing, intranet access,  delivery specific deployment for example: development, main, test,  bug fix ... environments)
5. SOLUTION DESIGN
   Let's define project delivery method, team setup, stakeholders roles and responsibility matrix, high level project time plan, epic-stories-tasks from business use-cases and test cases as well. Customization details, identifying integration in terms of  services to be consumed.
   Analysis document can be addressed as a reference and acceptance criteria(s)/test scenarios should be part of the section.
6. OPERATIONAL DESIGN
   Solution Characteristics: The description of the solution should be given in terms of the architecture that is being implemented with high level data flows described to set the context of the system. This section should set out to ‘characterize’ the system describing aspects of its operation.
   Sizing and Performance: Capacity (concurrent users figures) under peak times and normal business hours. Scenarios and KPIs (Key Performance Indicators) to be considered in case of performance test.
   Vulnerabilities: Impacts of the solution to the existing systems in terms of security. Define system hardening for new solution implementation.
   Stability: Describe the solution clustering structure, to be fault tolerant and accessible even catastrophic situations. 
7. BUSINESS CONTINUITY
   Backup strategies. important data protection and restoring system instruction can be added to here.
   Fail-over details, extensibility and scalability are important keywords for the section.
   System monitoring or alarm functionalities for surveillance of the system should be clearly defined.
   Regular maintenance activities for the solution are part of business continuity.
   Troubleshooting methods and log monitor of the solution needs to be clear in that section.
8. SUPPORT MODEL
   Support details.