When a modernization, compliance or security hardening project kicks off, the first question should be straightforward: do we actually know what we have?
In most cases, the answer is no, or only partially. There are architecture diagrams, sometimes an application inventory, often documentation produced at some point and never updated. But between what is documented and what is actually running in production, the gap is almost always significant.
IS mapping is not an academic exercise. It is the methodical prerequisite without which every transformation decision rests on an incomplete picture. And on a critical IS, an incomplete picture leads to costly surprises.
What “mapping” means in practice
Mapping an IS does not mean producing a diagram with boxes and arrows. It means making the layers of the system readable as they actually operate, not as they were designed five years ago.
In practice, mapping covers at least four levels. The first is the application layer: which components are in production, what their functional responsibilities are, and what their dependency relationships look like. The second is the data flow layer: what data circulates between components, through which protocols, at what frequency, and with what latency or availability constraints. The third is infrastructure: which environments each component runs on, with what runtime dependencies (runtime, database, cache, message queue), and under what deployment model. The fourth is identity and access: who accesses what, with which accounts, what authentication mechanisms, and what segregation rules.
On a contract management IS in the financial sector, this work recently revealed that the official architecture diagram did not mention three intermediate services added over time, that two nightly data synchronization flows ran through an FTP server that appeared in no inventory, and that production database access rights were shared via a generic account used by six people.
Nothing spectacular in isolation. But the accumulation of these blind spots makes the system impossible to transform with confidence.
Why existing documentation is almost never enough
Most organizations have documentation. The problem is rarely its complete absence, but rather its reliability and freshness.
An architecture diagram produced at initial deployment three or five years ago reflects a state that no longer exists. Components have been added, removed or replaced without the diagram being updated. Flows have evolved with business needs. Workaround scripts have become de facto components without ever appearing on the official documentation radar.
The result is documentation that creates the illusion of readability without delivering the substance. It is detailed enough that no one questions it, but too outdated to support a real decision.
This is why useful mapping does not start from existing documentation. It starts from production: logs, monitoring, Git history, interviews with operators, analysis of actual network flows. Existing documentation serves as a starting point, but it is systematically cross-checked against operational reality.
Invisible dependencies are the real risk
On an IS that has been running for several years, the most dangerous dependencies are not those that appear in diagrams. They are the ones nobody documented because they seemed temporary or secondary.
A batch job launched by cron every night to consolidate data between two systems. A CSV file deposited via FTP to a partner that has only accepted this format since 2018. A shared library used by three services whose version hasn’t been updated in two years because nobody knows exactly what side effects it would cause. A cache service masking a performance problem on the database, whose shutdown would cause visible degradation across the entire system.
These dependencies generally do not reveal themselves through static code analysis. They reveal themselves through analysis of actual activity: production logs, traffic patterns, timing anomalies, and above all the testimony of operators. An operator who says “we never restart this service because last time it broke everything” is often the best mapping source available.
Access rights mapping is a subject in its own right
On many IS, application mapping and access rights mapping are treated separately, if the latter is addressed at all.
This is a mistake. Understanding who accesses what, with which accounts, what mechanisms and what privilege levels is an integral part of reading the system. An LDAP directory or an identity provider doesn’t tell the full story: you also need to see service accounts, direct database access, API keys distributed without rotation, and inherited permissions that were never revoked.
On a project in the insurance sector, access rights mapping revealed that 40% of active accounts in the directory corresponded to employees who had left the company more than a year earlier. Not through malice, simply because the offboarding process did not include systematic revocation of technical access.
This type of discovery has a direct impact on the scope of any transformation. You cannot strengthen a system’s security if you don’t know who actually has access to it.
Mapping is not a deliverable, it’s a process
The classic mistake is treating mapping as a one-off project. An audit is commissioned, an 80-page report with diagrams is produced, it gets filed in a shared drive, and six months later it is already obsolete.
Useful mapping is a living thing. It is continuously fed by monitoring, deployments, security reviews and incident postmortems. It is accessible to the team and maintained as a system artifact, on the same footing as code or tests.
In practice, this can take very simple forms: an architecture diagram versioned in the Git repository, updated with every significant change. A component and dependency inventory maintained in a structured spreadsheet or a dedicated tool. A quarterly review of flows and access rights, integrated into the routine maintenance process.
The challenge is not the sophistication of the tool. It is the discipline of keeping it up to date.
What mapping enables afterwards
An up-to-date map does not solve anything by itself. But it underpins every subsequent decision.
It allows you to identify fragile areas before launching a modernization, rather than discovering them mid-migration. It allows you to properly scope a compliance project, knowing which flows and which access rights are actually affected. It allows you to prioritize security actions on the components that concentrate the risk, rather than treating the IS as a homogeneous block. And it allows teams to regain confidence in their ability to evolve the system, because they finally know what they are touching.
Without mapping, you proceed on intuition. With an up-to-date map, you proceed on facts.
Conclusion
Mapping an IS is not a preparatory exercise you can skip to move faster. It is the foundation that makes any transformation, any security hardening and any maintenance in a state of trust possible.
Reading an IS before pretending to transform it, distinguishing documentation from operational reality: these readings structure our engagements. Modernization and managed services for trust-critical systems.