Or: don’t use the architecture Decision Log as a control mechanism.
Tempting isn’t it? All those architecture decisions get logged there. Favourite pastime of the control-freak enterprise architect: review the logged items and write comments on them, reset their state from accepted to rejected.
Don’t. Well, let them log. Let them review. Let them improve. But don’t interfere unless absolutely necessary. And with necessary I usually mean: you have something to bring to the table that will actually help the logger to learn, to improve their future decisions. And remember you are the last one in the chain of reviewers – or should be if you have your architecture process operating maturely.
My preferred strategy for the Decision Log is to use it, not as an extra governance tool so much (although it is a crucial part of the governance framework), but more as a learning tool.
The learning aspects are:
- The need to make architectural decisions explicit. Think what you are actually doing. Write it down so that someone else (and you, possibly, two months from now) can understand it.
- Review decisions from your team-mate. Understand, discuss, improve.
- Review decisions from other teams: what are they doing over there? Can we re-use some of it? Is there an overlap?
It may very well be that you see valid improvement points. But unless those really create large enough problems, it is often better just to let them be, and let the loggers discover for themselves what the improvement points are, than to interfere and order rework done. This way the process becomes a learning journey, where the net improvement over longer periods of time (say, years) is much higher than when you constantly give in to micro-governance.
Sustainable architectural velocity is what you should aim for.
