Architecture debates tend to be about technology choices. In practice, the decisions that determine whether a system can be changed in five years are decisions about boundaries: what is separated from what, and how expensive it is to move that line later.
Seams are what you are really buying
A seam is a place where the system can be taken apart without surgery. A well-placed seam lets a component be replaced, scaled independently, or handed to a different team. A badly placed one becomes the reason a rewrite is quoted instead of a refactor.
Microservices are one way to create seams, and an expensive one. Modules with enforced boundaries inside a single deployable give most of the benefit at a fraction of the operational cost, and they can be split later — precisely because the seam already exists.
Integration is the requirement, not the afterthought
Enterprise systems rarely start from nothing. The identity provider exists. The ERP exists. There is usually one system that everyone agrees is a problem and nobody is allowed to switch off. Those constraints are the actual shape of the project and belong in the first week of design, not the last month of delivery.
The most consequential architecture decisions are made before anyone opens an editor, in the conversation about what the system is allowed to depend on.
Write the decision down
Architecture decision records cost twenty minutes each and answer the question that otherwise takes a week of archaeology: why is it like this? A team that can read the reasoning behind a constraint can change it safely. A team that cannot will work around it, and the workaround becomes permanent.
Design for handover from the start
Assume the people who built the system will not be the people running it in three years. That single assumption improves documentation, observability, deployment automation and naming — and it costs almost nothing to adopt on day one.