The dependency map is one of the best views to show dependencies across or inside workspaces.

One popular use case is showing applications and processes that realize the specific Capabilities, as shown below:

In this example, the component in context is the Business Capability, Integrated Risk Management. This component is shown at the top of the view. Underneath, descendant components are shown with square corners, and referenced components are shown with rounded corners.

In the above picture, the conditional formatting settings tell the Dependency Map to show the reference types (Is Expert In, Is Realized By) as labels.

Conditional formatting and other perspectives can often help the Dependency Map to tell a story. For example, below we have filtered the above Dependency Map to show only referenced Applications, colored by the total direct cost value, shows the most costly applications in orange, and the least costly ones in green.

Reference labelling options are very useful in Dependency Map. In the above picture, the reference labelling is configured to show the reference type at the top of each referenced component.

In the Dependency Map, groups and components have squared corners, and referenced components have rounded corners.

The default grouping in Dependency Map is Group by Parent All. Hence, when there are no grouping rules in the current perspective, the Dependency Map will show the component hierarchy, child components will be displayed downward from the context component.

Dependency Map supports several other types of grouping rule. As an example, this Dependency Map shows two degrees of incoming references of the context component, Active Directory, grouped by Component Type.

The Dependency Map traverses references in a graph structure, similar to the Block Diagram and other views in Ardoq. Therefore, it is easy to show multiple degrees of referenced components.

For example, we can display the Web and Mobile Applications Technical Capability with three degrees of incoming references.

These traversal settings generate a Dependency Map which shows that Web Portal has an incoming Impacts reference to Simplify IT, which has multiple incoming references from components in the People workspace, and one incoming reference from the Reduce technical debt Objective, which itself has an incoming reference from a Strategy component.

It is important to note that Ardoq only loads components which are directly referenced from a loaded workspace. Therefore, loading multiple workspaces will often produce a more detailed Dependency Map when traversing multiple degrees of relationship. In the above example, both the Projects and Objectives workspaces are open, and so the references from Simplify IT and Reduce technical debt are loaded, and are thus included in the traversal.

Each rounded-corner node in the Dependency Map represents a reference chain. Reference chains are strictly directional. This means that incoming references can only contain incoming references, and outgoing references can only contain outgoing references. It is not possible to use Dependency Map to show multiple degrees of relationship which change direction. In other words, if a component has an outgoing reference, and the referenced component has an incoming reference, it is not possible to show that 2nd-degree incoming reference. To display 2nd-degree references of this nature, we recommend Block Diagram.

An interactive illustrative visual simulation of how graph traversal works are available in a popover that’s triggered by the info icon which is placed inside the degrees of relationships dropdown.

Users can interact with the illustrative visual simulation by changing the values on either slider or hovering over the components.

For further reading on the concept of graph traversal, refer to the Graph Traversal knowledge base article. These concepts apply to Block Diagram as well as Dependency Map. However, due to the enforcement of reference chain direction (explained above), only the incoming and outgoing degrees of relationship sliders are available in the Dependency Map traversal options menu.

If there is depth to the component hierarchy, or if a grouping rule is applied resulting in a deep grouping, the Collapse Groups / Collapse Component Hierarchy slider can be used to change to a summary view of the top level groups.

Consider the following image, showing two degrees of incoming references from the Technical Capability Digital and User Experience. The component hierarchy is not collapsed here.

Using the slider to collapse the component hierarchy depth to 2 produces the following view:

One level of the component hierarchy has been collapsed, so Web Portal is hidden, but its references are displayed inside Web and Mobile Applications. Note the double border around Web and Mobile Applications and Simplify IT, indicating the component which contains collapsed children, and the referenced component which is the result of a collapsed hierarchy.

When the Show Only Connected Components view setting is enabled, components which do not contain references will be omitted from the view.

The Show Vertical or Show Horizontal view settings toggle changes how root nodes in the Dependency Map are laid out. A vertical layout is often useful in making more root nodes initially visible without needing to scroll down.

By default, the Dependency Map colors referenced components according to the component style. Enabling the Color by Reference Type view setting will color referenced components according to the reference style, using a lightened version of the reference line color as defined in Manage Reference Types.

To show the parents of referenced components, use the Include Reference Parents slider. This slider controls the number of levels to display in the component hierarchy.

Reference parents are displayed with a dotted border and a partially transparent background. When multiple references share a common ancestor, the parent nodes will be merged, as illustrated here:

Hovering over a component highlights all visible instances of that component in the view. So if I highlight Identity Management, both instances are highlighted.

Left-clicking a component navigates to that component, opening the workspace if necessary. Right-clicking a component shows the context menu for that component.

The view can be exported to PNG, or added to a new or existing Presentation, using the menu at the top-right of the view toolbar:

Components and references are sorted in Dependency Map, both at the view root and within each node. The navigator sort order is respected. Here is how the sort is applied in each node:

Components are sorted using the sort set in the navigator tree.

References are sorted with the following priority:

When reference parents are shown, references will be sorted accordingly, so the outermost reference parents are sorted by the navigator sort.