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.
My preferred strategy for the Decision Log is to use it, not as an extra governance tool so much, but more as a learning tool. The learning aspects are:
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.
By: Rob Vens
Posted: March 11, 2016, 4:47 pm
Mediation, gespecialiseerd in zakelijke en ICT conflicten
Coaching van CIO's
Coaching van architecten (Enterprise, Business, ICT)
Trainingen op het gebied van Agile...