Application Dependency Map Tool
Map which services call which, what they share and who runs them, and keep each one's owner, SLO and failure impact behind its tile.
Free forever on the Personal plan
Application dependency maps: an example
Calls and queues apart
Solid lines for requests a customer waits on, dashed lines for work that can wait in a queue.
Criticality at a glance
Tiles coloured by tier, so the services that page someone stand out from the ones that can wait.
An owner on every tile
Owner, SLO, callers and failure impact open from the service itself.
The basics
What is an application dependency map?
An application dependency map shows how the parts of a system rely on each other: which services call which, which queues sit between them, which data stores they share, and which outside providers they cannot run without. It is drawn from the point of view of failure, so it answers what else breaks when one part fails.
Teams use dependency maps to plan changes, set incident priorities, agree SLOs and decide what to move first in a migration. The lines show the dependencies; the next questions, such as who owns a service or how long it can be down, need a record behind each tile.
In Blueprintr each service on the map can open a stratum with its owner, tier, SLO, callers and failure behaviour, so the map and the service catalogue are one document.
Why Blueprintr
Dependency maps for the next incident
Draw the calls once, then keep the answers behind each service.
Services, queues and stores
Draw services, queues, data stores and suppliers with icons from the installed packs, colour them by tier and dash the ones run by someone else.
VellumOwner and impact behind each tile
Give every service a stratum with its owner, SLO, callers and what fails with it, in a table readers can scan during an incident.
StratumFollow a dependency
Link one service's record to the next, so a reader can follow the chain from a failing database to every service that calls it.
Snapshots from your tools
On Enterprise, Continuum Link attaches dated snapshots from tools such as Datadog, Dynatrace, New Relic, PagerDuty and ServiceNow CMDB to a service's record. It never changes the map.
ContinuumStart from a whiteboard
Photograph the map from a workshop and AI Convert turns it into an editable diagram. The free plan includes five generations a month.
AI FeaturesOne link for on call
Publish the map and link it from runbooks and the on-call handbook, or embed it in your wiki so the latest version is the one people open.
How to
How to make an application dependency map in Blueprintr
Create a blueprint
Sign up free, create a blueprint for the system and open the Vellum editor.
List the parts
Add a tile for each service, queue, data store and outside provider, grouped by the path they serve.
Draw the dependencies
Connect each caller to what it calls. Use solid lines for synchronous calls and dashed lines for queued work.
Add owners and tiers
Colour each tile by tier, then add a stratum with its owner, SLO and failure impact.
Publish and link it
Publish the blueprint and link it from runbooks, tickets and your on-call handbook.
Start from a template
Microservices system design
Clients, an API gateway and identity, five services with a database each and an event backbone, with strata for APIs, data ownership, events and SLOs.
FAQ
Questions about application dependency maps
Is this application dependency map tool free?
Yes. Drawing the map, the icon packs and strata are on the free Personal plan. Snapshots from monitoring and service management tools with Continuum Link are part of Enterprise.
Does Blueprintr discover application dependencies automatically?
No. You draw the dependencies, because the calls between your services are not something a scan can read reliably. On the Team plan, Continuum Cloud can draw the AWS and Azure resources underneath them.
What is the difference between a dependency map and an architecture diagram?
An architecture diagram shows how a system is built. A dependency map shows what relies on what, so it can answer what fails, or slows, when one part goes down. Many teams keep both as tabs in one blueprint.
How do I show how critical each application is?
Colour each tile by tier and add a small legend, as in the example above. Put the tier's meaning, such as which incident priority it triggers, in the stratum behind the legend.
Can I link the dependency map from runbooks and tickets?
Yes. Publish the blueprint and use its link anywhere, or embed the live diagram in a wiki page. Readers can open each service's record without leaving the map.
How do I keep a dependency map up to date?
Make updating it part of the change: when a service gains or loses a dependency, edit the map and publish. Every publish keeps a snapshot, and on the Team plan you can browse and restore earlier versions.