I've been tasked with writing SAD's for our current two projects and there are many more coming, all similar although different in small ways, mostly technical (they all have a similar requirements) Let's first establish what I think an SAD is for: to provide a software design that satisfies functional and non-functional requirements with key use cases (4+1 model) to validate the design and various viewpoints for various stakeholders.Primary reason we now decided to have SAD's is because after reviewing these projects, we realized our developers need some direction on what to use, when and how.My question now is: is it wise to have a master SAD or reference SAD that describes project overarching requirements common to all projects (transactionality for example or prescribing a specific framework to realize IoC/DI).Are there examples of this approach? A classical 4+1 model view wouldn't work, because such a reference SAD would not include a concrete Use Case or Class. As such, a reference SAD would not actually design a specific system, which is kind of why SAD's exist in the first place.What I'm looking for is to describe once our common needs (package structure, tiers/layers, frameworks to use), while individual projects can minimize their copy/paste factor by referencing this common document and only provide Use Cases to illustrate and validate, class diagram and physical/deployment view.To give you an idea of what we're dealing with here, the differences between these projects are of the following order of size: mostly microservices or small webapps (all the same frontend tech) with none to small sized domain models, either a rational database or a document store. Some have REST, JMS, SOAP or a combination going in and/or out. All projects are some combination of these things and they are all implemented using the same frameworks and approaches.I prefer not to copy paste SAD's just to change a few details. I've also thought of writing an SAD for a virtual project or define profile SAD's to reference to. Or some other modular way of plugging together SAD's?I would love to gain some insight on how to deal with many similar projects in a homogeneous way so our developers know what to do./edit: the more I think about it, the more I feel a reference SAD cannot properly capture concrete application needs. They're just too specific for their use case. Maybe it's better to switch to multiple similar SAD's after all and try to move out as much as possible to a coding guidelines?
Extendable reference Software Architecture Document: good idea or not?
design;architecture;documentation