I have sat in a lot of architecture meetings. Councils, review boards, guilds, working groups. Some of them made decisions that are still in force years later. Some made decisions that were being argued about again within a month. For a while I assumed the difference was the quality of the people in the room. I no longer think so. I think it is a handful of habits, and most of them are boring.
Decisions nobody can find are not decisions
The most common way an architecture decision dies is not that someone overturns it. It is that nobody can find it. The decision lived in a meeting, or a thread, or a slide deck that was accurate for one quarter. A new team joins, asks the question fresh, and gets a fresh answer, because the old one is gone.
So the first habit is dull: write the decision down in one place that everyone knows about, in a form short enough that people will actually read it. What was decided, what the alternatives were, and why this one. A page is enough. A paragraph is often enough.
I think the reason matters more than the decision. A decision without its reason cannot be revisited honestly, because nobody can tell whether the reason still holds. A decision with its reason can be retired the day the reason stops being true, and everyone will agree.
The people who decide should be the people who live with it
An architecture group made of people who no longer write code will make decisions the people who do write code quietly route around. Not out of rebellion. The decision just does not fit the work as it actually is, and the people doing the work know that.
I have come to believe the group has to include people who will feel the consequences. That means working engineers, and it means engineers from the teams the decision touches, not only from the platform team that proposed it. It also means the group should be small enough to actually decide. A room of twenty can discuss. A room of six can decide.
Decide the question, not the technology
The decisions that last tend to be about boundaries and contracts: how services talk to each other, who owns what, what a team may depend on and what it may not. The decisions that age fastest tend to name a specific library or version.
That is not an argument against choosing a library. It is an argument for being clear about which kind of decision is being made. A boundary decision can be written once and hold for years. A technology choice is the current best answer and should carry a review date, so that when it is replaced nobody feels a rule was broken.
Give every decision a date
The decisions I have seen hold longest, strangely, are the ones that were explicitly temporary. A decision with a review date gets revisited on purpose, by the group, with the reason in front of them. A decision with no date gets revisited by accident, by whoever is most frustrated, usually in a pull request comment.
I think the review date does something else too. It lets people accept a decision they disagree with, because they know there is a time and a place to make the case again. Most of the energy that goes into relitigating decisions is energy that had nowhere else to go.
Where this stops being true
A small team does not need an architecture group at all. Three engineers who talk every day are the group, and writing down decisions is still worth doing but the rest of this is ceremony.
And some decisions are not the group's to make. When a direction comes from above, from a merger, a compliance requirement, or a platform choice made for the whole company, the group's job is not to decide but to work out what the decision means for the systems it owns and to write that down. I think a group that is honest about which questions it actually owns keeps the authority to decide the ones it does.
Photo source: https://photos.robertstowe.com/utah