Skip to content

PATTERN Cited by 1 source

Visual graph for business-engineering alignment

The pattern

When designing a data model that must be co-authored by engineers and non-technical domain experts, use an auto-generated graph visualisation as the primary communication artifact, rather than SQL DDL, spreadsheets, or ER diagrams.

The business concepts (Address, Business Partner, Product), their attributes, and their relationships are rendered as nodes and edges in a graph visualisation (e.g. Neo4j's browser). Both engineers and domain experts can read the same diagram. Engineering handoff happens at the graph, not at the schema.

Why it works

  1. SQL DDL gatekeeps understanding. Non-technical domain experts don't read SQL — but they own the business semantics that the schema must encode. Zalando names this as one of the core MDM drawbacks: "for business stakeholders that are domain experts the understanding of contents and how they relate to each other is hard to grasp from these technical definition files" (sources/2021-07-28-zalando-knowledge-graph-technologies-accelerate-and-improve-the-data-model-definition).
  2. Spreadsheets lose relationship structure. Columns-of- tables formats flatten the graph. "Has contact", "belongs to", and cardinality are implicit; the audience must mentally reconstruct them.
  3. ER diagrams are authored, not generated. They drift from the actual model. A graph rendered from the same data that drives schema generation is always consistent with the live artifact.
  4. Graph visualisations are self-explanatory for small models. At tens of concepts and hundreds of attributes, a node-edge diagram is more compact and more readable than the equivalent table-of-tables.

Concrete shape at Zalando

  • The knowledge graph of System / Table / Column / Concept / Attribute / Relationship nodes is stored in Neo4j.
  • Neo4j's browser renders the graph. Legend colours classify node types; node counts per type are displayed in parentheses ("the number in brackets in the colour legend is the total amount of nodes of this type in the knowledge graph").
  • Domain experts review the rendered graph to confirm business-concept coverage + mapping correctness. Engineers review it to confirm the structural match with source system columns.
  • Outcome named by Zalando: "The dialogue between business and technology in designing the golden record logical data model has improved and accelerated the process of creating a correct model."

When to reach for this pattern

  • Any MDM project — domain experts are load-bearing contributors.
  • Enterprise data-integration platforms where domain models span org boundaries and must be discussed across teams.
  • Schema-design activities where the target is small enough (tens of entities, hundreds of fields) for a graph visualisation to remain readable.

Trade-offs

  • Scale ceiling. Beyond a few hundred nodes, graph visualisations become hairballs. Partitioning / filtering / per-concept views become necessary.
  • Requires a pre-existing graph substrate. If you have to build the graph solely for viz, the cost-benefit breaks down. The pattern pairs naturally with patterns/knowledge-graph-for-mdm-modeling, where the graph is already the authoring substrate.
  • Layout quality matters. Tools that can't auto-layout cleanly produce diagrams that look worse than a good ER diagram. Zalando's explicit reason for choosing Neo4j was "best look-and-feel", not query-path semantics.

Seen in

Last updated · 476 distilled / 1,218 read