The everything-view, again

In an earlier post I argued that there is no useful audience-independent architecture view: A diagram detailed enough to be useful has picked an audience, and the answer is one model with many audience-specific projections.

The 3D scene is the everything-view in its most seductive form. It jams three structural views (context, functional, information) and at least two cross-cutting perspectives (security, data quality) into one artifact. This is precisely the over-loaded drawing the architecture-description discipline exists to avoid. The fact that you can rotate it does not change what it is.

But suppose you disagree with the premise. The track record makes the case on its own.

The track record

CodeCity [1] is the canonical software city: classes as buildings, building height and footprint mapped to metrics, packages as districts. It is the best-executed version of the idea, and, rare for this genre, it was properly evaluated. A controlled experiment with participants from both academia and industry [2] found real but task-specific benefits over the baseline tooling of the time.

This is the strongest result 3D software visualisation has ever produced: positive, peer-reviewed, and honest. Durable industrial adoption still did not follow. Twenty years of papers, prototypes, and conference demos later, no software city is part of any mainstream development workflow.

Vizceral [3] is the more instructive case, because it is the flowing-particle traffic view which actually shipped and actually worked. Netflix used it in production traffic operations. Two details matter: First, its layout is 2D. WebGL is just the renderer, used for particle throughput, not for a third axis. Second, it is scoped to a single concern: traffic flow and hotspots. One view, one audience, one question. This is exactly the discipline that earlier post argued for, and even so, Netflix has since stopped using it internally and stopped active maintenance.

The tool which came closest to the dream succeeded by abandoning both the third dimension and the everything-view ambition.

The perceptual argument

The deeper reason is older than any of these tools. Cleveland and McGill measured how accurately people decode visual encodings [4] , and the ranking has held up for forty years: Position on a common scale is the strongest encoding we have. Length and angle follow. Depth and volume sit near the bottom.

A 3D scene spends its budget exactly backwards. It takes the strongest encoding, 2D position, and degrades it through perspective projection, while adding information on the weakest channels. On top of that come the practical costs anyone who has navigated a 3D scene knows:

• Occlusion: Things hide behind other things, and what is hidden is invisible instead of merely distant.

• Navigation cost: Finding a known element means flying through the scene instead of glancing at a drawing. You constantly have to maintain your orientation instead of getting it for free.

• An arbitrary Z axis: Architecture has no natural third dimension, so the axis encodes either nothing or a metric which would be clearer as color or size.

• Label degradation: Architecture diagrams are mostly labels, and labels in a perspective scene are skewed, scaled, or billboarded into clutter.

This is why the surviving tools in the space, like service maps in APM products, Kiali, or Honeycomb-style trace views, all converged on 2D with pan and zoom. Position stays trustworthy, labels behave, and orientation is free.

WebGL availability changes none of it. The bottleneck was never the GPU. It is the visual cortex, and that has not had a major release in quite a while.

Conclusion

The 3D scene still has its place, though. It photographs beautifully. As a demo at a project presentation, on a conference slide, or as a recruiting artifact it communicates something true ("this system is alive, data is flowing") to an audience which needs exactly that impression and nothing more.

What it must not become is something anyone relies on for architecture work. The documentation standard stays 2D, per audience, projected from one model. The dancing particles are marketing. And marketing, to be fair, is also a stakeholder with concerns.

And I still might implement it, because I'm just too tempted to create something beautiful, even knowing it'll be a failure.

References

1

Wettel, R. & Lanza, M. (2008). "CodeCity: 3D Visualization of Large-Scale Software." ICSE 2008 (tool demo); the city metaphor first appeared in "Visualizing Software Systems as Cities," VISSOFT 2007.

2

Wettel, R., Lanza, M. & Robbes, R. (2011). "Software Systems as Cities: A Controlled Experiment." ICSE 2011.

3

Netflix (2016). Vizceral. github.com/Netflix/vizceral. WebGL-rendered, 2D-layout animated traffic graphs; no longer actively maintained.

4

Cleveland, W. S. & McGill, R. (1984). "Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods." Journal of the American Statistical Association 79(387), 531–554.