Relationships

What a relationship is

A relationship connects a source element with a target element and has a type, one of the 21 in the language. The wording of the type reads from source to target, like a sentence: source, wording, target.

The rules are expressed in terms of element families, named types or layers. For example, the “funds” relationship (funds) only starts from funding (Funding), and “depends on” (dependsOn) only connects elements from the technical layers.

Structural relationships

Structural relationships describe how the architecture is made up: the whole and its parts, who performs a behaviour, and what makes a service real.

The “is composed of” relationship (composition) connects a whole with the parts it is made of, while “aggregates” (aggregation) groups elements that also make sense on their own, for example the projects (Project) of a programme (Programme). Source and target are of the same family; a source from the location family accepts any target.

The “is assigned to” relationship (assignment) runs from a structure to a behaviour, a service or an access. The “realises” relationship (realisation) shows what makes a service, a requirement, an objective or an architecture state real; for example, the procedure “Assess benefit application” realises the public service “Family support benefit”.

Dependency relationships

The “serves” relationship (serving) shows that the source offers something the target uses. The “accesses” relationship (access) shows that the source reads or writes information; the optional “access mode” field gives the direction: read, write or readWrite.

The “influences” relationship (influence) shows that the source changes an intent, for better or worse, with an optional influence sign. The “depends on” relationship (dependsOn) connects elements from the technical layers APP, DEL, RUN, HST and OPS. The “is associated with” relationship (association) connects any two elements and is the most general link.

Dynamic relationships

The “triggers” relationship (triggering) shows that the source starts the target; both are behaviours or events, for example an incident (Incident) and the runbook (Runbook) that handles it. The “flows to” relationship (flow) shows that the source passes something to the target, for example data or documents.

Deployment and hosting

The “is deployed to” relationship (deployedTo) connects what is installed (a release, an artifact, a workload or a deployment) with the runtime context it is installed in. The “is hosted by” relationship (hostedBy) connects a cluster, a node, a managed service, a data store or a software system with the location or provider that hosts it.

Governance, legal basis and funding

The “has legal basis” relationship (legalBasis) connects an element from STR, LEG, ORG or INF with a legal resource (LegalResource) or a legal provision (LegalProvision). The “governs” relationship (governs) runs from a governance body, an interoperability agreement or a public policy to any element.

The “funds” relationship (funds) connects funding (Funding) with the programme or project it pays for. The “measures” relationship (measures) connects an indicator (Indicator) with an objective, a goal, a public service or a capability.

Risk and continuity

The “mitigates” relationship (mitigates) connects a protective measure with the threat it reduces. The “affects” relationship (affects) connects a disruption scenario, an incident, a vulnerability or a risk with the exposed elements: structures, behaviours, services, accesses or stores. A dataset is not a permitted target, because it is information; the data store that keeps it is.

The “falls back to” relationship (fallsBackTo) shows which alternative a public service, a channel or a procedure switches to when it does not work normally. The “is restored after” relationship (restoresAfter) gives the order in which elements return after a disruption: the source is restored after the target. restoresAfter relationships do not form a cycle.

Links in specialised contexts

Besides the 21 relationship types, the editor creates typed links in specialised contexts, for example for runtime, hosting and operations. The application does not keep them as relationships, but in element fields or helper types. For example, the monitor “Benefit availability monitor” observes the software system “Benefits case platform” through the observes link.

On detail sheets, tools are linked through detail relationships (DetailRelationship), for example BPMN sequence flows. The ends of a detail relationship are two different tools on the same sheet.

Validity of relationships

The editor does not create a relationship that is not permitted. Validation reports as an error an invalid relationship that appears some other way, for example in a file edited outside the application. Workspace settings narrow the built-in rules, but cannot permit a relationship the language forbids.

Relationship table

For each type, the table gives the wording, the line and the ends it is drawn with. The target end sits next to the target element and the source end next to the source element.