Most architecture diagrams are clean by necessity. They show applications, databases, network boundaries, cloud services, identity systems, and the connections between them. They help us understand how an environment was designed and how its major components are supposed to interact.
The real environment is usually a lot messier.
Systems change after they’re deployed. New functionality gets enabled, integrations are added, permissions expand, dependencies change, and something that was never intended to be externally accessible eventually finds its way to the internet. Over enough time, the architecture running the business can become meaningfully different from the architecture someone originally designed.
One of this week’s vulnerability disclosures is a particularly interesting example. Researchers identified a vulnerability in PostgreSQL functionality that had existed for roughly 12 years. The issue could allow an attacker with relatively low-level replication credentials to execute code and ultimately gain superuser privileges.
There’s something remarkable about a vulnerability remaining undiscovered for that long in software as widely used and closely examined as PostgreSQL. More importantly, though, it illustrates how much capability can exist inside the technology we depend on without being obvious from an architecture diagram.
A diagram might simply show a database. That box doesn’t tell us everything the database is capable of doing, which features are enabled, who can interact with them, how privileges are structured, or what other systems trust it. Those details are part of the architecture too, whether anyone intentionally designed them or not.
The same idea appears elsewhere in this week’s news. Attackers are exploiting internet-facing MikroTik devices, while an unpatched Magento and Adobe Commerce vulnerability is allowing malicious code to be introduced through application functionality. A breach at Mathspace reportedly originated with a vulnerability in its self-hosted Metabase reporting system, ultimately providing access to internal database records.
These aren’t identical Security problems, and treating them as though they are would miss the point. What connects them architecturally is the gap that can develop between our understanding of a system and everything that system is actually capable of doing.
That gap tends to grow over time.
Software evolves. Environments evolve with it. Teams change, ownership moves around, temporary configurations stick around longer than expected, and new business requirements create connections that weren’t part of the original design. None of this necessarily reflects poor architecture. Much of it is simply what happens when technology supports a changing business for years.
The challenge is making sure our understanding of the architecture evolves along with it.
Asset inventory is an important part of that, but knowing that PostgreSQL, Metabase, Magento, or a MikroTik device exists only gets us so far. Architecture also needs context around exposure, privilege, dependencies, trust relationships, and the potential impact if one of those systems behaves differently than expected.
That context changes how we think about risk. A reporting platform isn’t just a reporting platform when it has direct access to sensitive databases. A network device isn’t simply infrastructure when its management plane is exposed to the internet. A database isn’t just a place to store information when functionality inside it can ultimately provide a path to operating-system-level control.
This is one reason architecture reviews shouldn’t only happen when something new is being built. There is value in periodically looking at an existing environment as though you’re seeing it for the first time. Not because the original design was wrong, but because the system you have today may no longer be the system that was originally designed.
Good architecture needs to remain understandable as it changes.
The architecture diagram will probably never capture every feature, permission, dependency, or configuration in an environment, nor should it. But the organization should have enough visibility to understand where its important trust relationships exist, how critical systems can be reached, and what capabilities are sitting behind the boxes on the diagram.
Because eventually, every organization inherits some architecture it didn’t consciously design.
Understanding that architecture is just as important as designing the next one.
