Welcome to my standard solution architecture document template, which I have developed and continuously refined through two decades, and introduced in numerous corporations as their new standard.
I use it when working as a freelance solution architecture for clients if they don’t already have their own mandatory template in place, and I use it in my own development projects.
When encountering an in-house standard for solution architecture documentation, I use my own template as a checklist to ensure that I cover all the necessary aspects. More than often, my clients’ template has some gaps, which I then have to find a way to address while adhering to their preferred structure.
My template is not only useful for other solution architects. If you are a project manager or in any other role in a project, or a stakeholder in a project, this template can help you determine if the project is delivering architecture documentation of sufficient quality to address all relevant concerns, including adequately support long-term maintenance of the solution being built.
If you’re about to prepare a request for proposal (RFP) to have vendors bid on the solution, I recommend that you specify exactly how you want the solution architecture to be documented as part of the delivery.
I have been involved in many RFPs, and helped evaluate the proposals, and to this day I have never seen any vendor present a meaningful architecture documentation template. Don’t leave it up to the vendor – demand that they follow your standard (or mine)!
When looking at my chapter names you might be surprised that they don’t end with ‘view’. Among architects it’s understood that the document present views, which cover viewpoints, which align with your stakeholders’ perspectives. But that’s the underlying thinking – that doesn’t warrant calling things ‘views’ – they are, but don’t let your in-depth understanding of the finer points spill through – except in the content of the chapters that really matter.