[bluGill]

You cannot usefully change/review architecture decisions in 1 year. The point of architecture is to make the hard decisions that you will regret getting wrong in the future to try to get them right now (often without enough information to make them). If you decide to make a free for all an architecture will emerge that is a mess that you cannot change.

Architecture should not be "we have always done it like this". If you don't write down why though it will become that. Often there are good reasons that things have always been done like that - those reasons may or may not still be valid but if you don't know what they are it is hard to evaluation. More than once I've seen someone rethink a "we have always done it like that" and discover the hard way why they always did it that way.

I've never seen a company with a good way to write down why they do things though. When someone even tries nobody reads those documents.

[scaryclam]

It really depends on the decision, what was done, and the overall impact. If the decision is to migrate to microservices, a year in it may be reviewed and decided that the work has been far more than anticipated, and is too much for EVERYTHING to be migrated, and the decision changed.

Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.

A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.

[bluGill]

You can review - but by the time you really know it is too late. If things are going really bad after one year then start over. However often things that will go well long term are having "growing pains" at 1 year and so "staying the course" despite the pain might be the right decision. Until you have a microservices architecture you don't know the pros/cons of it for your system - you can get insight from others, but their system will be different and so will have different problems.

Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.

[fragmede]

A year is and is not a long time, so it depends on how seasonal the prosu is. New years celebration decorations are at one end of the spectrum, but it turns out a lot of things have a seasonality to them as well.