infrainsight

How heavy is the DNS used for changes (records added/removed)? Do you have DNSSEC active? Does the DNS server also act as a caching DNS (given that you mention it as an external DNS, I suppose not)? These things can influence the specs of the server.

I would imagine that, for common use cases, low specs are fine, but as this is an external facing DNS server you probably cannot be certain that more interaction won't happen. If too lightweight, a lightweight DDoS might be sufficient to bring it down, which majorly impacts your service. So I wouldn't go below 2core, 4Gb.

But personally, I don't recommend hosting your own DNS. DNS is a brittle service the moment you want to do more than just exposing a single zone, and the complete DNS architecture shouldn't rest on a single service. There are dedicated DNS service providers out there that work very well, and can be programmatically configured (API).

I like the books from the SEI (Software Engineering Institute), although its been a few years that I bought new ones (or lend a few to read through). The "Software Architecture in Practice" by Len Bass, Paul Clements and Rick Kazman is one that I do still consult. Another one is "Documenting Software Architecture" by Paul Clements, Felix Bachmann, Len Bass and a few others.

While I also have "Evaluating Software Architectures" I was a bit more disappointed there, although that might be because I was expecting more content steering whereas the book is more about the process of evaluation (using methodologies like ATAM). My current job is strongly within the non-functional area, so I might be more biased there.

These books are however quite heavy. It might be better to first focus on lightweight architecture practices and pattern books/resources, as well as see how rigid software architecture is handled within your company. There is little value in massively focusing on architectural governance, frameworks, methodologies, processes and the like if the organization isn't tuned to this.

On top of schnapsidee's already correct feedback, if the company is willing to enforce documentation deliverables (which it really should), I've found it important to have a minimal documentation deliverable formulated. Don't immediately overshoot with all the different types and subjects, but find a set of documentation aspects that are agreeable by the company at large as a minimum. You can always increase this later, but it's hard to set the bar too high immediately as that removes any willingness from the organization as well.

You also can't just 'reset' the organization and suddenly do things in a different way. It will need to be evolved into a better documentation structure. Perhaps you could start with just a portal that points to the various existing documentation libraries and services. That can help you identify what types of documentation you have, and perhaps even find a good grouping. Also, try to see what information should be protected (don't want to have passwords laying around, or other risky information) versus which information should be easily accessible.