In this awesome talk from React Finland 2019, Monica Lent discusses software architecture in understandable and well-defined terms.
The talk rejects casual use of big words like "architecture" and "technical debt" and demands you to define what they really mean when you use them.
Monica Lent's definition for software architecture is "enabling constraints". An architecture defines the constraints that will enable people to work productively on a project. When there is too little architecture, people will generate an overly complicated and hard to maintain system over time.
Cloud solution architects have been lucky in recent years. Amazon AWS provides a very well thought-out architecture for Serverless applications in particular. As an architect, you mainly need to know all the available building blocks and their non-functional attributes, such as pricing and scalability options. You can then create a cloud architecture just by combining these blocks into a system that matches your requirements.
Frontend architects need to do a bit more work, because they have more options available to them. There is some consensus about the most important things, like state management and component frameworks. You pick a state management framework like Redux or MobX, and a component framework like React, and together they define most of your architecture.
Architecture may also include a number of general development principles. Monica Lent's presentation includes some of them, such as inward-only pointing dependencies and conservative code reuse. There's nothing wrong with good principles, but developers will quickly forget them. If you want to enforce a principle, it needs to be somehow baked into the development process.
For example, AWS Lambda functions are always stateless, because they have no way to store state anywhere. This is often inconvenient at first, but the end result is an extremely robust and scalable microservice architecture. Lambda-based development enforces good architecture in this sense.
Amazon DynamoDB, on the other hand, presents a much more difficult architectural challenge. An architect may have initially designed a good database scheme for DynamoDB, but eventually developers need to add more entities and views to the system. DynamoDB doesn't set any constraints on what you store in the database and sooner or later bad decisions are made.
Referring to Monica Lent's talk again, one way to maintain best practices over time is to encode them into automated tests. Such tests can enforce specific rules about software dependencies, for example. The challenge, then, is how to write automated tests that enforce good DynamoDB database design. It's a challenging thought but certainly not impossible.