Among the factors that determine whether an organisation can withstand a crisis, yet rarely appear on architecture diagrams, the first two are closely connected: genuine control over the IT environment and a clear understanding of system dependencies. We discuss them together because neither is complete without the other. Control without an understanding of dependencies is blind. Knowledge without control is powerless.
Let us begin with control. Formally, every organisation claims to have it: systems have designated owners, access rights are assigned and documentation exists. Genuine control means more than that. It means the company truly understands what is operating within its environment, who can access it and what is changing. The gap between formal declarations and operational reality can be significant, even if it causes no visible problems under normal conditions.
That gap can be measured with a few straightforward questions. Who currently has access to the environment, including vendors and other third parties? What is running within it, including components introduced years ago and never properly documented? Who is aware of the most recent changes, and who approved them? An organisation with genuine control can answer immediately and with confidence. An organisation with control that exists only on paper promises to investigate. During a crisis, that difference directly affects response time.
The second factor is an understanding of system dependencies. An IT environment is not a list of separate components. It is a network of interconnected systems. The sales process depends on an application, the application depends on a database, the database depends on infrastructure, and many of these elements depend on external providers. An architecture diagram shows the building blocks. A dependency map shows how those blocks support one another and what else they may bring down when they fail.
During a crisis, unknown dependencies often prove the most costly. Each one is discovered at the worst possible moment: when it stops working. Instead of restoring the environment in a known sequence, the team has to investigate why a system that should already be operational is still unavailable and what additional component it requires. We discussed this in our article on the board-level question about the organisation’s single biggest point of failure. Without a dependency map, no one in the company can answer that question honestly.
Both capabilities can be developed in a similar way, without major investment. The starting point is an accurate record of the current environment: who has access, what is running, what depends on what, and which business processes rely on each component. The map should be built from the perspective of business processes rather than hardware. The board does not need to know the name of a server. It needs to know what could bring sales to a halt. A practical starting point is to create one map for the organisation’s single most important process. The remaining processes can be added gradually.
Such a map has one inconvenient characteristic: it becomes outdated. IT environments change faster than documentation, which means a one-off inventory often describes the company as it existed a year ago. Genuine control is not a project. It is a habit. Access reviews, dependency updates and change coordination must follow a regular cycle.
Finally, it is worth returning to the starting point. Neither genuine control nor an understanding of dependencies is visible on an architecture diagram, and neither can be purchased together with hardware. This is quiet, largely invisible work. Yet it determines whether, during a crisis, the company follows a map or conducts an investigation within its own environment.
