Tool Alternatives

Ilograph alternative: keep the perspectives, stop hand-writing the model

By the engineer who builds Datadef, from client work on data platforms · Reviewed August 21, 2026

Ilograph is one of the more thoughtful diagramming tools in the category. It separates resources from perspectives, so one tree of components can be shown as a network view, a data flow, a security path, or a sequence, without duplicating the components in four files. The authoring experience is fast, with autocomplete and a diagram that updates as you type. The open question is the same one every model-based tool faces: who keeps the YAML honest.

Try it free
6 min readFor teams maintaining Ilograph YAML for a system that changes weekly

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

146/2000• 3 credits left
Try:

No account needed · Editable canvas, not a picture

The perspective model is genuinely good design

In Ilograph the source has two halves. The resources section declares components as a tree of parents and children. The perspectives section declares how those components relate, either as a relation perspective or as a sequence perspective. Every diagram is a view of the same resource tree, which means a component is described once and appears correctly in every view.

That structure earns its keep on distributed systems, where the interesting thing is rarely the box list and almost always the path: how a request travels, which hop crosses a trust boundary, what happens when the cache is cold. Contexts, autocomplete, automatic layout, and interactive highlighting make the authoring loop pleasant, and the result runs in the web app, in a desktop application, and inside Confluence Cloud through the marketplace app.

Where the hand-written model gets expensive

The resource tree is typed by a person, and the perspectives multiply the consequences of that. One mistake in the model shows up in every perspective at once, and one missing component is missing from all of them. The elegance that keeps the views consistent also keeps them consistently wrong when the underlying system moves.

Nothing in the tool reads a repository or a cloud account, so there is no signal that a component was removed or that a new dependency was introduced. The YAML is exactly as current as the last editing session, and the editing sessions get rarer as the system gets bigger, which is the wrong direction.

The edit itself is small, which is exactly why it does not happen. Adding one cache to a running system is a Terraform block, a Helm value, and then, somewhere else entirely, these lines.

resources:
- name: Platform
  children:
  - name: orders-api
  - name: orders-db
  - name: orders-cache      # added by hand, after somebody notices

perspectives:
- name: Network
  relations:
  - from: orders-api
    to: orders-db
  - from: orders-api        # added by hand, in the right perspective
    to: orders-cache

Generating the resource model from the code

Datadef connects to a repository on GitHub, GitLab, or Azure DevOps with a read-only token, tracks one branch or tag per diagram, and generates the architecture from the files that define the system: infrastructure as code, containers and orchestration, schemas and dbt models, API specs, CI pipelines, and manifests. A daily sync regenerates the diagram and an architecture.md when the code moves.

The canvas supports the structural parts you would expect from a model-based tool: zones for boundaries, real icons on the nodes, labelled edges for what actually flows, and column-level lineage when the subject is data rather than services. It is one canvas per diagram rather than N perspectives over one tree, which is the real difference in expressiveness.

The closest counterpart to a second perspective is a second diagram on the same connection, and it is not only a different crop. One connection can back several diagrams, each tracking its own branch or tag and each choosing what gets read. The architecture focus pulls infrastructure and orchestration to the front, with ceilings of 16 infrastructure files and 14 Kubernetes manifests against 3 dbt models; the content focus inverts that, reading up to 18 dbt models and 14 SQL files while sampling infrastructure three files deep. Two diagrams of one repository can therefore be different readings of it. What they are not is views onto a shared resource tree: each canvas is its own object, and renaming a component on one does not rename it on the other.

For Confluence, where a lot of Ilograph output ends up, there is a live embed: the page shows the current diagram without a plugin, an export step, or a viewer account.

Choosing between them

If the value you need is several narratives over one model, sequences included, Ilograph is more expressive than a generated canvas and this is not a close call. If the value you need is that the picture is right on the day someone opens it, generation wins, because it removes the human step that keeps failing.

A reasonable split for a large system: generate the as-built view from the repository so onboarding and incident response start from something true, and hand-author the two or three narrative perspectives that matter enough to maintain deliberately.

FAQ

Does Datadef support multiple perspectives over one model?

Not in the Ilograph sense. One repository connection can back several diagrams, each on its own branch or tag and each reading a different slice of the files, but every diagram is its own canvas rather than a view onto a shared resource tree. A system that genuinely needs several formal perspectives is better served by a perspective-based tool.

Can a generated diagram be embedded in Confluence?

Yes, and without the marketplace app route. A live embed is an image URL, so a Confluence page renders the current diagram through a normal image macro, no plugin to install and no viewer account for the reader. The image follows the canvas, so each repository sync updates the page without anyone editing it.

How is the model kept current?

It is regenerated rather than edited. A daily sync re-reads the connected branch or tag and rebuilds the diagram and the architecture doc. Each run first hashes the structure that feeds the diagram, so a commit that changed only prose or tests regenerates nothing. Manual refresh and agent-triggered refresh over MCP are both available.

Is the generated diagram editable afterwards?

Yes, it lands on a normal editable canvas with zones, labelled edges, and icons. A node you drag keeps its position across later syncs, since anything more than 12 pixels from where the last sync left it counts as hand-placed, and nodes you add yourself are preserved. Labels and edges derived from the source are regenerated when the source changes.

Can data flows be shown at column level?

Yes, for data architecture. Lineage can be drawn column to column between tables and models, which is a level of detail service-oriented diagrams usually leave out, and it is the case where a repository read leans on dbt models, SQL DDL, and schema files rather than on infrastructure code.