Recently, I read the book Software Architecture and Decision-Making by Srinath Perera. It contains a lot of content that is available in other software architecture books but offers some unique angles on certain topics.
I think the author is right to point out that you need to design deeply things that are hard to change, especially database schemas. For businesses, data is gold, and making changes to it comes with enormous risks. Therefore, changes are very rare and done only when absolutely necessary. The same applies to customer-facing APIs (or even internal APIs). These are usually contracts that other parts of the system adhere to, so changes to them come at a big cost. Facebook was famous for following the adage "move fast and break things," but after they annoyed developers with constantly breaking APIs, they changed their attitude to "Move fast with stable infrastructure."
The author also emphasizes the business environment where the architect operates. The skill level of the team is important when designing a system, as well as the required time to market.
Often, naive implementations are the best to get the business going. The architect must be the person who, using their judgment, takes calculated risks and assumes responsibility for the outcome; otherwise, the whole team becomes blocked.
Something that I haven't encountered previously is a chapter discussing mental models explaining performance. I strongly believe that good mental models are essential in enabling good judgment when making software decisions, so seeing a chapter dedicated to mental models explaining performance was great. I've been spending a great deal of time trying to understand how computers work in order to build better and more performant systems.
Another useful part is the one talking about the importance of testing and enforcing behavior from a management perspective. It's important for a designer or manager to understand the team's motivations and design processes in a way that makes it hard to avoid writing tests. Often in startups, this is omitted because they focus on developing as fast as possible. The role of a designer is to understand the importance of this and create incentives that make people want to write tests; otherwise, it might be easier to pass on the buck. Demanding excellence is also very important. Some companies don't enforce excellence standards because they cause stress to the developers. We all make mistakes, so we shouldn't blame the developers if something happens, but it's important to enforce certain standards and strive to raise them for the team. It's vital to remove anything that the developer doesn't control from the equation, but they need to be held responsible if they don't meet certain diligence standards. Otherwise, there is no incentive for the rest of the team to hold themselves to a higher standard.
One of the big issues in tech is mindlessly copying architectures from popular companies like Uber or Netflix without considering the actual problems that should be solved, often resulting in building antipatterns like distributed monoliths. The book points this out in the microservices chapter and offers alternatives like repos-based teams. The same goes for building event-driven and asynchronous software. That requires developers to really understand how to write such systems, and without that knowledge, the systems produced might have additional complexity without the actual performance boosts.
Overall, the book gives a very good overview of many leadership considerations when leading software projects without going too much into technical details, so I would highly recommend it.