The architecture review board has a network graph. It was built from the CMDB eighteen months ago, manually updated three times since, and now shows 847 nodes and 2,200 edges in a force-directed layout where every node overlaps every other node and no useful pattern is visible at any zoom level. The diagram exists. It communicates nothing. Someone exports it to Visio every quarter, the export takes forty minutes, the result is sent to a folder where it lives alongside the previous seven exports that nobody opens either. The portfolio is undocumented not because nobody drew the diagram but because the diagram nobody can read is functionally equivalent to no diagram at all.
A dependency wheel, a circular chord diagram where applications or programs are arranged on the perimeter of a ring, and dependencies are drawn as arcs connecting them through the interior, solves a specific problem that force-directed graphs, hierarchical trees, and dependency matrices all fail at: showing the full dependency structure of a large portfolio at once, in a format where coupling density, bidirectional relationships, and high-fan-in components are immediately visible as visual patterns rather than requiring navigation, filtering, or manual inspection. At portfolio scale, the wheel is the diagram that is actually read rather than the diagram that is technically complete.
Build the Wheel Data First
SMART TS XL’s dependency graph is the structural foundation for dependency wheel visualizations that architecture review boards can actually read.
SCOPRI DI PIÙ…What a Dependency Wheel Is, and What It Is Not
A dependency wheel (also called a chord diagram, arc diagram, or circular dependency visualization) is a graph layout method where:
- Nodes (applications, programs, services, or components) are arranged around the perimeter of a circle
- bordi (dependencies) are drawn as curved arcs through the interior of the circle, connecting the two nodes the dependency links
- Arc width encodes coupling strength, a thicker arc between two nodes indicates a stronger dependency (more function calls, more data flow, more shared components)
- Arc direction encodes dependency direction, the arc originates from the dependent node and terminates at the dependency
The result is a diagram where the coupling structure of the entire portfolio is visible simultaneously. High-fan-in nodes, the shared infrastructure that many applications depend on, appear with many arcs converging on a small perimeter segment. Isolated clusters appear as groups of nodes whose arcs stay within a local region of the wheel. Circular dependencies appear as bidirectional arcs between node pairs or as closed arc loops.
What a dependency wheel is not:
Not a network graph. A force-directed network graph positions nodes based on spring-force physics. It is good for small graphs (under 100 nodes) and poorly suited to large ones, where node overlap makes patterns invisible. The wheel format fixes node positions on the perimeter, preventing overlap regardless of graph size.
Not a dependency matrix. A dependency structure matrix (DSM) encodes the same information in a grid format, rows and columns represent components, cells represent dependencies. The matrix is precise and sortable but not intuitively readable: pattern recognition from a 500×500 matrix requires training that pattern recognition from a wheel does not.
Not a hierarchical tree. Tree layouts show parent-child relationships but cannot represent cross-branch dependencies without visual clutter. Application portfolios have many cross-domain dependencies, a billing service that depends on an authentication service that depends on an LDAP directory that is also used by HR, that trees represent poorly.
The wheel’s advantage is specifically in the combination of scale and readability: it can represent hundreds of nodes and thousands of edges in a single view where architectural patterns are directly visible without navigation.
Why Wheels Work Better Than Network Graphs at Enterprise Scale
The readability problem with network graphs at enterprise scale is geometric, not aesthetic. A force-directed graph with 500 nodes and 3,000 edges has no stable layout. The spring forces that position nodes relative to their neighbors produce different layouts on every render depending on initial conditions. At 500 nodes, the minimum edge crossing count is computationally intractable, the layout algorithm finds a local minimum, not the global minimum. The result is a diagram where the structure of the graph is obscured by the layout algorithm’s limitations.
The wheel avoids this by making a deliberate trade-off: it sacrifices layout freedom in exchange for positional stability and visual clarity. Every node is on the perimeter. The only visual variable is the arc, its width, direction, and curvature. This constraint, which looks like a limitation, is what makes the wheel readable at scale.
Three specific advantages over network graphs at enterprise portfolio scale:
Coupling density is immediately visible. A node whose perimeter segment is dense with arc origins or destinations, where many arcs begin or end at a small arc of the circle, is a high-coupling node. No navigation is required to identify it. In a force-directed graph, a high-degree node may be visually centered (force-directed layouts pull highly connected nodes toward the center) but the degree is not encoded in any visual property that is immediately apparent at glance.
Bidirectional dependencies are distinguishable. In a force-directed graph with directed edges, the arrow direction is readable only when zoomed in to individual edges. In a wheel, bidirectional dependencies between two nodes, where A depends on B and B also depends on A, appear as two arcs crossing in the interior, forming an X pattern that is visible at any zoom level. Circular dependencies at the application level are a significant architectural risk; the wheel makes them structurally detectable.
Clusters are spatially apparent. When nodes are sorted by domain, team, or functional area on the perimeter, clusters of tightly coupled nodes within a domain appear as arcs that stay in a local region of the wheel interior. Cross-domain dependencies appear as arcs that cross the center. The ratio of local arcs to center-crossing arcs in any region is a visual measure of that domain’s cohesion and its coupling to other domains.
How to Read a Dependency Wheel: Five Patterns
Pattern 1: The Hub Node
A node whose perimeter segment is the origin or destination of a disproportionate number of arcs. In a portfolio wheel, hub nodes are shared infrastructure, authentication services, core databases, utility libraries, shared COBOL copybooks, that many other components depend on.
Cosa significa: The hub node is a single point of failure for every component that has an arc terminating at it. It is the highest-priority target for redundancy investment, the highest-risk component for change management, and the most important component to migrate correctly (and first) in any modernization sequence.
Cosa fare: Identify hub nodes before change control decisions are made. A proposed change to a hub node requires impact analysis across every arc that terminates at it, the wheel makes the scope of that impact visible at a glance.
Pattern 2: The Isolated Cluster
A group of nodes whose arcs stay entirely within a local region of the wheel, with few or no arcs crossing into adjacent regions. The cluster is internally coupled but externally independent.
Cosa significa: Isolated clusters are strong modernization candidates. Their bounded dependency scope means they can be migrated, replaced, or retired as a unit without requiring simultaneous changes to the rest of the portfolio. The Strangler Fig pattern is directly applicable to isolated clusters.
Cosa fare: Identify isolated clusters and migrate them as the first waves of an incremental modernization program. Starting with isolated clusters builds experience, produces early business value, and reduces the legacy portfolio without touching the tightly coupled core.
Pattern 3: The Bidirectional Arc Pair (Circular Dependency)
Two arcs between the same pair of nodes, crossing in the interior. Node A depends on node B, and node B depends on node A. In a more complex variant, a closed loop of arcs connects three or more nodes in a circular chain.
Cosa significa: Circular dependencies prevent independent deployment. If A and B must both be updated when either changes, they cannot be deployed independently. They have an implicit coupling stronger than any documented interface, they share state or behavior in a way that makes them operationally inseparable despite being architecturally separate.
Cosa fare: Document and address circular dependencies before modernization planning. Resolving circular dependencies typically requires extracting the shared state or behavior into a third component that both original components depend on, eliminating the circularity.
Pattern 4: The Dense Central Region
The interior of the wheel is dense with crossing arcs, many arcs from many parts of the perimeter converge toward the center and cross each other. No clear routing pattern is visible.
Cosa significa: The portfolio has high average coupling with few natural domain boundaries. This pattern typically indicates a “big ball of mud” architecture where historical development added integration without architectural governance. The portfolio is resistant to incremental decomposition because there are no isolated clusters to extract.
Cosa fare: Perform a clustering analysis on the dependency graph to identify the minimal number of component groups that have the fewest cross-group dependencies. Restructure the wheel with nodes sorted by the identified clusters to confirm whether any natural boundaries exist. If none do, a big-bang replacement of the core may be the only viable modernization strategy.
Pattern 5: The Sparse Perimeter Region
A region of the wheel perimeter that has few arcs connecting it to the rest of the wheel. The nodes in this region have low coupling to the rest of the portfolio.
Cosa significa: These components are candidates for retirement or replacement. Low coupling means few other components depend on them. If they also have low business value or high technical debt, retirement without replacement is likely appropriate. Dead code analysis, identifying which of these components have no active callers from any production execution path, confirms the retirement candidate status.
Cosa fare: Run dead code analysis on sparse perimeter nodes. Nodes with zero inbound arcs from production execution paths are dead code, remove them from the portfolio and exclude them from modernization scope.
Building the Data: From Source Analysis to Chord Diagram
A dependency wheel is only as accurate as the data it is built from. The data requirement is a dependency matrix: for each pair of components in the portfolio, whether a dependency exists and how strong it is. This data must come from structural analysis of the actual code, not from documentation, CMDB records, or developer interviews.
The data structure required for a D3.js chord diagram:
javascript
// D3 chord diagram data format
// matrix[i][j] = strength of dependency from component i to component j
// 0 = no dependency
// Positive integer = coupling strength (call count, include count, data flow volume)
const portfolioMatrix = [
// CUSTPROC TRANPROC ACCTMGR RPTGEN AUTHSVC
[ 0, 45, 12, 0, 8 ], // CUSTPROC
[ 0, 0, 28, 0, 8 ], // TRANPROC
[ 0, 0, 0, 15, 8 ], // ACCTMGR
[ 0, 0, 0, 0, 0 ], // RPTGEN
[ 0, 0, 0, 0, 0 ], // AUTHSVC
];
const componentNames = [
"CUSTPROC", "TRANPROC", "ACCTMGR", "RPTGEN", "AUTHSVC"
];
// Arc widths scale with matrix values
// AUTHSVC appears as a hub: many non-zero values in its column
// RPTGEN appears as a sink: non-zero values in its row onlyThe matrix values come from the dependency analysis of the actual codebase:
- Per CALL relationships: count the number of CALL statements from each program to each other program
- Per COPY relationships: count the number of programs that include each copybook
- Per data flow relationships: count the number of programs that read from or write to each shared dataset
- Per API relationships: count the number of API calls from each service to each other service
A COBOL portfolio’s dependency matrix is built from three analysis inputs: the CALL graph (which programs call which other programs), the COPY graph (which programs include which copybooks), and the data flow graph (which programs access which shared datasets). Together these three graphs produce the complete coupling picture that the chord diagram requires.
bash
# Pseudocode: extracting dependency matrix data from COBOL static analysis
# Each row: SOURCE_PROGRAM, TARGET_PROGRAM, DEPENDENCY_TYPE, STRENGTH
CUSTPROC -> TRANLIB CALL 12 # CUSTPROC calls TRANLIB 12 times
CUSTPROC -> CUSTMSTR COPY 1 # CUSTPROC includes CUSTMSTR copybook
CUSTPROC -> CUST.FILE DATA_READ 1 # CUSTPROC reads from CUST.FILE
TRANPROC -> TRANLIB CALL 8 # TRANPROC calls TRANLIB 8 times
TRANPROC -> CUSTMSTR COPY 1 # TRANPROC includes CUSTMSTR copybook
# ... one row per dependency across the full portfolioThe strength values determine arc width in the chord diagram. Normalizing these values, expressing them as a percentage of the maximum coupling strength in the portfolio, produces arcs whose relative widths communicate the relative coupling intensity accurately.
Five Enterprise Use Cases for Dependency Wheel Diagrams
Use Case 1: Modernization wave sequencing. Sort the wheel to cluster nodes by domain. Identify isolated clusters (few cross-cluster arcs) and sequence them as early migration waves. The visual pattern, which clusters are internally dense and externally sparse, directly corresponds to which clusters can migrate as independent units.
Use Case 2: Change impact communication. Before a change advisory board, show the dependency wheel with the proposed change target highlighted. The arcs connected to that node are the visual representation of the change scope, every component that must be tested, notified, or updated. No verbal explanation of “this component has 47 dependents” conveys the same information as an arc from 47 nodes converging on a single perimeter segment.
Use Case 3: Portfolio rationalization prioritization. Overlay technical debt scores (cyclomatic complexity, code age, defect density) on the node colors. Components with high technical debt scores and low fan-in (few inbound arcs) are rationalization targets, high cost to maintain, low risk to retire. Components with high technical debt and high fan-in are modernization necessities, high cost to maintain, high risk to leave unchanged.
Use Case 4: Acquisition portfolio integration analysis. After a merger or acquisition, combine the two organizations’ dependency wheels. The cross-organization arcs, connections between one organization’s applications and the other’s, are the integration points that must be managed during portfolio rationalization. Isolated clusters in either wheel that have no cross-organization arcs are candidates for retirement or consolidation without requiring cross-organization coordination.
Use Case 5: Business continuity planning. Hub nodes in the wheel are single points of failure. Nodes with the densest inbound arc concentrations represent the highest-priority targets for redundancy investment. The wheel provides the visual evidence for business continuity investment decisions, replacing verbal descriptions of criticality with a structural diagram that shows, simultaneously, which components every other component depends on.
The COBOL Portfolio: Where Dependency Wheels Have No Competition
The application portfolio visualization tools that produce dependency wheels, LeanIX, Virima, ServiceNow CSDM, discover dependencies through network traffic analysis, CMDB records, and API call monitoring. They produce excellent wheel visualizations for modern application portfolios where network traffic is the primary coupling mechanism.
They produce nothing for COBOL portfolios.
A COBOL batch program that calls twelve subprograms through CALL statements, includes fifteen copybooks through COPY directives, and reads from four shared VSAM datasets has a rich dependency structure that creates meaningful arc patterns in a dependency wheel. That structure is invisible to network traffic analysis because COBOL batch programs do not communicate through network protocols, they communicate through compiled call linkage, shared library datasets, and file system coupling. The only way to discover the dependency structure of a COBOL portfolio is to parse the source code.
The dependency wheel for a COBOL portfolio built from static source analysis reveals patterns that decades of CMDB maintenance and developer interviews have not surfaced:
Copybook hubs. A frequently included copybook, included by 200 COBOL programs, appears in the wheel as a node with 200 arcs converging on its perimeter segment. This pattern identifies the shared data structure that is the highest-risk change target in the portfolio. A change to this copybook requires coordinating 200 programs. The wheel makes this visible without requiring someone to know in advance that the copybook is widely shared.
Program clusters by business domain. When programs are sorted by their JCL job membership, which programs run in the same batch job stream, clusters of programs that interact primarily within a job stream appear as localized arc patterns. The arcs that cross cluster boundaries represent the data dependencies between job streams, the files produced by one stream and consumed by another.
Dead program islands. Programs with no inbound arcs, no other program calls them, no JCL job directly invokes them, appear as perimeter nodes with only outbound arcs or no arcs at all. These are dead code candidates. The wheel makes them visually distinct from the connected portfolio without requiring manual inspection of each program’s call graph.
Circular dependency loops. COBOL programs that call each other in a circle, a pattern that creates compilation ordering problems and logical coupling that makes testing difficult, appear as bidirectional arc pairs or closed arc loops. These architectural problems are rarely documented; the wheel surfaces them from the source structure.
Come SMART TS XL Provides the Dependency Data for Portfolio Wheels
A dependency wheel is a visualization layer. The layer requires accurate data, specifically, the complete dependency matrix for the portfolio, derived from structural analysis of the actual code rather than from documentation or network discovery.
SMART TS XL'S mappatura delle dipendenze delle applicazioni produces this matrix for COBOL, JCL, Java, Python, RPG, PL/I, and every other language in the environment. The output is the complete dependency graph: every CALL relationship (which programs call which), every COPY relationship (which programs include which copybooks), every data flow relationship (which programs access which shared datasets), and every JCL operational relationship (which job steps invoke which programs in which sequence).
This graph is the input to the dependency wheel visualization: each node in the graph becomes a node on the wheel’s perimeter, and each edge becomes an arc in the wheel’s interior, with arc width proportional to the coupling strength encoded in the edge weight.
Migliori analisi d'impatto capability makes the dependency wheel actionable: when a node is selected in the wheel visualization and its inbound arcs are highlighted, the impact analysis produces the structured list of every affected program, the data that supports change advisory board review, migration wave planning, and business continuity assessment.
Migliori analisi statica del codice capability adds the quality overlay: coupling the dependency graph with cyclomatic complexity, code age, dead code percentage, and technical debt metrics produces the colored dependency wheel where node color encodes technical health and arc width encodes coupling strength simultaneously. This combined visualization is what makes portfolio rationalization decisions evidence-based rather than opinion-based, the nodes that are both highly coupled and technically unhealthy are visible as the brightest-colored nodes with the densest arc concentrations.
Migliori ricerca aziendale capability makes the dependency wheel interactive in the operational sense: a user who clicks on a hub node in the wheel and asks “which programs include this copybook?” receives an answer in seconds. The wheel identifies the pattern; the search provides the enumerated list that the pattern represents.
For organizations building dependency wheel visualizations for presentation to architecture review boards, technology leadership, or board-level risk committees, SMART TS XL provides the structural analysis that makes the wheel accurate, the difference between a diagram that represents the actual portfolio and a diagram that represents what the CMDB thought the portfolio looked like eighteen months ago.
The Diagram That Is Actually Read
The failure mode of enterprise architecture visualization is not the absence of diagrams. It is the production of diagrams that exist and are not used, because they are too complex to read at the scale they were built for, because they are too stale to trust for the decisions they were built to support, or because they encode information in a format that requires navigation and filtering before any pattern is visible.
The dependency wheel succeeds where force-directed graphs fail at enterprise scale because it makes structural patterns, hub nodes, isolated clusters, circular dependencies, dense cores, visible as spatial and visual properties of the diagram rather than as emergent properties that require searching. The portfolio’s coupling structure is visible at a glance. The decisions that depend on that structure, migration sequencing, change impact scoping, rationalization prioritization, business continuity planning, can be grounded in the visual evidence rather than in narrative descriptions of a structure that the audience cannot see.
For COBOL and mainframe portfolios specifically, the dependency wheel built from static source analysis is the only visualization that represents the actual coupling structure, the one that exists in the code and the copybooks and the JCL, not the one that the CMDB’s network discovery could reach. That accuracy is what makes the diagram useful rather than merely present.
