Dependency Mapping

Purpose

Dependency Mapping is the surgical diagnostic of distributed architecture. It reveals that microservices are often just distributed monolithic knots in disguise. Teams think in boxes, "This is my service." Dependency Mapping forces them to think in arrows: "I cannot ship if service B is down." It measures the true degree of systemic freedom and autonomy in an organization.

Context of Use

If the company repeats, "We are agile," while every release requires four weeks of release-train synchronization and a trivial frontend field change forces updates across three backend services, then deadly coupling is already in place. Dependency Mapping should happen before teams are scaled so you can check whether the architecture can survive that scaling.

Step by Step

1.Start the inventory: List the core components or squads.

2.Hard dependencies: Draw red arrows for synchronous blockers. For example, service A fails if service B does not answer in 100 milliseconds.

3.Soft dependencies: Draw blue arrows for asynchronous connections. For example, service A publishes a Kafka message for service B.

4.Organizational dependencies: Add an overlay, such as "Team A cannot deploy until Ops team C manually approves the firewall rule."

5.Count the edges: Count incoming and outgoing arrows per squad. The node with the highest incoming dependency count is your organizational bottleneck.

Example

Product velocity is highly uneven. Squad A ships weekly while Squad C needs months. A dependency map is drawn from checkout down to the database. The map reveals a giant spaghetti knot around Team B, the authentication backend. Nearly all twenty feature teams have organizational and technical hard links to this team. Team B is drowning in the cognitive load of hundreds of pull requests. Squad C is slow because it sits in Team B's queue.

Diagram

How Diagnosis Turns into Action

As Sam Newman emphasizes, every synchronous dependency in a distributed system is a potential weapon against availability. The arithmetic is brutal: 99.9 percent uptime for service A multiplied by 99.9 percent uptime for service B becomes 99.8 percent uptime for the combined path. Every extra crossing on a dependency map costs the organization real money in coordination meetings. The diagnostic exposes how often organizational charts lie about autonomy.

When This Method Fits Best

Unlike very broad causal loop diagrams that allow abstract sociological variables such as pressure or motivation, Dependency Mapping is hard and concrete: API calls, package dependencies, and ticket handoff silos between teams.

How to Use the Diagnosis in Everyday Work

Architects have to make trade-offs. The goal is never zero dependencies. That would be absurdly inefficient. The goal is asynchronous causality. If node A goes down, system B should not block the user. In architecture sessions, actively cut arrows on the diagram and ask, "How do we redesign this synchronous arrow into asynchronous event publishing so we do not have to wait anymore?"

First Analysis Steps

Use the Team Topologies lens. Any dependency that is not defined as a crystal-clear X-as-a-Service relationship with full automation is, by definition, a blocking collaboration or facilitation dependency that consumes large amounts of human bandwidth.

How You Recognize a Useful Diagnosis

When reviewing a proposed architecture change, do you inspect not only the new container or service but also whether it creates three new hard dependencies that multiply overall system risk?

Sources

Matthew Skelton & Manuel Pais — Team Topologies, Chapter 3: Inter-Team Dependencies

The Systems Thinker: Seeing Interconnections

Sam Newman — Building Microservices, Chapter 3: Coupling (O'Reilly, 2021)