Architecture is not a diagram
When people think about software architecture, many imagine diagrams: boxes, arrows and colours. They are useful. But they are not the architecture.
I have seen projects with flawless diagrams and systems nobody really understood. The reason is simple: diagrams show what exists, but not why it exists. And when problems appear, what is missing is never a better drawing, but a clear decision.
Architecture is the set of difficult decisions that shape everything else. What to decouple and what to centralise. What to automate and what to keep manual. What to optimise now and what to postpone. Those choices determine how a system is built, how it is operated and how it evolves.
A good architect does not draw more. They decide better.
When an organisation treats architecture as a drawing exercise, it ends up debating form instead of substance. Time is spent aligning boxes and arrows while the real issues remain unresolved. The result is often fragile systems: technically sophisticated, but conceptually weak.
When architecture is understood as a process of decision-making, the opposite happens. Teams align, errors decrease and change becomes more predictable. Not because diagrams disappear, but because they are used for what they are meant to do: to explain decisions, not replace them.
Diagrams explain systems.
Decisions create systems.
That is architecture.