So, you’ve just spent three months creating a mountain of requirements. However, you have started to notice that you are now tiptoeing around, not disturbing the requirements in case there is an avalanche of stakeholder outrage – “how dare you remove that button” they say!

Another three months pass, and you start showing people what you’ve built, but you don’t get the response you expect. They are uninterested and ask about a requirement that has never been mentioned before…

There are many ways (and some of them are polite 😉) of describing why your boss is now asking for something completely different. I’ve grouped some of them under the “collective memory” heading. The collective memory is that general consensus, the overall flow of a situation – it is not about the detail. It is driven by / made up of:

• The pace of change in the world
• Perspective of “too much detail just give me the headlines”
• Don’t care to (or can’t) remember what I asked for x months ago
• Don’t want to be held accountable for boring long term goals – easier to forget

A good example of an industry where this is particularly obvious is media led companies.  Their needs as a business change with what is happening in the news, or events around the world. The requirements or underlying premise can literally change radically in 24 hours.

Architects should act as a longer term memory, helping teams and businesses get past the six month barrier, so that when the same argument or discussion comes up again you can layout what happened last time. Remember, though, that the conclusions might now be different.

Your product still exists

Importantly, though, there is still a product, there is still a solution, but not the exact requirements fought over in a number of meetings. What I found was that as long as you kept the general shape the same – they didn’t care about some of those early requirements, but they were interested in an evolved version based on the original themes and ideas. Architects are ideally placed to keep that product shape / essence helping teams to stay aligned.

The architect can also prevent another “memory gap”, that often gets missed in terms of governance and compliance. Firstly, many aspects of the design and solution are tailored to meet regulations – the design documentation should help trace compliance rules and key risks back to the areas of the solution that address them. In some organisations I’ve been involved in writing the actual risks and others just support the business articulate the risk in proportionate fashion. As with the other elements of a bigger picture is it easy for the reasoning behind them to fade as well.

Architects can act as a living record of intent, not just design. By linking decisions to principles, standards, and risk outcomes, architects help organisations avoid reliving the same compliance debates again and again. This does not mean freezing past decisions — it means making it clear why something was acceptable at the time, and what would need to change for it to be reconsidered.

I think that some of the reason that Agile has a lot of power is that it aligns with that short collective memory, reinforcing the need to deliver small change frequently in a visual / tangible way.