The document should consist of a high level description of the major components of the system and the interfaces between them. This is also a good place to describe system wide policies. The type of organization and application will determine the appropriate level of detail.
At a minimum the document should allow a small team of people to work on the design of the system at the next level of detail.
A document template might not help you that much. What is important is what you, as the "Solution Architect", want to say about your system.
This is possibly the lowest level of detail at which the non-technical people in the organization will attempt to understand the system, so it is perfectly reasonable to use block diagrams and/or diagrams using icon-style representations to illustrate the concepts.
My own technique for writing this kind of document is to write a skeleton of the document. Then, for each chapter, draw a diagram and base the words around it. Sometimes I have a few diagrams up my sleeve before I start on the skeleton. Usually these come out of conversations with other people about the system. The conversations might be with a stakeholder, when I am attempting to understand what we are supposed to build, or with a colleague, when I attempt to pass on my understanding.
Good luck!