Two views of the same factory
The organisation, a manufacturer operating several production sites, came to us with a problem that sounded organisational but turned out to be architectural. The operations side of the business had process documentation — some current, some historic, spread across a process tool that had fallen out of use, a shared drive of flowcharts, and the heads of a few long-serving supervisors. The IT side had an application register that listed what ran where and who paid for it. What the organisation did not have was any reliable connection between the two. When a production planner asked what would happen to order release if a particular system went down, the answer took a week to assemble and was different depending on who assembled it.
The trigger for the engagement was concrete: the organisation was beginning to evaluate a replacement for its manufacturing execution system, and the programme board wanted to understand which processes the incumbent actually supported before anyone talked to vendors. The honest answer was that nobody knew, at least not in a form that could be written down and defended. We were asked to fix that — not to document every process in the company, but to build a maintained, queryable link between the operational processes that mattered and the systems that supported them, in the Sparx EA repository the architecture team already ran.
What we found when we looked
We spent the first fortnight taking stock of what already existed, because process documentation initiatives leave sediment, and the sediment tells you what will and will not work the second time. The abandoned process tool held a few hundred diagrams from an initiative five years earlier — beautifully consistent, largely obsolete, and untouched since the consultant who drew them left. The shared drive held flowcharts in every drawing tool of the past decade, some contradicting each other for the same process at different sites. The most current knowledge was in operating instructions maintained by the quality department for certification purposes, which described procedures precisely but said almost nothing about systems.
Two conclusions came out of that stocktake and shaped everything after it. The first was that the previous initiative had failed not from bad modelling but from having no consumer: the diagrams answered no recurring question, so nobody paid the cost of keeping them alive. Our models would exist to answer the support question, and anything that did not serve that question would be left out, however interesting. The second was that the site differences were real, not documentation noise — order release genuinely worked differently at the two largest plants, a fact with direct consequences for a single MES rollout. We modelled the variants as separate processes under a common parent rather than pretending one standard existed, and flagged the divergence to the programme, where it moved the rollout sequencing discussion by some months.
The application register, by contrast, was in decent shape — the architecture team had kept it current in the repository, and it gave the ArchiMate side a trustworthy foundation. That asymmetry, weak process knowledge over a solid application model, is the commonest starting position we see in manufacturing, and it is a workable one; the reverse is much harder.
Choosing two notations on purpose
The first design decision was also the most debated: one modelling language or two. The architecture team worked in ArchiMate. The people who understood the processes — production planners, quality managers, shift supervisors — did not, and in our experience rarely do, because ArchiMate's process support is deliberately coarse. It can say that a process exists and is served by an application; it cannot comfortably say what happens inside the process, in what order, with which decisions and exceptions. That level belongs to BPMN, and it is the level at which process owners recognise their own work.
So we used both, in the same repository, each doing the job it was designed for. Operational processes were modelled in BPMN 2.0, which Sparx EA supports natively through its built-in MDG Technology, down to the task level for the processes in scope. The architecture — applications, the services they expose, the technology beneath them — stayed in ArchiMate. The two notations meet at a defined seam, which the rest of this case study is mostly about, because the seam is where this kind of initiative usually fails.
It is worth saying that using two notations in one tool is not free. Modellers need to know which toolbox to draw from, and a governance rule has to say where each language may appear. But the alternative — forcing everything into one notation — costs more. ArchiMate-only would have produced process models the process owners could not read, at which point they stop correcting them and the content quietly dies. BPMN-only would have left the application landscape without the relationship semantics that make impact analysis possible. Two languages, one seam, was the cheaper compromise, and Sparx EA is one of the few tools where both live comfortably in a single repository.
Structuring the repository so the seam is visible
We restructured the repository around that decision before modelling anything new. Process content lives in a package tree organised by value stream — order to dispatch, procure to stock, plan to produce — with one BPMN process diagram per operational process and a strict two-level depth limit, because process hierarchies deeper than that stop being maintained. Architecture content lives in its own tree, organised by domain, exactly as the architecture team had it before. Neither tree references the other's internals directly; everything crosses through a small, deliberately boring package of bridge elements that both sides treat as shared property.
The package structure sounds like housekeeping, but it is what made the collaboration work. The two analysts who maintain the process content — one in operations, one in quality — were given write access to the process tree and nothing else, through Sparx EA's package-level security; process owners contribute in workshops and reviews rather than at the keyboard. Architects kept the architecture tree. The bridge package requires both an architect and a process owner to agree before anything in it changes, which is a rule enforced socially rather than by the tool, but the package boundary makes the rule easy to state and easy to check. Each package also carries an owner tagged value, so the weekly model report can say not just what changed but which owner's package it changed in.
Processes first, systems second
The modelling itself ran as a series of workshops per value stream, and we learned early to keep the two halves of each workshop apart. The first half was pure process: the owner walked through the work as it actually happens, and we captured it live in BPMN with the diagram projected. No system names allowed — the moment a workshop drifts into systems, the process model becomes a picture of the current IT landscape rather than of the work, and loses its value for exactly the vendor-evaluation questions the client needed answered. Getting the sequence right, with its exceptions and its waiting points, took most of the time and produced most of the corrections.
The second half added the systems. For each task we asked one question: what do you have in front of you when you do this? The answers — a screen in the ERP, a terminal on the shop floor, a spreadsheet, a clipboard — went into the model as the supporting relationship for that task. The spreadsheets and clipboards went in too, modelled honestly, because a task supported by a spreadsheet is precisely the kind of fact a modernisation programme needs to see. Around a dozen workshops of half a day each covered the value streams in scope, with a written convention that a process appears in the model only if its owner attended the workshop; processes without an owner in the room were listed as gaps rather than modelled from hearsay.
The projector rule mattered more than any notation choice: nothing entered the model that the process owner had not seen drawn, objected to, and finally nodded at. Models built from interview notes afterwards come out smoother than the reality, and wrong in the places that matter.
The bridge: application services, not applications
The seam between BPMN and ArchiMate needed a precise rule, and the rule we set is the one we would defend anywhere: process tasks link to application services, never directly to applications. The ERP is not what supports the order release task; the order release service, which happens today to be provided by the ERP, is. The distinction sounds pedantic until the MES evaluation starts, at which point it becomes the entire point. Vendors are proposing to provide services; the processes consume services; which box provides which service is exactly the variable under discussion. A model that links tasks straight to application components has already assumed the answer.
Concretely, the bridge package contains around eighty ArchiMate application services, each realised by exactly one application component in the architecture tree and each serving one or more BPMN tasks in the process tree. In Sparx EA the cross-notation relationship is technically an ArchiMate serving relationship drawn to a BPMN activity element, which the tool permits and which we document as a convention, because it is a convention — no standard blesses it, and we say so plainly in the model's readme diagram. Naming discipline carried a lot of weight here: services are named as capabilities a business person would recognise, in the language of the factory floor, not as module names from a vendor catalogue.
The traceability window in Sparx EA turned out to be the everyday payoff of this structure. Select the MES component and the window unfolds realisation to services to tasks to processes: every place the system touches the work, three levels deep, without drawing a single dedicated diagram. That one navigation, shown live, is what convinced the programme director the modelling effort was worth its cost.
Reading coverage in the Relationship Matrix
With processes on one axis and application services on the other, the Relationship Matrix became the engagement's reporting instrument. One matrix per value stream, tasks down the side, services across the top, a mark wherever a serving relationship exists. Read one way, it answers the support question: which services does this process depend on. Read the other way, it answers the exposure question: which processes does this service — and therefore the system behind it — touch. We generated the matrices straight from the repository into the workshop packs, and they were corrected in the meetings like any other artefact.
The empty regions taught us the most. A cluster of tasks in the quality value stream had no supporting application service at all — only the spreadsheet and paper placeholders we had modelled, which the matrix renders distinctly from a genuine unknown: the work ran on paper and local spreadsheets, which the quality manager knew individually but had never seen laid out as a pattern. Conversely, one legacy reporting system served nothing in any of the modelled value streams: every task it had once supported had migrated to the ERP over the years, and it survived on renewal budget out of pure habit. After its owner confirmed no consumers existed outside the modelled scope either, it was decommissioned within the year, which paid a respectable fraction of the engagement's cost by itself, and gave the architecture team a story about the model earning money rather than costing it — a story worth more than any capability heat map for winning the next round of modelling budget.
For the board pack we did not show the matrices themselves — a forty-column grid persuades nobody. A model search extracted the counts that mattered: tasks with no supporting service, services concentrated in systems already flagged for renewal, and processes wholly dependent on a single application with no modelled fallback. Those went into the pack as a short table with a sentence against each line, regenerated before every meeting so the numbers always reflected the repository as it stood that morning. The discipline of regenerating rather than editing turned out to be persuasive in itself; when a director asked whether a figure was current, the answer — it was produced from the repository this morning — ended a category of argument that had previously consumed whole meetings.
Putting the model to work: the MES question
The MES evaluation was where the structure repaid the client. Because tasks linked to services, we could produce, for each of the three candidate value streams, the exact list of services the incumbent MES provided, the tasks each one served, and the processes those tasks belonged to — a requirements skeleton generated from the model rather than brainstormed in a room. The programme wrote its request for proposals around that service list. Vendor claims were then assessed against it service by service, with each vendor's coverage recorded as a scenario in the repository, so the comparison the board finally saw traced back to the same model the process owners had corrected in workshops.
The model also reframed the boundary question, which in MES replacements is usually the expensive one. Two services everyone had assumed belonged to the MES turned out, once the serving relationships were on the table, to be consumed almost entirely by planning processes that the ERP already supported elsewhere — moving them out of the MES scope shrank the programme and removed an integration. We claim no credit for the decision itself; the model simply made the question visible early, while it was still cheap to ask. That is our honest view of what architecture models do in programmes like this: they rarely produce the answer, but they bring the argument forward to a point where changing course is still affordable.
Reaching readers who will never open the tool
A decision we took early, and would take again, is that process owners do not become Sparx EA users. The tool is where the model lives, not where the factory reads it. Asking a shift supervisor to install a modelling client, learn its navigation and remember a licence password is how you convert an ally into a critic, and the licence cost would have bought nothing — their contribution happens in workshops and reviews, not at a modelling keyboard.
Instead, each value stream gets a generated pack: the BPMN diagrams, the support matrix, and a one-page list of open gaps, produced from the repository with Sparx EA's document generation and dropped onto the intranet after every review cycle. The packs carry a generation date on every page, which quietly solved the versioning arguments that had plagued the shared-drive era — when two people disagree about a process, the first question is now whose printout is older. Two people outside the architecture team did learn the tool properly: an analyst in operations and one in quality, who maintain their trees between reviews and have become the model's advocates on their side of the house. Concentrating the tooling skill in two named people, rather than spreading a thin familiarity across twenty, is the pattern we recommend for every mixed business–IT modelling effort we run.
Keeping process and architecture in step
A linked model decays from both ends: processes change on the floor, systems change in projects, and each change quietly invalidates relationships that nobody is looking at. We set up the maintenance to be small and recurring rather than heroic and annual. Process owners review their own value stream's matrix twice a year in a session that takes an hour; the architecture side updates the bridge whenever an application change goes through the existing change process, which we amended with a single added question — does this change add, remove or move a service? Every bridge relationship carries a last-reviewed tagged value, stamped by the review sessions and by the change process; a model search lists the ones whose stamp is older than a year, and those get checked first.
We also resisted scope growth, which is the quieter threat. Success created demand: within months, other departments wanted their processes modelled, and there was pressure to deepen the BPMN to keystroke level so it could double as training material. Both would have sunk the maintenance budget. The rule the client adopted, on our advice, is that the repository models a process at the depth needed to reason about system support and no deeper, and admits a new value stream only when a named owner commits to the twice-yearly review. Training material lives elsewhere. A year on, the discipline is holding: the twice-yearly reviews happen, the matrices stay honest, and the model has admitted one new value stream on exactly the terms the rule requires — a named owner, a bounded scope, and a review commitment in the diary before the first workshop was booked. Saying no to good ideas is a governance capability, and it is the one that keeps linked models alive — a theme we return to in our Sparx EA consulting work more often than any technical topic.
Limits we named on day one
Three limitations were written into the engagement summary, and they belong in this account too. First, the BPMN–ArchiMate seam is a convention, not a standard. Sparx EA lets the two notations coexist and lets us draw the bridge relationships, but no metamodel enforces the rule that tasks link only to services; our model validation script enforces it instead, and a team that stops running the script will drift. Second, Sparx EA's BPMN simulation is not something we used or recommended here — the models are built for traceability, not execution, and simulation-grade models need timing and resource detail these deliberately do not carry.
Third, the model covers the value streams the programme paid to cover, and coverage is not completeness. There are processes in the company that appear nowhere in the repository, and the matrices say so explicitly rather than implying a full picture. We regard that honesty as a feature of the approach: a model that is explicit about its edges gets trusted inside them, and the fastest way to lose a factory audience is to show them a diagram that claims more than the people in the room know to be true.
The repository now answers, in minutes, the question that once took a week: what does this system actually support? If your organisation is facing a systems decision with that question unanswered — an MES, an ERP, anything with processes attached — we can help you build the link before the vendors arrive. 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.