Making architectural decisions is just the how. I always start with why. Why do you have this particular problem that you are tasked to solve?
Why does the business want a new elevator service? Are the current solutions too slow? Is the problem actually optimizing elevator dispatch?
Similarly, understand the business can help choose between sql and nosql. Nosql or document databases are very flexible and works great for nested relations. Is that what the business data look like?
Also, design docs are necessary evil. You may or may not like them, it’s a tool for communication.
Sorry if all that seem too vague. I guess my point is you want to think like an engineer, so you have to understand requirements as well as the limitations.
