Application Dependency Mapping

Dependency Mapping in Action

For impact analysis and change management of IT systems.

The dependency map (or dependency model) helps predict and troubleshoot behaviors of the system during scheduled maintenance and unexpected failures, a process called "impact analysis".

The video below demonstrates manual modeling of dependencies using Blueprints™ to build an interactive dependency map, and using it to perform impact analysis of the system's susceptibility to various failure scenarios. Blueprints™ also supports automated IT discovery.

Dependency Mapping in Action

To learn more watch these additional instructional videos.

Use Blueprints™ yourself by registering for a free trial.

Example Dependency Map

In the diagram above, two relations are modeled as lines between objects: needs (green) and mounts (blue). A third, more subtle relation, hosts, is shown as one object contained by another.

Dependency Mapping Strategies

  • Directionality of dependency
  • Be sure to model the correct direction of dependency. Continually ask the question, "If this fails, does that fail, or is it the other way around?" Remember to model the direction of the dependency. Failure propagates backwards across the relationships.

  • Don't confuse data flow with dependency
  • It seems IT workers naturally fall back to thinking in terms of data flow and not necessarily dependency. Often the dependency direction is the reverse of the data flow direction. If A feeds data to B, B probably depends on A.

    There is nothing wrong with modeling data flows, but that's not dependency mapping. A dependency map is a relatively simple model a complex system because it doesn't get mired in too many details. A dependency map can tell you how the system might fail, give a sense of robustness or fragility, or show the scale, all without ever knowing how the data flows.

  • Keep it generic
  • It is good to generalize when modeling. The real world is messy and full of differences. Generalizing reduces those variations so you can see the forest for trees. If a map is as detailed as the real world, it's no more useful for understanding that world than the real world itself. The generalizations make the model tractable and therefore valuable.

  • Plan for constant change
  • In the context of information technology, a dependency map must continually change as the underlying IT environment changes.

  • Don't rely on automation exclusively
  • Automation is the Holy Grail which could provide results with little manual effort. But it's a never ending grail quest like all the others. The dependency map is a summary of knowledge for use by humans, and as such it must be compiled with substantial guidance by humans to fit human needs. Automation is excellent for providing a foundational inventory of objects, and can provide some relationships, but usually it provides too much minutia, and can't extract bigger picture.