System Dependency

A system dependency is anything that needs another component’s data, behavior, availability, or decision in order to work. Before changing or retiring a system, the dependencies in both directions decide what can move independently and what will break. GOV.UK’s legacy guidance names interdependent systems that are hard to separate as a main reason such changes are slow and costly.

Look past the application

A fictional order database is read by a morning reporting job through a service account, feeds a nightly export to finance, receives status written back by an approval workflow, and is queried by a month-end reconciliation report. Scheduled jobs, files, stored procedures, dashboards, exports, service accounts, and people performing manual steps are dependencies as much as application code is. So are obligations attached to the data, such as who may see a record and how long it must be kept.

Rare work is the usual blind spot. A month-end report that runs twelve times a year does not appear in a week of traffic logs. Ask the people who do infrequent work, and observe over a window long enough to include it.

A missing edge is not proof of no dependency

Recorded data lineage helps locate consumers of a table or column, but its coverage has a boundary: spreadsheets, ad hoc queries, and unsupported tools may be absent. Confirm important consumers with their owners before a breaking change, and record the dependency, its owner, and what it needs, such as a field, a schedule, or a permission, so the migration plan can carry it.

Dependencies also run the other way. The new reporting path depends on the retained database’s schema, its service account, and its availability at 06:00. A change to any of those after cutover is a change to the new path too.

Reference: GOV.UK: Managing legacy technology. Examples here are illustrative.