Lightspeed

Articles

Map & Document Your Enterprise

Build a working map of repositories, services and data flows, then use resident agents to keep it current as the enterprise changes.

Every enterprise has a landscape nobody fully understands: dozens of repositories, a few hundred servers, schemas that grew over time, and scheduled jobs that run because they always have. The documentation may explain the system as it was several years ago.

The consequences appear everywhere. Onboarding takes longer. An incident starts with finding someone who remembers the integration. A migration begins with another discovery project.

Agents can help by reading the systems directly, combining what they find, and returning regularly to check what changed.

Start with what is deployed

A Lightspeed agent can inspect an approved host through the environment daemon or reach a service through connected tools. It reads deployed configuration, examines scheduled jobs, and follows the connection from an application to the database it actually uses.

This gives the investigation concrete starting points. A repository explains the code; the running environment shows which version is deployed and how it is connected. Together they help reconstruct a more useful picture than either source alone.

The team chooses the access appropriate to discovery, such as read-only files and limited database credentials.

Split the landscape between specialists

A coordinator can delegate repositories, host groups or data domains to separate agents. Each receives a focused brief and the tools for that part of the estate.

The coordinator then brings the findings together: which job produces a file, which service consumes it, and which tables several applications share. Disagreements become questions to investigate. A dependency described differently at either end deserves another look.

Parallel discovery helps cover a large landscape while keeping each agent’s task understandable.

Put the map somewhere people can use

Findings live in persistent virtual workspaces: architecture notes, interface descriptions, diagrams and source extracts. Files collected from machines can be saved alongside the explanation they support.

People can review and correct these documents. The agents can read those corrections on their next pass, and reusable procedures can become skills for future investigations.

A fixed snapshot or file reference gives a reviewer a particular version to discuss. The working map can continue evolving as new systems are discovered.

Keep looking after discovery ends

A resident bot can revisit a service on a schedule, compare the current deployment with the map, and report changes. That continuing job is what makes the documentation useful beyond the initial project.

Imagine an overnight job moving to another host. The next inspection can find the changed schedule, update the dependency notes and flag any unanswered questions. The team learns about the change while the evidence is still available.

The agents’ conversations and notes can remain available without keeping a dedicated execution machine running for each one.

Make the next investigation easier

Start with one service and its immediate dependencies. Build a map the team can review, correct the gaps, and expand from there. The result becomes a shared working record for onboarding, incident response and future changes.

Read next: Map Legacy Banking Systems for a regulated discovery programme. For the file and knowledge layer, see workspaces and skills.