Skip to main content

Architecture Dependency Tracking

This document provides a guideline for tracking dependencies between architecture activities. A dependency exists when a specific activity needs to be executed before another activity can be executed or even started.

Although this document focuses on the dependency on and to architecture, the same concept can be applied to other areas.

NOTE: The purpose of the dependency tracking described here is to support project planning and execution. Modeling dependencies between software, hardware, and document artifacts, e.g., for what-if analysis at changes, is not the objective. Hint: never set a dependency to a work item that is done or closed.

Intended for​

Architects.

Who initiates dependency tracking?​

Many people in R&D may identify dependencies between different activities. However, if the system architecture is well understood, important architectural dependencies can be identified early in the agile work process as changes are planned. Therefore, the system architecture team is well-positioned and qualified to identify and define dependencies.

However, anyone in the organization is encouraged to identify dependencies and create links as described here. A dependency may be hidden at the more abstract system level and only uncovered as the design evolves.

How are dependencies tracked?​

Azure DevOps (ADO) is (primarily) used to track R&D team activities in PCP for software and hardware development, but also for architecture descriptions. ADO supports dependency links for tracking dependencies between work items, which is the dependency tracking method to be used.

A dependency can be defined within a stream (e.g. Operations), but can also span across multiple streams (e.g. from Operations to Engineering), or across projects (e.g. from Automation Vision (AV) Operations to System 800xA).

The dependent work items shall be linked with a successor-predecessor relationship that indicates what must come first (the predecessor) and what comes after (the successor).

A1

This reference defines the dependency and is automatically rendered in tools such as a dependency tracker or delivery plans.

A2

A3

Which work item types shall be linked as dependencies?​

In ADO, multiple work item types, such as system epics, epics, features, user stories, etc., are used. Dependency relationships can be defined for any item type. In principle, items should be linked to items of the same type (e.g., features to features, epics to epics, etc.). This is not mandatory; however, sometimes it is practical to link different item types to each other.

Example: When defining dependencies across different streams, a “source” feature may not yet have been created when the dependent feature is created. In such a case, set the dependency to the relevant source epic instead. If there is no epic, then put the dependency to the source system epic. This dependency link shall then later be redirected as the source features or epics are created. It is the responsibility of the successor to monitor the predecessor’s progress.

Example: Dependencies from system architecture work items - system architecture activities will also be tracked in ADO with system epics / epics / features. Hence, when creating architecture features in development streams, people shall search for potential dependencies on the system architecture work items and create appropriate links.

When are dependencies defined?​

Dependency links can be defined at any time during project execution. However, it is recommended that they be defined before the planning phase of the program increment cycle. This allows the planning to take the dependencies into account, reducing the risk that work items will be delayed or postponed to later increments.

The dependency tracking process in brief​

The following diagram represents the main steps of the definition of dependency tracking.

A4

How to monitor predecessor items' progress​

Since dependencies between work items might block multiple successor work items, the status and progress of predecessor items must be properly monitored. Owners of successor work items shall monitor the progress of their predecessor issues. If there are signs of delays, this shall be raised with the predecessor's owner and escalated if necessary. Rigorous transparency on ADO is required to make this process work.

How to deal with dependencies outside ADO​

The dependency tracking process described here assumes all activities are tracked in ADO. This may not always be the case, however. Some R&D groups may use other tracking tools, such as Team Foundation Server (TFS), and/or not use the agile template.

Unfortunately, there is no direct way to link ADO work items and (for example) TFS work items; hence, it is not possible to create an explicit dependency between (for example) a feature in ADO and a task in TFS.

If there is a need to create a dependency between such items, these are the steps that shall be followed:

  • Create a "proxy" work item in ADO that represents the original "external" work item we want to link. The "proxy" shall be the same type (epic/feature/user story) as the original. Copy all properties that are relevant to the tracking ("Title", "State", "Iteration Path", "Assigned To", etc.).
  • Create the dependency link according to the above.
  • Regularly and manually update the "proxy" item's properties from the original item.

This way, the dependency can be managed visually, as in all the other cases. However, the synchronization between ADO and TFS will have to be maintained manually.

Tools for automatic data migration​

Some tools are meant to migrate data across different systems and, theoretically, could be used to automate TFS-ADO synchronization. However, such solutions are more designed for bulk data migration, not for a constant data synchronization flow.

Owner: Architecture Team