How do you start mapping your information system?

Launch the approach

Before collecting any information, state the need: preparing an audit, examining a migration or rebuilding shared knowledge of the information system. This objective determines the scope, the level of detail and the people to involve.

Distinguish the people who hold the information from those who will use the views. IT teams, business owners, CISOs and service providers can contribute to the collection; executives, auditors and project teams do not necessarily expect the same representation.

• Identify a sponsor who can arbitrate priorities and mobilise contributors.
• Choose a realistic scope: one site, one family of applications or one business activity.
• Formalise a target and a path: the layers to cover, the level of detail and the planned timeline.

Define your model and assess your sources

You rarely start from scratch. Gather spreadsheets, network diagrams, CMDB exports and project documents. Assess how current and reliable they are: information that is available is not necessarily still accurate. Complement this collection with targeted discussions with the people who know the scope.

Then agree on the objects, their attributes and their naming. A common naming convention prevents the same server from appearing under several names. The six-layer model provides a framework, but the starting point must remain suited to your context.

• Define the information needed for the decision: name, owner, criticality or hosting, depending on the intended use.
• Limit granularity: an attribute with no identified use means extra collection and maintenance effort.
• Document the relationships between the selected objects; they are essential to understanding dependencies.

Choose a tool that serves the method

The choice of tool comes after scoping. Assess it on your scope and your data: can you reuse the existing information, produce an understandable view and maintain the result with several people?

The guide proposes five criteria for assessing a dedicated tool. They must be considered together: the quality of the first diagram is not enough if updating it becomes too difficult.

• Centralisation: share a common base among contributors.
• View generation: use the data entered to limit redrawing.
• Collaboration: organise contributions from several teams.
• Import from existing sources: prepare imports from the available inventories.
• Rights management: adapt distribution to the scopes and to the sensitivity of the information.

Build a reliable first view

Start from objects you already know, then follow their dependencies to complete the scope. This approach lets you produce a usable view without waiting for an exhaustive inventory of every layer.

Have this first view reviewed by the people who know the applications and the infrastructure. Missing information must remain points to check: the absence of a relationship in the repository does not prove the absence of a real dependency.

• Check the names, the useful attributes and the links between objects.
• State the scope of the view, its date and its legend so that it remains understandable when it is shared.
• Before automating collection, define the rules for importing and checking data.
• Adapt distribution: a map can reveal sensitive information about your information system.

Organise updates over time

The value of a map depends on keeping it up to date. For each scope, answer three questions: who is responsible for it, when should it be updated and how are changes validated?

Build updates into existing processes: a project that adds, changes or removes a component must also update the corresponding information and relationships. Use the views in project reviews, operational discussions and audit preparation.

• Appoint a lead for each layer or scope.
• Define the events that trigger an update, and the periodic reviews.
• Plan light oversight to check how current the data is and arbitrate extensions to the model.

An example to make the approach concrete

The guide follows Akelia Distribution, a fictional company. Its team starts with the applications that matter for its commercial activity: the ERP, the B2B e-commerce site and their infrastructure. It imports its existing inventory, harmonises naming and completes the criticality information.

A first view then supports a discussion of dependencies with the logistics provider. The example illustrates a step-by-step approach; it is neither a customer testimonial nor a promise of timing.

Your first cycle in 30 days

The white paper offers this action plan as a starting point on a deliberately narrow scope. Adapt the pace to the resources and information available in your organisation.

• Week 1 — Frame the pilot scope, identify the sponsor and state the objective.
• Week 2 — Gather the existing sources and define the minimal model.
• Week 3 — Produce a first application view and its dependencies, and have it reviewed.
• Week 4 — Appoint the owners, organise updates and prepare the next cycle.