I follow an architecture principle I call The Law of Collective Amnesia.
Over time, everyone (including yourself) forgets the original intention of the system's design as new requirements emerge.
This law applies at all levels, from system design to microservices, or even libraries.
🧬 Systems Evolve (and Intent Fades)
When building new platforms/services/whatever, we create a system design that follows a structure.
Different components have distinct responsibilities; they interact clearly with the rest of the system, and there is a plan.
But as time progresses, new people may not understand the original intentions of the design.
As new requirements come in, the pressure to deliver may push you or others down a path that doesn't align with the original plan.
When the architecture’s intent is understood, additions can be beneficial. When it’s forgotten, they start to feel duct-taped on.
Duct-taped solutions turn into technical debt or operational/management complexity that starts to weigh the system down.
📠 How Good Systems Become Legacy Nightmares
We've all seen the legacy platform that feels brittle, does too much, and is daunting to refactor.
It didn't start that way.
At the time, it was probably a great design, but over time, new features and capabilities turned it into Frankenstein's monster.
👮 How to Defend Architecture from Collective Amnesia
While it may not be possible to prevent the system from devolving forever, you can reduce the need for duct tape solutions by designing for change.
📜 Roles and Responsibilities
An important—but not always effective—step is to document and define the roles and responsibilities of components within the system.
When a system is broken down into components with distinct roles and responsibilities, it becomes easier for people to make informed decisions about where new capabilities should reside.
The documentation “should” influence how change is implemented.
But it relies on people following that documentation, which is the fundamental flaw.
🚧 Architectural Guardrails: Make the Right Path the Easy Path
When I say "architectural guardrails," you probably think of review boards and ADRs. These processes are essential, but they don't always work as a prevention.
Instead, I mean designing the system so that the correct placement of functionality is the path of least resistance.
🔏 Contracts as Constraints, Not Convenience
In general, I feel like back-end APIs should provide as much data as possible, and it should be up to the clients to use what's relevant.
But sometimes contracts can be used to enforce design behaviors.
Systems can't act unless they receive the data required to act.
🚪 Control Ingress and Egress to Control Evolution
Ensuring that only specific systems serve as entry and exit points helps direct future design decisions.
It's often easier to add a new endpoint than to add a new platform that serves as an entry point.
Knowing this can allow you to put in place processing at those entry and exit points that ensure future capabilities follow specific patterns.
🧩 Design for Change, Not Today’s Requirements
When you are first building a system, it's easy to want to make it quickly based on the requirements in front of you.
But when you know a platform will evolve, it's beneficial to take time and implement interfaces that make the system more modular.
Within a microservice, this can be how you structure the application, how you create packages that can be extended even though you don't need them day one.
At a platform level, it could be the decision between monolith and microservices. If you know there will be a rapid change, it may make sense to leverage microservices. If you know there won't be a fast change, start with a monolith.
🧠 Final Thoughts: Assume Intent Will Be Forgotten
The above examples are just a subset of the ways you can enforce a design that aligns with your intentions.
The key lesson: don't build a plan that relies on people to follow your intentions. They won't.
You have to assume the next person won't design systems the way you do, they won't understand the reasons behind your design, and they'll be under pressure to deliver.