Experience with "Upstream / Downstream" wording in CSDM and Playbooks

[Niclas]

Hi Community,

I’d like to raise a terminology observation that I keep encountering when working across CSDM, CMDB Unified Map, Query Builder and Get Well Playbooks.

One of the core goals of CSDM is to establish a common, shared language that is understandable across roles — from technical teams to service owners and business stakeholders. In practice, however, the terms “upstream” and “downstream” are used with different meanings depending on context.

CMDB / Unified Map / Query Builder

• Upstream describes relationships moving toward higher‑level abstractions, ultimately reaching the business layer.
• Downstream describes relationships moving toward lower‑level, increasingly granular technical components.

Get Well Playbooks

• Upstream causes refer to governance or data quality issues.
• Downstream consequences refer to the resulting business impact.

While both interpretations are valid in isolation, using the same terminology for different mental models (structural dependency vs. cause‑and‑effect) can be confusing in practice — especially for:

• newcomers to CMDB / CSDM
• non‑native English speakers

This can lead to situations where the same business impact is considered “upstream” in Query Builder but “downstream” in a Get Well Playbook, which feels counter‑intuitive when CSDM aims to simplify and standardize communication.

A concrete real‑world example illustrates this ambiguity:

Imagine a Application Service Instance is experiencing an outage.

From the perspective of the Get Well Playbook  Application Services with Business Service Offering Relationship perspective, the resulting business impact is described as a downstream consequence, as incidents and changes are unaware of business impact originating from the affected Application Service.

However, when analyzing the same situation in CMDB Unified Map or Query Builder, an Incident Manager would identify the Business Service impact by following resp. building an upstream relationship from the affected CI (Service Instance), since the Business Service Offering structurally depends on the Service Instance, which in turn runs on the underlying Server.

In practice, this means the same business impact is referred to as downstream in one context and upstream in another.

I’m curious whether others have faced similar challenges — particularly when learning CSDM concepts or preparing for CIS‑DF training — and whether clearer terminology or additional contextual guidance could help reduce this ambiguity?

Personally, encountered this ambiguity while preparing with the official MeasureUp practice exam, where identifying business impact indicated "downstream" in a Playbook-related question and "upstream" in a Query Builder related one, which was initially confusing. 

Thanks!

This post was written with help of Gen AI, did some edits after posting...

[CMDB Whisperer]

Well said!  If I could give you more kudos I would.  This is a pet peeve of mine and I have encountered multiple people in IT who encounter cognitive dissonance when these terms are used.  Yet they are used so often that it becomes hard to avoid using them, even for someone who knows they are problematic! 

I find the operational usage, i.e. the usage in Get Well Playbooks, to be more rational.  This is because a stream only flows in one direction, no matter what the mental model.  In the Get Well Playbooks, it is clear what is "flowing" down this stream: impact.  But in the dependency usage, i.e. that applied in the various dependency maps, it's not clear what is actually "flowing" or what the "stream" is.  Generally speaking, "upstream" refers to the source state of origin and "downstream" refers to the final state.  If you look up definitions elsewhere most seem to support this as the accepted usage of the terms.  Even in IT, it is used more often to describe the flow of data or computing to the application that consumes it, which supports the operational definition.

In contrast, the relationship from an Application or Service to its computing or data processing CIs would be better described as more of a parent-child or other hierarchical terminology than a flow-based terminology.  I don't have the perfect answer here, but it would be great if we could get past this inherently confusing terminology with a better, more appropriate terms to distinguish between dependencies and flow.  If we're using terms that are there only to define direction, but that direction is ambiguous, why use the terms at all?!