1. Don't pick an architecture because it's all the rage right now.
2. Don't pick an architecture that mimics your org's structure. Aka don't fall prey to Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law.
3. Don't pick an architecture that your team can't operationalize--e.g. due to lack of skills or due to business constraints.
You can't not fall prey to Conway's law. You can only choose how you organize your people and their interfaces.
A long time ago I remember hearing a good bit of advice that for a new project you should innovate the product or the tech stack but not both. I think this is similar: unless you have a lot of resources (people + political clout), don’t buck the existing org chart in more than one area if you can avoid it.
You’ll constantly be dealing with all the problems because nobody else will care.
The only counterexample to Conway that I have seen working is “away teams”:
https://pedrodelgallego.github.io/blog/amazon/operating-mode...
This is natural and even beneficial: it reduces communication and coordination costs, which is the costliest and hardest part of any organization or system. Perhaps that sometimes lands you in a suboptimal local minimum, but escaping that is usually quite costly in the short term. Think about how often top-down reorgs actually generate value.
* "I always urge builders to consider the evolution of their systems over time and make sure the foundation is such that you can change and expand them with the minimum number of dependencies."
* "There are few one-way doors. Evaluating your systems regularly is as important, if not more so, than building them in the first place."
This is useful advice to people who can make high level org decisions. But they don’t necessarily know what’s going on at a software level.
The people who do know what’s going on often have a very hard time getting buy in for refactoring. Many of them (rightfully) conclude it’s better to just make management happy churning out features.