The ask behind the ask
An insurance company came to us with a straightforward request: ArchiMate training in Sparx EA for a mixed group — six architects, a handful of senior analysts, and two people from the IT strategy office. They had licences, they had a repository that was mostly empty, and they had a modelling standard on paper that said ArchiMate 3.x without anyone having fully adopted it.
The first conversation surfaced the real problem, as first conversations usually do. Two years earlier, most of the group had attended a certified ArchiMate course. Everyone passed. Almost nobody had modelled since. The course had taught the language as a language — thirty-odd concepts, eleven relationship types, layer by layer, with examples about a fictional coffee company — and the group had returned to work fluent in a vocabulary they had no sentences for. The standard existed, the tool existed, the knowledge nominally existed, and the repository stayed empty.
So the engagement we actually proposed was not a course. It was a modelling programme built entirely on one of their own live questions, with the notation introduced only as the question demanded it. The measure of success we agreed with their head of architecture was concrete: at the end, the group would have a model of a real slice of the company in their own repository, built by their own hands, that their own management would accept as an answer to a real question. Learning ArchiMate would be a side effect. We have run enough Sparx EA and ArchiMate workshops to hold that this is the only reliable direction: people do not learn a modelling language and then find uses for it; they have a question, and learn exactly as much language as the question needs.
Why the previous training had not stuck
It is worth being precise about why the certified course had evaporated, because the failure modes shaped the programme design. When we interviewed participants beforehand — half an hour each, eight people — three patterns came up repeatedly.
First, the examples had belonged to someone else. A fictional company's order process demonstrates the notation perfectly and connects to nothing the learner knows. The knowledge had no anchor, so it drifted. Second, the course had treated all of ArchiMate as equally important. Faced with the full metamodel, the group had come away with the accurate impression that the language is large, and the inaccurate impression that they needed most of it. In practice a working architecture group uses perhaps a dozen concepts daily. Third — and this one is specific to tooling — the course had been delivered in a generic drawing environment, not in Sparx EA. The gap between knowing what an application service is and knowing how to create one in EA, reuse it across diagrams, and avoid the classic trap of drawing a new copy each time, had never been crossed. Several participants had opened EA once, produced a diagram of floating unconnected boxes, and concluded the tool was fighting them.
None of this is unusual, and none of it reflects on the people. Language courses produce language knowledge; modelling practices produce models. The two are related the way a grammar book is related to a written paragraph.
Designing the programme around one claim
We asked the head of architecture for a question that mattered enough to survive eight weeks of attention. The one we settled on came from their operations director: motor claims handling was being modernised, and nobody could say with confidence which systems a claim touched between first notification and payment, or which of those systems the modernisation would strain.
That question is close to ideal for a learning programme. It spans every ArchiMate layer without forcing any of them: there are capabilities and services the business cares about, processes people can describe from experience, applications with real names and real owners, and technology that the infrastructure team could speak to. It has an audience — the modernisation programme — waiting for the answer, which changes the emotional register of the work from exercise to contribution.
The programme itself ran as four full-day modules, roughly two weeks apart, in a dedicated sandbox area of their repository that we later promoted into the real structure. Each module followed the same rhythm: a short notation briefing covering only what the day needed, then modelling in pairs at the tool, then a closing session where pairs defended their fragments and the group merged them into one shared model. The merging discussion was where most of the learning happened, deliberately — two pairs modelling the same claims intake differently is not a problem to be avoided but the fastest route to understanding what the notation choices actually mean.
Setting up Sparx EA for learners
Before the first workshop day we spent two days configuring the environment, because a learner's first hour in Sparx EA decides their opinion of it for a year. Out of the box, EA greets a newcomer with every technology it supports and every window it owns; the correct response for a workshop is to take most of it away.
The sandbox lived in their real repository rather than on training laptops — same Pro Cloud Server, a dedicated package tree, so that everything learned about connecting, browsing and locking transferred directly to daily work. We prepared a trimmed workspace layout for participants: project browser, properties, notes and the diagram canvas, nothing else, distributed as a saved layout everyone could restore with two clicks when EA's windows inevitably wandered. The ArchiMate perspective was set as default, hiding the UML and SysML toolboxes entirely, and we restricted the working palette further to the concepts the programme would actually teach, so the toolbox never offered anyone a technology function or a value stream before they had a use for one.
Into the sandbox went three prepared packages: the application inventory — around sixty systems with names, owners and lifecycle tags, imported from a spreadsheet the week before, so no pair would waste workshop minutes typing system names — an empty, structured working area per pair, and a worked example modelling one small service correctly, with notes explaining each choice. The inventory import mattered more than it sounds: reusing existing elements instead of creating duplicates is the habit the whole tool depends on, and it can only be practised in a repository where the elements already exist to be found.
Module one: enough notation to argue
Day one introduced exactly six concepts: business process, business service, business role, application component, application service, and the serving relationship. That is enough to make a claim that can be wrong — "the claims intake process is served by the document capture service, which the scanning platform provides" — and being wrong in public, cheaply, is the engine of the whole method.
We spent the morning on the distinction that decides whether an ArchiMate model is useful or decorative: the difference between what something offers its consumers (a service), how the work is done (a process), and what performs it (a component). The group modelled first notification of loss from the customer's side inward. The arguments started within the hour — is "register claim" one process or three, is the call centre a role or an actor, does the mobile app provide one service or five — and we let them run, because every one of those arguments is really a question about how the company wants to describe itself, which is precisely the conversation an architecture practice exists to host.
In the tool, we enforced one habit from the first minute: the model browser is the truth, diagrams are views of it. Every element created once, reused everywhere, found through the browser or a model search before being created again. Participants who absorbed that habit on day one rarely produced a floating-boxes diagram again; it is the single highest-value habit in Sparx EA and the one generic drawing tools actively untrain.
Module two: the business layer, in their own terms
The second module widened the claims scenario to the full journey — notification, triage, assessment, decision, payment, recovery — and brought in capabilities. The capability discussion needed careful chairing. Insurance companies do not lack for capability maps; they lack capability maps anyone uses, and the group had two competing inherited ones. Rather than adjudicate abstractly, we anchored on the question: which capabilities does the modernisation programme claim to improve? That cut the relevant map down to a dozen capabilities, which the group linked to the processes and services from module one.
This was also where we introduced the realisation relationship properly, and with it the discipline of direction: processes realise services, components realise services, and the arrow means something falsifiable. We find that once a group can fluently say why realisation points from the performer up to the service, and serving from the service to its consumer, the rest of the relationship set follows with little friction; until then, more notation is just more confusion.
By the end of the day the shared model could answer the first half of the operations director's question — what the claims journey consists of and which services it consumes — and the group had begun, unprompted, correcting each other's granularity. When someone modelled "send letter" as a business process at the same level as "assess claim", it was a participant, not us, who objected. That is the moment a modelling practice starts existing.
Module three: applications, technology and the seams
Module three descended into the application layer, which for an insurer of this age meant meeting the estate honestly: a policy administration system old enough to vote, a claims platform mid-replacement, a document management system, a payments engine, and an integration layer that had accumulated rather than been designed. The infrastructure lead joined this session, which we recommend at every similar engagement — the conversation between architects and infrastructure at a shared diagram is worth more than either group modelling alone.
The modelling pattern for the day was the seam between layers: application services serving business processes, components realising those services, flows between components carrying named information. Naming the flows forced precision that boxes and lines had always allowed the group to evade — "claims data" dissolved under questioning into first notification messages, assessment reports and payment instructions, each with a different source of truth. Two previously undocumented dependencies surfaced during this exercise, one of which mattered to the modernisation programme's sequencing. The workshop paid for itself in that hour, by the operations director's own account.
We also introduced tagged values here — lifecycle status and ownership on application components — because module four would need them, and because attributes entered at the moment they become useful are remembered, where attributes mandated upfront are resented.
Module four: traceability, and the model as evidence
The final module turned the accumulated model into answers. We taught the group to build traceability views — from capability down through process and service to component and node — using diagrams where a narrative was needed, and the Relationship Matrix and model searches where a table was the honest format. The closing exercise was a rehearsal with a live audience: the group presented the claims model to the operations director and two programme managers, fielding questions directly from the repository. Which systems does a motor claim touch: eleven, on the happy path, and the model showed them. Which are strained by modernisation: three candidates, visible where modernised services converged on unmodernised components.
Questions arrived that the model could not answer — about volumes, about costs — and we had coached the group to treat these as scope statements rather than failures: the model answers structural questions; other instruments answer quantitative ones. An architecture group that can say clearly what its model does not claim earns trust faster than one that overreaches. The director left with answers, the programme left with a dependency view it adopted into its planning, and the group left with something subtler: the experience of the model being useful in a room, which no course simulates.
What happened between sessions
The two-week gaps were structured, not idle. Each module ended with modelling homework in pairs — extend the model along an assigned edge, with a named deliverable — and each gap included a one-hour remote clinic where we reviewed repository content with whoever showed up. The clinics mattered disproportionately. A workshop day performs; a clinic corrects. Reviewing a pair's actual model, in their repository, catches the habits a classroom never sees: elements created on diagrams and orphaned, relationships drawn against the grain of the metamodel, the quiet duplication of things that already existed.
We also ran a light validation script over the sandbox between modules — naming conventions, required tagged values, relationship legality — and opened each module with five minutes on its findings, anonymised. The point was not enforcement; it was demonstrating that quality in a repository is observable, continuously, by machine, which reframes conventions from etiquette into engineering.
Pairing deserves a note, because we composed the pairs deliberately and recomposed them each module. Architect with analyst, sceptic with enthusiast, and never two people from the same team twice running. The stated reason was knowledge spread; the operational reason was that a pair containing one strong modeller produces one strong modeller's model, silently, while a pair of peers has to negotiate every choice out loud — and the negotiation is the exercise. The pair that argued for twenty minutes about whether claim triage was a process or a function learned more ArchiMate that afternoon than any lecture could deliver, and both of them can now defend the answer they reached, which is worth more than the answer being ours. Several participants later adapted that script for their baseline repository, which is exactly the kind of theft we encourage; our general approach to it is written up in our guide to model validation in Sparx EA.
The workshop is the visible part of the engagement. The clinics between sessions, where real models get reviewed in the real repository, are where the practice actually forms.
A conventions sheet that fits on one page
The programme's most photocopied deliverable was also its shortest: a single page of modelling conventions, drafted progressively across the four modules and frozen at the end. One page was a design constraint, not an accident. Conventions documents that run to thirty pages are consulted once and feared thereafter; a page gets pinned next to a monitor.
What earned a place on it: the twelve concepts in scope, one line each, in the company's own vocabulary — an application component is "a system with its own budget line or support contract", because that definition had ended three workshop arguments. The four relationship types the group actually needed, each with its direction stated as a sentence pattern to complete: this process realises which service; this service serves which process. Naming rules, with a real good and bad example apiece. The tagged values every application must carry. And at the bottom, in bold, the browser-before-canvas rule: search for the element before you create it.
Everything that did not fit the page went into the worked example package in the repository instead, where guidance can sit next to a live demonstration of itself. We have come to prefer that split in all our capability development work: the page states the rules, the repository shows them, and the validation script enforces the mechanical ones, which frees the page to contain only what humans need to remember. When the company later extended the conventions for new domains, they kept the one-page discipline, adding a second page only for the data modelling additions — and reportedly after some resistance.
What stuck, six months on
We checked in twice after the programme ended, at six weeks and at six months. The honest scorecard: the claims model was alive and had been extended to two adjacent product lines, because the modernisation programme kept asking it questions — a model with an audience maintains itself in a way no mandate achieves. The repository had adopted the sandbox's conventions. Four of the eight regular participants were modelling weekly; two occasionally; two had returned to their old tools, both in roles where modelling was marginal anyway. The strategy office had begun asking for capability views in planning discussions, having seen one in the module-four presentation.
Against the criterion we set at the start — a real model, in their repository, accepted by their management as an answer to a real question — the programme succeeded plainly. Against the more ambitious criterion of an embedded practice, it was a strong start rather than an end state, which is the only honest claim a workshop can make. The company subsequently set up the governance and curation structures around the repository as a separate effort, on the sensible ground that a practice needs an operating model, not just trained people; that kind of follow-through is its own engagement, closer to enterprise architecture consulting than to training.
The honest limits of a workshop
A named limitation, because this format has one and it should be stated rather than discovered. A scenario-based programme optimises for depth over coverage: the group learned the dozen concepts the claims question needed, thoroughly, and did not meet the rest of the language. Motivation elements, the strategy layer beyond capabilities, the implementation and migration extension — all were deferred. For this group that was the right trade; a team that will face merger modelling or roadmap planning within the year would need those parts, and we would design a different scenario to force them into play.
The second limit is dependency on the question. The programme worked because the claims question was real, current and owned by someone with standing. We have declined to run this format when the sponsoring organisation could not produce such a question, because without one it degrades into exactly the abstract course it was designed to replace. If you have the question — something your management genuinely wants answered, that nobody can currently answer from documentation — the rest can be built around it. We would be glad to help; you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.