The architecture diagram is usually tidy. The organization operating it rarely is.
A service may have a clear responsibility on paper and three different owners in practice. A data pipeline may run successfully while delivering information nobody trusts. Moving either one to a newer platform does not resolve that ambiguity.
Complexity needs an owner
Every new dependency introduces a relationship someone must understand. Who notices when it fails? Who pays for it? Who decides when it can change?
Those questions can sound administrative. They are design questions. A boundary that nobody can explain is not much of a boundary.
Before adding another service, I would want a short answer to four things:
- What specific problem does this separation solve?
- Which team owns the behavior at the boundary?
- What will a partial failure look like to a user?
- How could we remove or replace the component later?
Boring is a result, not a stack
An unfamiliar tool can be operated predictably. A familiar one can hide years of undocumented assumptions. The point is not to choose old technology automatically. It is to make the system understandable enough that ordinary changes remain ordinary.
For a cloud workload, that may mean a single deployment unit, a documented recovery process, and a cost boundary that matches a team's responsibility. A more distributed design may be justified later. The justification should be a constraint we can name.
Leave a trail
A short decision record often helps more than a perfect diagram. Record the constraint, the options considered, the tradeoff accepted, and the condition that would make the decision worth revisiting.
Future colleagues do not only need to know what was built. They need to understand why it once made sense.