Everytime I sit to document an architecture, I am confused and take some time to start off. This time I sat to figure out why I was doing this everytime though I had done it N times before. The answer I got was that I was pondering about the target audience, the representation to be used etc. Finally I think I have the answer - “Don’t worry about it”�
�
When you start documenting the architecture, consider both technical and non-technical audience into consideration.  The first 1-2 sections of the document should address the non-technical group. Rest of it can be hard-core technical terms/concepts.  Now you may ask me why the non-technical group should be considered. This group consists of senior level managers, program managers etc who would like to validate if all their requirements have been met. Once they give a go-ahead, the tech team takes over to inspect the thought process under a microscope.
�
So here is the structure I found and liked:
1. Target audience for the document
2. Terminologies used
3. References - (Mainly your requirements/functional specification). If you are integrating with any external systems, refer to their architecture/design documents.
4. Non-functional requirements - Read through the requirements document and extract the non-functional requirements such as security, performance etc and list it here.
5. SAD structure (SAD - System Architecture Document)
6. Conceptual Architecture
7. Logical Architecture
8. Execution Architecture
9. Architecture Validation

Ashwin Mallur Parthasarathy Architecture & Design