One digital service, two rooms that never met
The organisation in this case is a public employment service: the agency a citizen turns to after losing a job, for registration, guidance, benefit-related steps and, with luck, the way back into work. It had committed publicly to digitising its core service — the path from "I have just become unemployed" to "I have a personal action plan and a counsellor" — and the programme was already funded and staffed when we arrived.
What we found was a familiar geography. In one room, the service side: policy staff, service designers and team leads from the regional offices, working in journey maps, personas and slide decks, fluent in what the citizen experiences and why the current process frustrates people at precisely the moments they are most anxious. In another room, the technical side: architects and delivery teams responsible for the registration portal, the case management system, the matching platform and a document platform, fluent in interfaces, data and release plans. Between the rooms travelled documents — beautifully designed journey maps in one direction, integration diagrams in the other — and each room politely filed what the other sent, because neither could act on it. The programme board sensed the gap without being able to name it: decisions kept arriving twice, once framed as service design and once as system change, with no way to see whether the two framings agreed.
Our brief was to give the programme one connected description — citizen journey, processes, information and supporting systems in a single model — and to do it in Sparx EA, which the architecture team already ran as its repository.
Setting up a joint modelling effort
The temptation in this situation is to appoint the model as the neutral ground and invite everyone to it, and in our experience it fails, because a modelling tool is home territory for one room and hostile terrain for the other. So we set the work up differently: the neutral ground was a series of working sessions, and the model was the minutes.
Six half-day workshops over five weeks, each with both rooms present and each anchored on a stretch of the journey. The wall carried the service designers' journey map, enlarged, unedited — their artefact, treated as the authoritative statement of what the citizen goes through. Our facilitation walked stage by stage, asking the same four questions each time: what is the citizen doing here, what does the organisation do in response, what information changes hands, and which systems are involved. One of us facilitated; the other modelled live in Sparx EA, projected on the second screen, so both rooms watched the connected picture grow and could object to it in the moment. Objections were the product — a "that's not how it works" caught in a workshop is a defect that would otherwise surface much later, typically in integration testing, where it costs far more to unwind.
Between workshops we consolidated: tidied the live modelling, resolved the parked disagreements small enough to settle offline, and prepared the next stretch. The parking lot itself earned its keep — items too big to settle in the room became named issues in the model, each assigned to someone from the right room, which is how the model began accumulating not just structure but the programme's open questions in traceable form. This working rhythm draws on what we do in enterprise architecture engagements generally, but the two-room dynamic gave it an unusual edge: the model's first job was diplomatic, not technical.
Modelling the journey without losing the citizen
The modelling question that decides everything else in an engagement like this is what the journey stages become in ArchiMate. We modelled the journey as a value stream — six stages from "job loss" to "active guidance", each stage a value stream element carrying, in plain language, what the citizen needs at that point — with the citizen and the counsellor as business actors, and each stage realised by the business processes the agency runs behind it. Where the service designers' map recorded a pain point, we attached an assessment element quoting it, in the designers' own words, linked to the stage.
That choice sounds technical and is really editorial. The value stream keeps the citizen's perspective as the model's spine — the top layer of every overview reads as the journey the service designers recognise — while everything the technical room needs hangs off it in layers underneath. The service designers could stand in front of the top row and see their map; the architects could start from the same row and descend to interfaces. One artefact serving both fluencies. We held the stage count at six against pressure to subdivide, because a spine only works if people can hold it in their heads; the finer grain lives in the processes, where it belongs.
Connecting journey, process, information and systems
Beneath the stages, the model followed a disciplined stack. Each stage is realised by business processes; each process is served by application services; application services are realised by the four core systems and their components; and the business objects that matter — the registration, the employment history, the benefit claim, the action plan — are modelled once each, with access relationships showing which process reads or writes them and representation links to the forms and documents the citizen actually touches.
The information layer earned its place within the first fortnight. Journeys and systems both existed, in some form, in each room's artefacts; the business objects existed in neither. Nobody owned the question "what is the single thing called an employment history, and where does it live?" — and the act of modelling each object once, with every access to it visible, is what turned two comfortable stories into one uncomfortable, useful one. The employment history, it emerged, was captured in the portal, held again in different structure in case management, and asked for a third time on paper in some regional offices. Everyone knew a version of this; nobody had seen it as one picture.
For the process layer we stayed at ArchiMate's altitude in the shared model, and where delivery teams needed step-level detail we linked out to BPMN — the division of labour we describe in our piece on BPMN in Sparx EA. Two processes eventually got full BPMN treatment inside the same repository, traceable to their ArchiMate parents; the other twenty did not need it, and modelling discipline is mostly the art of not modelling things.
The conventions that made co-modelling possible
A model built by two communities needs firmer conventions than one built by architects alone, and we kept them few and blunt. Names came from the service side's vocabulary wherever a citizen or counsellor would recognise the concept, and from the systems' actual names where not — no invented middle language, because a model that renames things people know is a model people silently stop reading. Every element carried a one-sentence description written to be understood by the other room; workshop time was spent on these sentences, deliberately, because they are what WebEA readers see first. And provenance was explicit: elements originating from the journey map carried a tagged value linking back to the design artefact and its version, so when the designers revised their map — which they did, twice — the impact on the model was a query, not an archaeology project.
Package structure followed audience rather than layer: a package for the journey and its stages, one per journey stretch for the process detail, one for the shared information objects, and the existing application packages untouched — the programme model referenced them rather than duplicating them. That last rule mattered more than it looks: the four systems already had owners and models, and a programme that copies rather than references soon owns a fork it cannot maintain. The repository's package-level security enforced the boundary — programme modellers could reference the application packages but not edit them; where a relationship had to originate from a locked element, the owning team drew it on request, since connector ownership follows the source element. The arrangement kept the peace with the system owners and kept the referencing honest.
The re-entry problem the model exposed
The finding that paid for the engagement was the one the stack made undeniable. Tracing the employment history object across the journey showed the citizen supplying substantially the same information three times: structured, in the portal at registration; verbally, re-keyed by the counsellor into case management at intake, because case management had never consumed the portal's data; and on paper in offices whose local practice predated the portal. The model showed why, mechanically: an application service existed to expose the portal's registration data, and nothing subscribed to it — a reading both the portal and case management teams confirmed against their interface inventories before anyone acted on it. One missing serving relationship, in a diagram both rooms could read, standing for a daily indignity the service side had documented for years without being able to locate its cause.
The integration was scoped, argued for with the model's picture, and delivered by the case management team within the programme — the intake conversation now starts from the citizen's own registration data on the counsellor's screen. The paper practice took longer, because its cause was habit and workload rather than architecture, and honesty requires saying the model contributed the diagnosis there, not the cure. The board also learned something structural from the pattern: two further "everyone knows" irritations were traced the same way in later increments, both to missing consumption of data that was already available. The agency's problem, it turned out, was rarely missing systems; it was built capability nobody had wired together.
A connected model's real product is embarrassment of a specific, actionable kind: the gap between what the organisation believes it does and what its own layers, read together, show. The re-entry finding was never invisible — it was distributed, one third in each of three artefacts nobody read side by side.
Views for each audience
One model, several readerships, so we invested in views the way the site's editors would. The programme board got a single journey overview — stages, pain-point assessments, and the status of each committed improvement — regenerated before each board meeting and read in two minutes. Delivery teams got per-stage views descending to services and interfaces, which became the standing backdrop of their planning sessions. The data protection officer, unexpectedly, became one of the model's heaviest users: the information layer — the business objects, the processes touching them through access relationships, and the systems each object is realised in — gave her the beginning of a processing-activity picture that she had been assembling by interview for a year. Her view was two searches and a diagram, and it bought the model an ally in a part of the organisation architecture rarely reaches.
The board pack deserves its own sentence, because it is where view discipline met document generation. Before each board, a template run assembled the journey overview, the status of committed improvements and the open-issue list into a short document straight from the repository — no slide assembly, far less version confusion, and the same numbers the delivery teams saw in their views, which ended the small but corrosive discrepancies between what different meetings were told. The generation side of Sparx EA did this without drama once the template was built; the effort, as usual, was editorial — deciding what a board should not be shown.
Service-side staff read the model through WebEA, with no desktop licences or training on their side — WebEA itself rides on the organisation's Pro Cloud Server deployment — following links we embedded in the programme's collaboration space. The element descriptions written for the other room did their work here; the feedback that mattered most came from a regional team lead who corrected a process description in week one — evidence a reader outside IT was actually reading. On the platform side this is all standard machinery — WebEA, model searches, document generation for the board pack — applied with editorial intent rather than technical ambition.
How the model was used during delivery
A programme model earns its keep after the workshops end, and the test came quickly: scope change. When the matching platform's replacement slipped by two quarters, the question "what does that touch?" was answered from the model in an afternoon — which stages, which processes, which interfaces, which committed improvements — where the previous comparable exercise had taken weeks to establish less. Impact analysis is the least glamorous and most persuasive thing a connected repository does, and it converted the programme director from tolerating the model to requiring it: from that point, change requests to the board carried a model-derived impact view as a standing attachment.
The model also quietly restructured accountability. Each committed improvement — the re-entry integration first among them — existed as an element linked to the stages it improved and the systems it changed, with an owner and a status. The board tracked delivery against the journey, not against a project list, which kept the citizen-facing purpose attached to every technical line item. When an increment proposed dropping the document platform work to protect a date, the board could see, in one view, which journey stage would keep its paper step as a result — and chose to protect the integration instead. That is the decision the two-rooms geography could never have produced, and it was taken in fifteen minutes.
The engagement, in rough numbers
Concreteness helps anyone weighing a similar effort, so here is the shape of ours, in the round terms that are honest for an illustrative case. The joint phase ran about five weeks: six half-day workshops, typically fifteen to twenty people in the room, with two of us — one facilitating, one modelling live. Consolidation between workshops took the modeller among us roughly a day per workshop. The connected model came out at a few hundred elements and somewhat more relationships: six value stream stages, around twenty business processes, a dozen shared business objects, and the services and components of the four core systems, referenced from their existing packages rather than duplicated. Two processes carried full BPMN detail; the rest did not need it.
After the joint phase, the working pattern was lighter: we stayed involved for two delivery increments at roughly a day a week — consolidation, view preparation for boards, and coaching the agency's architects into the facilitation role — before stepping back entirely. The board pack, the per-stage views and the data protection views were all generated from the repository by then, on a rhythm the architecture team ran without us. As consultancy engagements go, the profile is front-loaded and short; the model does its expensive learning in the workshops, and most of what follows is maintenance plus editorial care.
| Phase | Duration | Our involvement | Main output |
|---|---|---|---|
| Preparation | Two weeks | Full time, two people | Conventions, package structure, workshop plan |
| Joint workshops | Five weeks | Two people per session plus consolidation | Connected journey model, issue list |
| Delivery support | Two increments | About a day a week | Impact views, board packs, coached handover |
What the teams took away
The programme delivered its first two increments during our involvement, and the model practices survived our departure — the sturdier test. The agency's architects run the consolidation rhythm now; the service designers still own the journey map and still see it honoured as the model's source; and the joint workshop format has been reused for the next service in the digitisation plan, staffed internally. The repository holds the connected description as the programme's shared memory: a new delivery team lead onboarding in a day from the per-stage views was, for us, the clearest signal the artefact had become infrastructure rather than documentation.
For the organisation, the durable gain is the pattern, not the model. Journey as spine, information modelled once, systems referenced rather than copied, findings argued from connected views — the second service's modelling started from that template and reached its first findings noticeably faster. Models age; the capability to build them is the asset.
There was one cultural residue we did not predict. The phrase "is that in the model?" entered the programme's vocabulary as shorthand for "has this been thought through where everyone can see it" — applied to scope changes, to integration claims, and once, pointedly, by a service designer to an architect. When the question flows in both directions between rooms that previously exchanged documents, the model has done something no artefact does on its own: it has changed who is allowed to check whose homework. We count that, more than any diagram, as the engagement's result.
What we deliberately kept out of the model
Two exclusions defined the model's edges, and both were argued about. The service designers' craft artefacts — personas, emotion curves, prototypes, interview material — stayed in the design tools, linked by URL from the relevant stages. An enterprise repository is the wrong home for them: they change on a design rhythm, they carry nuance a modelling notation flattens, and dragging them in would have made the designers guests in someone else's tool, which the whole setup existed to avoid. The model points at them respectfully and does not pretend to contain them.
Step-level operational detail stayed out of the shared layers for the parallel reason: the shared model is where the rooms meet, and it stays readable only if each room's private complexity remains private. The named limitation we would flag to anyone repeating this: a value-stream spine is a modelling convention, not a service design method, and it captures the citizen's path only as well as the journey map it mirrors. Ours was good because the service designers were good. A weak journey map, connected beautifully to systems, produces a well-engineered description of the wrong service — the model amplifies the quality of what each room brings, in both directions.
If your organisation is digitising a public service and the journey people and the systems people are sending each other documents neither can act on, this pattern of joint modelling in Sparx EA is one we would be glad to discuss — our contact page is the place to start.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.