English | EN 
There’s a philosophical thought experiment that goes like this. “If a tree falls in a forest and no one is around to hear it, does it make a sound?” It’s meant to raise questions regarding observation and perception.
Arguably, the same goes for architecture – both physical and digital. If you build something, a house or a system, and then throw away the architecture describing how it’s been constructed, does it still have an architecture? Here it’s easy enough to argue that yes, it does still have architecture, it’s just not described as it was originally discussed.
However, we’ve been fed the notion that without architecture we’re lost at the sea of the system. And, yes, that’s true to some extent. But what we have done is to build countless shrines (file repositories, SharePoint, etc) to house architectural treasures of truth describing systems and relationships. And there they’ve often grown old and stale as the systems evolved.
And this becomes a big problem. Firstly, we have no idea of how the system is functioning. Second, if Sergeant Governance was to come along, we’d be slapped with so much documentation updates that any new features wouldn’t see the light of the day for quite some time.
Let alone the fact as we move from monolithic applications to small, distributed components – hello Microservices – that pop in and out at runtime, where we as humans have a hard time keeping up as the details overshadow the whole. We need to rely on algorithms to help sort out all the data – and often the system makes decisions on its own.
I was watching a presentation the other day by Ruslan Meshenberg, Director of Platform Engineering at Netflix. The talk was about Microservices and how Netflix has adopted it. Challenges and such. It was an interesting presentation. However, the “wait, what?”-moment for me in the presentation is at 28:20. Where Ruslan comments, “Once you get into this scale of microservices, you simply don’t have the luxury of architecture diagrams. Because things change all the time.”
Should we stop doing architecture diagrams? No. It’s fun, it’s great, it’s a means of communication before the system is built. But after the system is built, and we value a high degree of flexibility – supporting innovation, if you will – as the pace of digital is increasing day by day, we need other mechanisms to describe the architecture than a Word document in SharePoint.
Arguably, we should let the system describe it’s own architecture at runtime.
