Keeping Process Models and Architecture in Step

Two teams, two tools

The organisation behind this engagement is a food and beverage producer operating a few dozen production and distribution sites across Europe. Like many manufacturers of its size, it had invested seriously in process management. A process excellence team had spent years documenting how the business actually runs — order intake, production scheduling, quality release, warehouse despatch, returns — in SAP Signavio, with BPMN diagrams that operational staff genuinely used. Site managers referred to them during onboarding, and internal audit treated them as the reference for how work was supposed to happen.

In parallel, a small architecture team maintained a Sparx Enterprise Architect repository describing the application and technology estate: an application catalogue of around a hundred and twenty systems, their interfaces, their owners and their lifecycle status. That repository, too, was in reasonable shape. It answered questions about systems well enough that the IT leadership used it in planning discussions.

The two bodies of knowledge had grown up side by side without ever touching. Nobody had decided that; it had simply happened, the way it does when two competent teams each pick the right tool for their own job. The trouble surfaced whenever a question crossed the boundary — and the questions that matter most in a manufacturing business almost always do. Which processes stop if we replace the warehouse management system? Which applications does the quality release process actually depend on? Neither tool could answer, because each held only half of the picture.

We were asked to connect the two — not to migrate one into the other, which both teams rightly resisted, but to define how Signavio process content and Sparx EA architecture content would be exchanged and kept in step.

What we found when we looked

Before proposing anything, we spent time in both repositories. The Signavio workspace held around three hundred and forty processes, organised into a tidy hierarchy of process groups. The modelling discipline was good: naming was consistent, ownership was recorded, and diagrams were current enough that we found only a handful of processes nobody would claim.

The weakness was in how the process models referred to systems. System references lived in lane names, activity descriptions and free-text attributes, and they were written the way people speak. The same ERP appeared as "SAP", "SAP ECC", "the ERP" and, in one memorable case, the name of a system that had been decommissioned three years earlier. When we extracted every distinct system name mentioned across the process estate, we found nearly three hundred labels referring to what turned out to be about ninety real applications. There was no way to ask "which processes touch this system" and trust the answer.

On the Sparx EA side the application catalogue was solid, but processes were represented by a stale package of ArchiMate business processes someone had sketched during a TOGAF exercise years before — around forty elements, unowned, disconnected from Signavio and from reality. The architects knew it was dead weight; it had survived because deleting it felt like losing information, a pattern we see in most repositories that have lived a few years.

One incident had given the engagement its urgency. A change to label printing — a regulatory formatting requirement — had been assessed against the architecture repository, cleared, and implemented. It broke a despatch process at two sites, because the dependency between that process and the label printing service existed only in a Signavio diagram's activity text, where no impact analysis would ever find it.

One authority per artefact

The first design decision, and the one everything else rests on, was to give each kind of content exactly one authoritative home. Both teams had quietly feared the other outcome — a bidirectional synchronisation in which both tools could edit everything, which in our experience produces conflicts nobody can resolve and trust in neither system. We put the principle in writing early: content is mastered in one tool, and the other tool receives a read-only reflection of it.

Deliberately, BPMN flow detail does not cross the boundary at all. The architects did not need gateways and events in Sparx EA; they needed to know that a process exists, who owns it, and which applications support it. Importing full BPMN would have filled the repository with activity-level detail the architecture team would never maintain. The reflection is an inventory, not a diagram migration — and because each mirrored element carries a URL straight back to the live Signavio diagram, anyone in EA who needs the detail is one click from the authoritative version.

We should say why we rejected the obvious-looking alternative. Sparx EA can import BPMN, and a one-off migration of the Signavio estate would have demonstrated well in a steering meeting. But a migrated model is current for exactly one day, and the client would have owned two diverging process repositories instead of one — the state most organisations are trying to escape, reached deliberately. Exchange beats migration whenever both tools are staying, and both tools were staying.

Figure 1 shows the shape this produces in the repository. Mirrored processes sit in their own package hierarchy, matching the Signavio process groups one for one. Beneath them, the application services and components the architecture team already maintained. The one new kind of relationship in the model is the serving link between an application service and a process — and that link is mastered by the architects, in Sparx EA, because they are the ones who maintain the application side of it.

Identifiers before integration

Nothing about the exchange works without stable identifiers, so that is where the technical work started. Every Signavio process carries a durable internal identifier; we store it in a tagged value, signavioId, on the corresponding Sparx EA element. From then on the import keys on that identifier alone. A process can be renamed in Signavio, moved to a different group, or given a new owner, and the next import updates the existing EA element rather than creating a duplicate — which is the failure mode that kills most home-grown integrations within a quarter.

The unavoidable, unglamorous part was the first match. Three hundred and forty processes had to be paired with the forty stale ArchiMate processes already in EA, or created fresh. We generated a candidate matching by normalised name, then sat with the process excellence lead and an architect for two half-day sessions to confirm it. About thirty processes matched something existing worth keeping; the rest of the old package was archived to a clearly-labelled graveyard package rather than deleted, with a note recording why. The matching sessions also surfaced a dozen genuine duplicates inside Signavio itself — two teams had documented the same returns process under different groups — which the process team was glad to find for its own reasons.

One structural safeguard completed the identity work: the mirrored process package in Sparx EA is locked against manual editing. With EA's security enabled, the package is writable only by the account the import script runs under, so an architect cannot "helpfully" rename a mirrored process or add one by hand — edits that the next Monday run would either overwrite or, worse, duplicate. The rule sounds bureaucratic and is the opposite: it means every element in that package can be trusted to say exactly what Signavio said, which is the entire point of a reflection. Anything the architects want to say about a process, they say in the relationships and elements they master — and the locking does not get in their way, because a connector in EA belongs with its source element, so a serving link drawn from an application service the architects own to a mirrored process works even though the process element itself is read-only.

The weekly exchange, step by step

The exchange itself is a scheduled job that runs once a week, early on Monday. We deliberately kept it to three moving parts, each of which can be run and tested on its own.

First, an export pulls the process inventory from Signavio's REST API: identifier, name, group path, owner, status and diagram URL for every process. The result lands in a staging file — plain JSON, kept under version control, which means every week's exchange leaves a diffable record of what Signavio said at that moment. More than once since, that history has answered "when did this process change owner" faster than either tool could.

Second, a transformation compares the staging file against the snapshot recorded at the last successful import, producing three lists: processes to create, processes whose attributes changed, and processes that have disappeared from the export. Third, an import script drives the Sparx EA automation API: it walks the lists, creates or updates elements under the mirrored package hierarchy, and writes the tagged values. Creations and updates are applied automatically. Disappearances are not.

Deletions never propagate automatically

A process vanishing from the export can mean it was retired — or that it was moved out of the workspaces the export covers, or an export partially failed. An automatic delete in EA would sever the process's links to applications, and those links are exactly the content EA masters and Signavio knows nothing about. So disappearances go onto a reconciliation report instead: the mirrored element is flagged with a status tagged value, and a short monthly session between the two teams decides its fate. In practice the session takes about a quarter of an hour, and most flagged items turn out to be processes archived or moved out of the export’s scope rather than real retirements.

What a run looks like in practice

The whole Monday job takes under ten minutes against three hundred and forty processes, most of it in the API export rather than the EA import; a typical week carries a handful of attribute changes and one or two new processes. The job writes a one-page summary — created, updated, flagged, and any records the transformation rejected as malformed — and posts it to the two teams' shared channel, on success as well as failure, because a silent scheduler is indistinguishable from a broken one. When the export fails outright, which has happened twice (once an expired API credential, once a platform-side change to a date format), the import simply does not run: last week's mirror stays in place, intact and slightly stale, which is exactly the failure behaviour you want from a reflection. The contract test that checks the export's shape before anything is written caught the date-format change before it could half-import, and that single guard has justified its existence on its own.

Figure 2 shows the whole mechanism, including the one flow that runs in the opposite direction — the glossary feed, which deserves its own section.

Feeding the glossary the other way

The three hundred free-text system names were a symptom, not a cause. The cause was that Signavio modellers had nothing better than free text to reach for when they wanted to say "this activity uses the warehouse system". Cleaning the labels once would have decayed within months.

So the second half of the design runs the other way: the application catalogue in Sparx EA seeds a dictionary in Signavio. A script exports every current application — canonical name, short description, lifecycle status, keyed on the EA element’s GUID so renames propagate — and loads it into the Signavio glossary. Process modellers now pick applications from that list instead of typing names, and the pick is recorded as a structured reference rather than prose. Those references are documentation aids inside the process model; the maintained dependency links remain the ones the architects master in Sparx EA, and where the two disagree the monthly reconciliation session settles it. When an application is renamed or retired in EA, the next glossary feed carries the change to every process that references it.

New names still appear — a modeller documenting a process discovers a system the architects have never catalogued, which is useful information travelling in the right direction. Those requests route to the architecture team, who either add the application to EA (from where it flows into the glossary) or point the modeller at the canonical entry they should have used. The dictionary stays curated precisely because it has one door.

Internal audit turned out to be the glossary's most appreciative customer, which we had not predicted. Audit walkthroughs follow process documentation, and for years each walkthrough had begun with an interpretive exercise — establishing which real system "the ERP" in a diagram referred to before any control could be tested. Structured references ended that. The auditors now resolve a system reference to the architecture repository's entry, with its owner and lifecycle status, in one step, and their walkthrough preparation time dropped accordingly. It is a small effect with a useful lesson inside it: integrations justified by one audience tend to pay off with audiences nobody listed in the business case.

Linking processes to applications

With the inventory mirrored and the glossary structured, the links between processes and applications — the content the whole engagement existed to create — were built in a series of workshops, one per process group, over about two months. In each session the process owner and an architect walked the group's processes and recorded which application services each one depends on. We used Sparx EA's Relationship Matrix for the working sessions: processes down one axis, application services across the other, which turns "what did we miss" from an act of memory into an act of scanning an almost-empty row.

The granularity question came up immediately, as it always does. Site staff wanted to link activities, not processes; the architects wanted links they could maintain. We settled on process-level links as the maintained baseline — around five hundred serving relationships when the workshops finished — with activity-level detail recorded only where an impact analysis had actually needed it. That restraint needs defending: every link created is a link somebody must keep true, and a thousand speculative links are worth less than five hundred maintained ones. Our own validation scripts check the links' hygiene weekly — every mirrored process should be served by at least one application service or carry an explicit "manual process" tag, and every link must point at an application service that still belongs to a live application.

What changed for the client

The question that started the engagement — which processes depend on this system, and might stop if we change it — now has a five-minute answer. It is a model search in Sparx EA, and it is also, more importantly, a standing agenda item: the change advisory board asks for the affected-process list as part of every significant change, because producing it stopped being anyone's afternoon of archaeology. The label printing incident that motivated the work would have been visible in the first query anyone ran.

The first real test

The linkage earned its keep properly about six months in, when the client began a pre-study to replace the warehouse management system at its distribution sites. Historically that study would have opened with a discovery phase — weeks of interviews to establish what the WMS actually touches. Instead it opened with a query: every process served by the WMS's application services, forty-one of them, grouped by process owner, each with a link to its live Signavio diagram. The study team walked into their first workshop with the affected owners already named and the diagrams already open, and the discovery phase collapsed from weeks into two days of confirmation.

Just as telling was what the query got wrong: three of the forty-one links turned out to describe how sites used to work before an earlier consolidation. The workshops corrected them in the model there and then — and that is the healthy loop, because an impact analysis that quietly works around stale links leaves them stale for the next study. The model is not right because it was built carefully; it is right because every serious use of it is also a correction pass.

The softer change is in how the two teams relate. The monthly reconciliation session, which exists for hygiene, has become the place where process and architecture people notice each other's plans early. The process excellence lead told us the glossary feed alone justified the project from her side: her modellers stopped inventing system names, and audit stopped asking what "the ERP" meant. On the architecture side, the team now presents impact views in business language — process names the operations directors recognise — which has done more for the standing of the architecture practice than any diagram convention ever did.

What we would do differently

Two things. First, we would seed the glossary before running the first process import, not after. We did it the other way around, and for a few weeks modellers kept creating free-text names that then had to be matched — avoidable rework we walked into by sequencing for the architects' benefit rather than the modellers'.

Second, the named limitation: the process-to-application links live only in Sparx EA, and Signavio users cannot see them. A process modeller looking at a diagram there has no indication that the architecture team has recorded its dependencies one repository away. Pushing the links back into Signavio as glossary relations is technically feasible over the same API and remains on the client's roadmap; we chose not to build it in the first phase because a second write-path doubles the reconciliation surface, and we wanted a year of the simple design running boringly before adding one. That is a defensible trade-off, but it is a real gap, and we said so in the closing report rather than hoping nobody would ask.

The exchange also carries a maintenance obligation that no design removes: it depends on Signavio's export API remaining shaped the way it is. Version pinning and a contract test that runs before each weekly exchange keep surprises small, but a tool integration is a commitment, not a purchase.

Where they are now

Eighteen months on, the exchange still runs every Monday, the reconciliation session still fits in fifteen minutes, and the link count has grown modestly rather than explosively — which is what maintained content looks like. The client's own team operates the whole mechanism; our involvement ended with a handover workshop and a runbook, plus the automation API scripts under their version control, not ours.

If your organisation runs its processes in one tool and its architecture in another, and the questions that cross the boundary have no home — we have designed this exchange more than once, and the decisions transfer better than the scripts do. 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.