Dependency Mapping Across .NET Codebases, Terraform, Dynatrace, Confluence, Log…

Research Question

What practical tools and methodologies are being used to map dependencies across .NET codebases, Terraform configurations, Dynatrace Application Performance Management (APM) monitoring, and solution documentation in Confluence -- and how are organisations practically implementing these approaches to produce a detailed understanding of existing-state architecture and dependency trees? How do signals from log aggregation and the Configuration and Service Data Model (CSDM) extend and validate these maps? What role can locally-running Large Language Model (LLM) agents play in automating discovery and mapping across all these surfaces, given that every source will be incomplete, partially incorrect, or contain blind spots?

Supporting questions:

• What static analysis and tooling approaches exist for extracting dependency graphs from .NET codebases (project references, NuGet packages, inter-service calls, database dependencies)?
• How can Terraform configurations be parsed to produce resource and module dependency graphs, and what tools and Infrastructure as Code (IaC) analysis tools exist for this?
• How does Dynatrace APM's automated dependency discovery (Smartscape, service flow, topology) complement or conflict with statically-derived maps, and how is the data exported or queried?
• What is the role of Confluence documentation as a source of dependency information -- and what are its failure modes (staleness, incompleteness, inconsistency)?
• How do log aggregation pipelines surface runtime dependency signals that neither static analysis nor APM topology captures?
• What is CSDM in the ServiceNow context, and how does it model application, service, and infrastructure dependencies -- and where does it typically break down in practice?
• How can locally-running LLM agents automate the discovery and reconciliation of dependencies across all these surfaces?
• What strategies exist for handling the reality that all of these sources are partially wrong, incomplete, or out of date -- and how do organisations build confidence in their composite dependency maps despite this?
• What does a pragmatic "good enough" dependency map look like when starting from heterogeneous, imperfect sources?

Findings

(Populated from Section 6 Synthesis above.)

Executive Summary

[inference] The best-supported answer is to treat dependency mapping as a graph-merge problem: combine declared edges from code and Infrastructure as Code (IaC), observed edges from runtime telemetry, and curated ownership or taxonomy records from documentation and service-management systems. Sources: `terraform graph` command; Dynatrace service dependency graph; Confluence Representational State Transfer (REST) API v2 intro; ServiceNow CSDM data-foundation lessons.

[inference] The tool landscape splits into complementary evidence types rather than interchangeable products: static analyzers are strongest on declared structure, while Dynatrace, Elastic, Splunk, and Datadog map only the interactions that are actually observed through instrumentation and tracing. Sources: NDepend -- .NET architecture and dependency analysis; Depends -- open-source .NET dependency Command Line Interface (CLI) tool; Dependify -- .NET dependency visualisation workbench; `terraform graph` command; Dynatrace service dependency graph; Elastic service map; Splunk APM service map overview; Datadog service map.

[inference] Documentation and registry layers improve a map only when they are actively governed, because Confluence and CSDM can carry the ownership and business context that static and runtime tools miss but both degrade quickly without freshness discipline and stewardship. Sources: Confluence Representational State Transfer (REST) API v2 intro; Confluence content lifecycle management; ServiceNow CSDM data-foundation lessons; ServiceNow CSDM implementation lessons.

[inference] Locally-running agents are most credible when they orchestrate extractors, query interfaces, and reconciliation steps with explicit provenance, rather than synthesising unsourced dependency truth on their own. Sources: CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support; github.com; github.com.

Key Findings

1. [inference][high] Static extraction across .NET and Terraform should be the foundation of a dependency program because it provides the highest-confidence declared edges for code and infrastructure, but it cannot by itself prove live call paths, environment drift, or undocumented runtime coupling. Sources: NDepend -- .NET architecture and dependency analysis; Depends -- open-source .NET dependency Command Line Interface (CLI) tool; Dependify -- .NET dependency visualisation workbench; `terraform graph` command; Blast Radius -- Terraform graph visualisation; Rover -- Terraform visualiser.
2. [fact][high] Modern observability maps from Dynatrace, Elastic, Splunk, and Datadog are runtime-verification layers rather than universal architecture inventories, because each vendor explicitly ties visible edges to instrumented or observed interactions and documents blind spots when instrumentation or propagation is missing. Sources: Dynatrace service dependency graph; Dynatrace topology extension model; Elastic service map; Splunk APM service map overview; Datadog service map.
3. [inference][high] Confluence should be mined for architectural intent, terminology, and ownership clues, but its content should be downgraded in confidence unless each page carries explicit freshness and ownership metadata, because the strongest practitioner evidence shows that stale Confluence is the default failure mode. Sources: Confluence Representational State Transfer (REST) API v2 intro; Confluence content lifecycle management; github.com.
4. [inference][high] CSDM is the best enterprise layer for modelling service ownership, business context, and business-to-technical relationships, but it becomes misleading quickly when stewardship, automation, and use-case-driven governance are absent. Sources: ServiceNow CSDM data-foundation lessons; ServiceNow CSDM implementation lessons; github.com.
5. [inference][medium] A useful role for log aggregation in dependency mapping is to corroborate or investigate paths that are already suggested by traces, service tags, or request identifiers, because the public service-map evidence base is trace-first rather than raw-log-first. Sources: Elastic service map; Splunk APM service map overview; Datadog service map.
6. [inference][high] Local agents should orchestrate deterministic extractors, call APIs, merge graph fragments, and explain contradictions with full provenance, because both local graph-first tooling and prior repository work support agents as a transport and reasoning layer, not as an untraceable substitute for source systems. Sources: CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support; github.com; github.com.
7. [inference][medium] Curated model-as-code overlays such as Backstage metadata and Structurizr workspaces are valuable between raw extraction and enterprise registry layers because they let teams review, explain, and intentionally publish architectural relationships instead of relying only on generated diagrams. Sources: Backstage software catalog; Structurizr -- software architecture models as code.
8. [inference][high] A pragmatic "good enough" dependency map is an iterative, risk-based composite graph with per-edge provenance, freshness, semantic type, and confidence metadata, starting from business-critical services rather than attempting immediate estate-wide completeness. Sources: `terraform graph` command; Dynatrace Smartscape overview; Confluence content lifecycle management; ServiceNow CSDM data-foundation lessons; CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support.

Assumptions

• [assumption] Public materials understate the amount of bespoke internal reconciliation code used inside enterprises. Justification: extraction surfaces are well documented publicly, while end-to-end merge pipelines are mostly proprietary. Sources: `terraform graph` command; Dynatrace service dependency graph; Confluence Representational State Transfer (REST) API v2 intro; ServiceNow CSDM data-foundation lessons; CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support.
• [assumption] Organisations seeking this capability can obtain read access to the relevant code, observability, and registry surfaces. Justification: the technical pattern is viable only when governance allows the agent or pipeline to query all key sources. Sources: Confluence Representational State Transfer (REST) API v2 intro; docs.dynatrace.com; ServiceNow CSDM data-foundation lessons; Backstage software catalog.

Analysis

• [inference] The evidence points strongly toward a layered architecture because the sources describe different kinds of truth rather than competing measurements of the same truth. Static code and Terraform answer "what is declared"; APM and tracing answer "what was observed"; CSDM, Backstage, Structurizr, and Confluence answer "who owns this and how is it meant to fit together". Sources: `terraform graph` command; Dynatrace service dependency graph; Confluence Representational State Transfer (REST) API v2 intro; ServiceNow CSDM data-foundation lessons; Backstage software catalog; Structurizr -- software architecture models as code.
• [inference] The main trade-off is precision versus coverage: static analysis is precise but semantically narrow; runtime telemetry is behaviorally rich but instrumentation-bound; registries and documentation are broad but governance-bound. Sources: NDepend -- .NET architecture and dependency analysis; `terraform graph` command; Dynatrace service dependency graph; Confluence content lifecycle management; ServiceNow CSDM data-foundation lessons.
• [inference] The practical answer is therefore to merge the layers explicitly, preserve provenance for every edge, and let humans review only the contradictions and high-impact unknowns. Sources: `terraform graph` command; Dynatrace service dependency graph; Confluence Representational State Transfer (REST) API v2 intro; ServiceNow CSDM data-foundation lessons; CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support.

Risks, Gaps, and Uncertainties

• [fact] The public evidence base for raw-log-only dependency mapping is materially thinner than the evidence for tracing-based service maps. Sources: Elastic service map; Splunk APM service map overview; Datadog service map.
• [inference] Public sources describe extraction and modelling layers more clearly than enterprise reconciliation engines, so implementation detail for confidence scoring and conflict-resolution heuristics remains partly inferential. Sources: `terraform graph` command; Dynatrace service dependency graph; Confluence Representational State Transfer (REST) API v2 intro; ServiceNow CSDM data-foundation lessons; CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support.
• [inference] Organisations with weak ownership, poor tagging, or incomplete instrumentation will get less value from the composite pattern until those hygiene issues are improved. Sources: Confluence content lifecycle management; ServiceNow CSDM data-foundation lessons; ServiceNow CSDM implementation lessons; Backstage software catalog; Structurizr -- software architecture models as code.

Open Questions

• [inference] What is the best per-edge confidence formula when declared, observed, and documented sources disagree repeatedly over time?
• [inference] Which public benchmarks, if any, exist for evaluating cross-source dependency-reconciliation agents rather than single-source extractors?
• [inference] How should database and batch-pipeline dependencies be represented when call-based service maps under-report them?

sources

• [x] NDepend -- .NET architecture and dependency analysis
• [x] Depends -- open-source .NET dependency Command Line Interface (CLI) tool
• [x] Dependify -- .NET dependency visualisation workbench
• [x] Microsoft dependency guidance for .NET libraries
• [x] terraform graph command
• [x] Blast Radius -- Terraform graph visualisation
• [x] Rover -- Terraform visualiser
• [x] Dynatrace Smartscape overview
• [x] Dynatrace service dependency graph
• [x] Dynatrace topology extension model
• [x] Confluence Representational State Transfer (REST) API v2 intro
• [x] Confluence content lifecycle management
• [x] Elastic service map
• [x] Splunk APM service map overview
• [x] Datadog service map
• [x] ServiceNow CSDM data-foundation lessons
• [x] ServiceNow CSDM implementation lessons
• [x] Backstage software catalog
• [x] Structurizr -- software architecture models as code
• [x] CodePrism -- local graph-first code intelligence with Model Context Protocol (MCP) support
• [x] [Prior completed research: ](github.com)
• [x] [Prior completed research: ](github.com)
• [x] [Prior completed research: ](github.com)
• [x] [Prior completed research: ](github.com)
• [x] [Prior completed research: ](github.com)