Overview

Topology, presented as System Graph in the Zof Console, provides a dependency-aware view of applications, services, integrations, and change impact. Teams use topology to answer what exists, how systems connect, what changed recently, and what should be tested before shipping.

Unlike static architecture diagrams, topology in the Console connects to operational metadata: team ownership, recent validation outcomes, linked projects, and risk signals. This integration supports impact analysis during release planning and incident response.

Accurate topology is a shared responsibility between platform teams maintaining registrations and service owners confirming dependency edges reflect production reality.

Who should read this

SREs, architects, release managers, and QA leads planning validation scope from dependency knowledge.

Prerequisites

Applications and services registered in the Zof Console with team ownership
Integration connections supplying dependency metadata where available
Permission to access Platform → Topology

When to use this workflow

Onboarding new team members to Zof terminology and workflows
Authoring internal runbooks aligned with Console labels
Designing CI/CD or webhook integrations against documented behavior

Step-by-step procedure

Open the System Graph

Navigate to Platform → Topology in the Zof Console.

Select the organizational scope or application cluster relevant to your analysis.

Familiarize yourself with graph layout controls, filtering, zoom, and focus on subgraphs.

Validate node accuracy

Confirm registered applications and services match your current architecture inventory.

Identify orphaned nodes representing decommissioned systems still visible in the graph.

Work with service owners to add missing components before relying on graph for release decisions.

Review dependency edges

Inspect caller and callee relationships between services, APIs, and shared infrastructure.

Question edges that appear stale after recent architectural migrations.

Document critical paths, checkout, authentication, payment, that span multiple nodes.

Assess change impact

Highlight nodes affected by a planned deployment and traverse downstream dependencies.

Expand validation suites to cover impacted consumers not directly modified by the change.

Share impact summaries with release managers and dependent team leads.

Link topology to validation planning

Map dependency paths to existing test coverage in Coverage and the test library.

Create or schedule runs targeting high-impact subgraphs before gate evaluation.

Record topology-informed test decisions in release readiness documentation.

Maintain topology over time

Schedule quarterly topology reviews aligned with architecture governance cadence.

Update registrations when services split, merge, or change ownership.

Incorporate topology gaps discovered during incidents into backlog remediation items.

Key concepts

Organization scope: All Zof Console and API operations are isolated to your authenticated tenant.
Governed execution: Agent output and remediation follow policy packs with human approval when configured.

Best practices

Assign topology stewardship to a platform or architecture team with escalation to service owners.
Use consistent naming between topology nodes and application records in the Console.
Combine topology analysis with risk assessment, not either alone, for release decisions.
Integrate topology review into change advisory board templates for medium and high blast-radius changes.
Capture topology snapshots or exports for major release postmortems when dependency assumptions fail.

Common issues

Graph appears sparse or empty: Insufficient application registration or integration metadata. Begin by registering core services and enabling supported integration dependency feeds.
Incorrect dependency direction: Manual edge corrections may be required when automated discovery misinterprets call patterns. Validate critical edges with service owners.
Topology outdated after rearchitecture: Major migrations require explicit cleanup of retired nodes. Treat topology debt as operational risk alongside test coverage debt.