Practitioners who have learned EDGY apply it to real enterprise challenges, often alone, inside organisations that do not share the language. The language is accessible enough that a committed practitioner can start using it within weeks of a course. The books, the wiki, and the webinars carry the theory well.

Two symptoms recur predictably once the language is learned. The first is maps the practitioner understands perfectly but nobody else in the room reads. The second is tools — ArchiMate repositories, Confluence wikis, Miro boards, BPMN diagrams, Visio artefacts — that resist EDGY integration and silently push the practice back toward whatever vocabulary the incumbent tool enforces.

Neither of these is a knowledge gap. They are application gaps. The practitioner knows the theory. What they need is focused feedback on a specific artefact in a specific organisational context.

Intersection Group coaching exists for exactly this layer of practice. Sessions are 60 minutes, remote, and targeted at a single case or artefact. Three coaching formats are offered: Map Lab for map clarity, Tool Tuning for workflow integration, and Case Clinic for scope that will not settle. Two of these, Map Lab and Tool Tuning, address challenges the Intersection record explicitly documents. Recognising which kind of stuck you are in is the first step; booking the right session is the second.

Two observations support this conclusion:

• Map Lab addresses the problem of maps that are clear to their maker but unreadable to their audience.
• Tool Tuning addresses the problem of tools that resist the practice rather than supporting it.

Map Lab: when your maps do not communicate

Maps are not deliverables. Maps are shared instruments. Tools for a group of people to hold the same picture in their heads at the same time. A map that its maker can read but its audience cannot is not a map; it is a personal diary with diagrams.

Four talks from the Intersection record describe exactly this challenge, each from a different angle.

• Katharina Weber (Intersection 16, Copenhagen): Customer Journey Maps as a Tool for Continuous Improvement.
  Weber's argument is that customer journey maps fail when they are built as one-off deliverables for a specific project. They succeed when they are designed to sustain ongoing improvement, which means they must be readable by the team that inherits them, not just the team that made them. Map durability is a map-design problem.
• Natacha Hennocq (Intersection 16, Copenhagen): Multi-platform search for Orange entertainment services.
  Hennocq introduces the cognitive-science argument for collaborative mapping. Drawing on the concept of dead reckoning — the biological mechanism by which humans calculate their position in an environment — she argues that teams need shared maps for the same reason travellers do: to know where they are. When teammates build maps together, they align their mental models; when they consume maps made by others, they inherit the maker's assumptions without knowing they have done so.
• Nick Tune (Intersection 23, Vienna): Sustainable software development with collaborative domain modeling.
  Tune presents the terminology mismatch map — a visualisation technique for surfacing exactly where business vocabulary and technical vocabulary use the same words to mean different things. One of his examples, from an American bank, shows the word sponsor meaning one thing in business conversation and something else in the code, while the word the business called program had no equivalent in the codebase at all. The map's function is not decoration. It makes the misalignment visible so the team can address it.
• Jean-Sébastien Daigle (Intersection 24, Rome): Easy to use, hard to master: How to navigate EDGY.
  Daigle argues that a single map rarely does the job. Practitioners need multiple maps at different zoom levels, the way a traveller needs a universe view, a continent view, a city view, and a street view. A map that tries to serve all zoom levels at once serves none of them. Daigle's talk is the most practical public treatment of how EDGY practitioners should think about map granularity.

Across these four talks, the common claim is structural: a map is designed for its readers, not for its maker. Most map problems are design problems. The practitioner who makes the map is rarely the best judge of whether the map is working, because they know what the map is supposed to say. A Map Lab session supplies what the solo practitioner cannot supply for themselves — a reader who is willing to say I cannot follow this, and here is where the design breaks down.

Tool Tuning: when your tools resist your practice

Practitioners rarely work in a clean EDGY-only environment. They work inside organisations with incumbent tooling: enterprise architecture repositories, BPMN diagramming suites, Confluence wikis, Miro whiteboards, Excel trackers, Visio artefacts from earlier strategy cycles. Each tool enforces a vocabulary. Each tool was designed for a different practice. None of them were designed for EDGY specifically.

Two talks separated by seven years document this problem and its evolution.

• Guro Røberg, Kuno Brodersen & Yorai Gabriel (Intersection 17, Barcelona): Enterprise Design Tools.
  The panel named the problem explicitly: "disparate islands of knowledge — in Paint, Visio, Excel, Word, PowerPoint — are insufficient for decision-making in mid-to-large-sized organisations." Brodersen introduced the Three C's framework — Coherence, Collaboration, Consistency — as design criteria for what enterprise-design tools should achieve when integrated properly. Gabriel, in the same panel, enumerated six characteristics of effective diagrams as thinking tools: Simple, Scalable, Sustainable, Communicative, Information-Rich, Iterative. Seven years later, those six characteristics remain a practical checklist for evaluating any artefact a practitioner produces in any tool.
• Rudi Claes (Intersection 24, Rome): Modeling a composable architecture with EDGY.
  Claes updates the Tool Tuning story for the current generation. He built a free Sparks and ArchiMate plugin for native EDGY modelling, designed to coexist with BPMN and other modelling languages that an enterprise already uses. His positioning statement makes the Tool Tuning stance explicit: "composable architecture is a lot more about the people and the process and almost nothing about the actual tooling." Which is to say, the tools should adjust to the practice, not the other way around.

The pattern across both talks is consistent. Tool problems are not solved by tool replacement. They are solved by aligning the tool's vocabulary and outputs with the practice's vocabulary and needs, one workflow at a time. A Tool Tuning session is that alignment work, applied to a specific tool in a specific organisational context, with a coach who has done it before.

Your next step

If you recognised one of the two patterns in your own work, the matching coaching session is the next step.

Book a Map Lab session if your maps are not earning their rent. If people in the room nod politely but do not use what you have drawn, or if you have inherited a map the team cannot read, or if your maps work at one zoom level but fail at another.

Book a Tool Tuning session if your tools are fighting your practice. If your EDGY work is quietly being reshaped by the vocabulary of a repository you did not choose, or if you are integrating across Miro, ArchiMate, Confluence, and a BPMN tool without a clear principle for which does what.

Both formats are 60-minute remote sessions with experienced EDGY practitioners. You can book a session here.