Principle of evolutionary architecture - any successful product will necessarily evolve over its lifecycle.
The challenge is how to keep migrating from the architecture we have to the architecture we need.
Instead of ripping out and replacing services, we put existing functionality behind an API and avoid making changes to it. All new functionality is implemented in the new services with the new, desired architecture, making calls to the old system when necessary.
The strangler pattern is useful for migrating portions of a monolith or tightly coupled services to one that is more loosely coupled.
Overly tight architectures - every time we commit code to trunk or release into production, we risk creating a global failure. Every small change requires enormous amounts of communication, coordination and approvals. Small changes have seemingly unknowable and catastrophic consequences. This downward spiral is the consequence of the second law of architectural thermodynamics - reducing our overall complexity and increasing the productivity of all our development teams is rarely the goal of an individual project.
A loosely coupled architecture with well defined interfaces that enforce how modules connect with each other promotes productivity and safety. Each service has a well defined API - it enables testing of services. Service oriented architecture allows small teams to work on smaller and simpler units of development that each team can deploy independently and safely.