Every architecture decision is right for the load, the team, and the business it was made for. None of those three stay fixed. Traffic grows unevenly. Teams reorganize. The business finds a new customer segment that the data model never anticipated. The architecture doesn’t fail because it was wrong. It fails because it was never revisited.
Most organizations treat architecture as a project milestone: design it, build it, move on. The teams that stay ahead treat it as a standing capability. They schedule the review the same way they schedule a security audit, not because something is broken, but because six months of business change is enough to make yesterday’s constraints obsolete.
Three signs an architecture is due for its next iteration:
- Engineers routinely work around it instead of through it.
- New features take longer to ship than they did a year ago, with no corresponding increase in scope.
- Nobody can explain a design decision without saying “that’s just how it’s always been.”
None of these are emergencies. All of them compound. Waiting for the emergency, a full outage, a security incident, a competitor shipping faster, is the expensive way to have this conversation.
The alternative isn’t a rewrite. It’s a rhythm: discover what changed, define what actually needs to move, architect for the constraints you have now, and ship the smallest change that unblocks the next stage of growth. That rhythm is the whole idea behind the Iteration Loop.
Architecture isn’t a deliverable. It’s a decision you keep making.