Linking Operational Inventories with Architecture Models

Two lists of applications, neither of them right

The organisation is a hospitality group — hundreds of properties across Europe under several brands, with the central IT estate that implies: property management, reservations and channel distribution, payments, loyalty, procurement, workforce scheduling, and the integration fabric holding it together. Operations ran on ServiceNow, with a CMDB that support teams updated daily because incidents routed through it. Architecture ran on Sparx EA, where the application landscape, capability maps and integration models lived.

Each tool was healthy on its own terms. The problem was between them: the group had two lists of its applications, and they disagreed. A portfolio review had stalled for a month over exactly this — the CMDB counted roughly nine hundred application CIs, the architecture repository around six hundred components, and every planning meeting opened with a debate about which list to trust before it could discuss anything on either. Lifecycle decisions were being taken on applications the architects tracked, using support data from records the operations team could not confidently match to them.

The instinctive fix — "integrate the tools" — had been tried once before, as a CSV export loaded into Sparx EA over a weekend. It created a few hundred duplicate elements whose cleanup was still generating chore tickets two years later. So the brief we were given was gun-shy and precise: connect ServiceNow and Sparx EA so there is one truth about applications, but in a way that cannot silently damage either side. The caution was earned, and it became the design's spine.

Nine hundred CIs meet six hundred components

Discovery here was mostly counting, and the counting was revealing. We exported both inventories in the first week and put the raw comparison in front of both teams together — the same spreadsheet, the same room, no pre-processing. Watching operations and architecture each recognise their own tool's blind spots in the other's list did more for the engagement's politics than any steering meeting; from that session on, "your list is wrong" disappeared from the vocabulary, replaced by the more accurate "our lists disagree", which is a problem two teams can share.

The gap between nine hundred and six hundred turned out to have structure. A few hundred CIs were things architecture deliberately does not model: monitoring agents, utilities, per-property instances of the same product recorded separately because support contracts differ by site. A smaller set pointed the other way — systems the architects tracked that operations had never registered because they never generated incidents, including, embarrassingly for everyone, the data warehouse. The genuinely troublesome residue was the middle: applications present in both tools under names that had drifted apart. The property management system existed as three differently named records on one side and one component on the other; nobody was wrong, and nothing matched.

There was no shared identifier anywhere. Names were the only join key available, and names are the worst join key there is — they drift with rebrands, vendor changes and abbreviation habits. Both teams updated their own tool by hand, on their own cadence, with their own vocabulary. Any exchange built on name matching would rot at the speed of renaming, which the previous CSV experiment had demonstrated empirically.

One more finding shaped the design: the two tools disagreed about attributes as well as existence. Lifecycle status was the sharpest case — operations marked things retired when the last support contract ended; architecture marked them retired when the business stopped depending on them. Both definitions are legitimate, and they differ by years. Reconciling the lists without deciding who owns which fact would just synchronise the confusion.

Ownership before plumbing

So the first deliverable was not a script but a one-page ownership agreement, negotiated in two workshops and blunt enough to survive contact with both teams. For every shared attribute, exactly one side is authoritative. Operations owns operational reality: support group, support contracts, incident volumes, deployment instances, operational status. Architecture owns architectural meaning: capability links, classification, integration relationships, target-state decisions, and the architectural lifecycle. Where both concepts exist — as with lifecycle — both fields exist, clearly labelled, each maintained by its owner and visible to the other side.

From ownership, the flow directions followed mechanically. Operational attributes flow from ServiceNow into Sparx EA, so architects see yesterday's support reality against every component — nightly is current enough for lifecycle decisions, and honest about being a snapshot. Architectural identity flows the other way only as a reference — the EA GUID written back to the CI, so ServiceNow always knows which architectural element a CI belongs to. Nothing else flows toward ServiceNow: we resisted, politely and repeatedly, the suggestion that the exchange should also push capability data into the CMDB, because every additional writing direction multiplies the ways the exchange can corrupt something.

And one rule sat above all of it, written in the agreement in bold: no silent writes. Anything the exchange changes is logged per run, per element, per field, with before and after values; anything ambiguous changes nothing and lands in a report for a human. The previous CSV incident had taught the organisation what automation without that rule costs, and rebuilding trust meant the pipeline had to make that class of accident as hard as design can make it, and loud whenever anything came close.

The identifier is the design

Everything durable in this engagement reduces to one decision: matches are made on identifiers, never on names. Each matched pair is joined both ways — the CI's sys_id stored as a tagged value on the Sparx EA component — a set of sys_ids where per-site CIs roll up to one component, with roll-up rules for the operational tags (worst status wins, earliest contract end wins) — and the component's GUID stored in a custom field on each CI. Once the pair exists, either side can rename, rebrand and abbreviate freely; the join survives, because the join was never about the words.

The pairing itself is therefore a one-time event per application, made carefully, and treated as a small act of governance rather than a technical step. That is also why the initial matching — nine hundred candidates against six hundred — deserved and got its own phase of the project, described below, rather than being a side effect of the first synchronisation run.

A nightly exchange with no silent writes

The pipeline itself is deliberately unexciting. Each night, a script pulls the application CIs and the fields in scope from ServiceNow's REST table API into a staging file — plain JSON, kept for ninety days, because a dated series of snapshots answers "what changed and when" questions that neither tool answers well on its own. Nothing reads the CMDB live during the day, and nothing ever writes to it except the one field carrying the EA GUID.

A comparison stage then classifies every record into one of four buckets. Matched and clean: the identifiers pair up and the operationally owned attributes agree — nothing to do. Matched but diverged: the pair exists but an owned fact changed — support group moved, contract ended, status shifted — so the change is applied to the EA side's operational tagged values and logged — unless the same field was also hand-edited on the EA side, in which case it goes to the monthly session instead of being overwritten. New in ServiceNow: a CI with no EA partner, queued for a human decision. Missing in ServiceNow: an EA component whose CI has vanished from the export, queued likewise. Only the first two buckets ever touch the repository automatically, and only within operations-owned fields; the script physically has no code path that writes an architecture-owned attribute.

Every run ends with a reconciliation report: what changed, what is queued, and the trend of the queue sizes. The report is short by design — a page on a normal night — and the first thing we tuned when it wasn't, because a report nobody reads is the first step back to two diverging lists.

What crosses, field by field

The field scope was kept deliberately narrow — every field in the exchange is a maintenance commitment, and the temptation to synchronise everything visible is how integrations grow until they break. The first release carried six exchanged fields — five operational facts flowing in, the GUID flowing out. A year on, the exchanged set has grown to nine; each addition argued its case against the same two questions the originals answered: who owns it, and who acts on it on the other side.

The last row is a design statement, not an omission. Architectural meaning stays in the repository where it is made; the CMDB reaches it through the GUID, rendered on the CI as a link that opens the element in the repository's web view. That link, not a copied field, is what "visible both sides" means for the architectural lifecycle. The narrowness is also what kept the ownership agreement enforceable — with six fields, "who owns this fact" has a crisp answer for every one; with sixty, it would have decayed into folklore within a quarter.

Matching nine hundred to six hundred, once

The initial pairing took about six weeks of calendar time and a fraction of that in effort, run as a weekly review rhythm. The script proposed candidate pairs by normalised name and vendor, ranked by confidence; a small group — one architect, one CMDB owner — confirmed or rejected them in batches. Confirmed pairs got their identifiers written both ways. Nothing was ever paired automatically: high-confidence suggestions made the sessions fast, but every join in the estate has a human decision behind it, which mattered enormously for trust and cost perhaps three afternoons of confirmation time, on top of the script's preparation and a handful of disputed application boundaries that took their own conversations.

The rejects were more interesting than the matches. Class rules emerged for the CIs architecture legitimately ignores — agents, utilities, per-site instances roll up to one component with an instance count — and those rules went into the comparison script so the buckets stay clean permanently. The unmatched residue on both sides became a worked-through list with a decision on every line: register it, model it, or retire it. The data warehouse got its CI. Three applications got retirement plans instead, having been found running with no owner on either list.

Implementation against the automation API

On the Sparx EA side, everything runs through the automation API in the manner we describe in our complete guide to Sparx EA automation: the script resolves components by GUID, updates tagged values in the operations-owned set, and appends to a change log the repository itself carries, so the audit trail travels with the model. Components stay exactly where the architects put them — the exchange adorns the architecture; it does not reorganise it.

Two safeguards did more for adoption than any feature. A dry-run mode produces the full would-change report without touching the repository, and it ran nightly for three weeks before the first real write, with both teams reading the output — by the time writes were enabled, the pipeline had already demonstrated three weeks of restraint, which is how you buy back trust after a CSV incident. And a circuit breaker halts the run entirely if the proposed change volume exceeds a threshold, or if an in-scope field comes back empty across a large share of records — a broken export, not a mass change, on the theory that a night where four hundred applications change support group is not a busy night but a broken export, and a stopped pipeline is a phone call while a wrong one is a month of cleanup.

The scripts themselves are small — the export, the comparison and the EA writer together are a few hundred lines — and the client's own team maintains them now. The modest size is the point: the engineering difficulty of this integration was never the code; it was the fifteen decisions about ownership, direction and failure behaviour that the code merely enforces.

The first month in production

The first live month behaved the way first months do, and the design absorbed it. The opening week produced an ugly spike of diverged records — several dozen a night — which turned out to be the CMDB team's own cleanup of contract data colliding with the exchange noticing every correction. Expected in hindsight, alarming on day three, and exactly what the reconciliation report was for: the spike was visible, explicable and gone within the fortnight, and it left both teams more confident in the pipeline rather than less, because every one of those changes was in the log with its before and after values.

Night nineteen was the real test. A ServiceNow platform upgrade deprecated one of the fields the export read, and the upgraded table returned it empty; the export ran, the comparison found ninety per cent of records apparently missing a value, and the circuit breaker did the only correct thing: it stopped, changed nothing, and paged the CMDB owner. The fix took twenty minutes the next morning. Under the previous integration philosophy, that night would have blanked a tagged value across six hundred components and the cleanup would have taken a week — the comparison was lost on nobody, and the incident retired any remaining internal debate about whether the breaker's threshold was too cautious.

By week six the exchange had become infrastructure: unremarkable, watched by its report, mentioned only when its numbers moved. That is the correct end state for this kind of plumbing, and reaching it in six weeks was a direct dividend of the three dry-run weeks that preceded it.

Who resolves what

The buckets only work because each one has an owner with a cadence. New-in-ServiceNow goes to the application steward on the architecture side, who decides weekly whether each item is model-worthy under the class rules or gets excluded by them. Missing-in-ServiceNow goes to the CMDB owner with the opposite question. Diverged records that the script cannot resolve — conflicting edits within the same owned field — land in a monthly session that has never yet needed more than half an hour, usually because the answer is "the contract genuinely ended".

That unmatched count is on both teams' dashboards, and it has stayed in single digits since the fourth month. When it spikes, something organisational happened — an acquisition's systems arriving in the CMDB, typically — and the spike is the alert.

The class rules get a quarterly review of their own, because they encode a boundary that moves. Twice in the first year, a category the rules excluded turned out to matter architecturally — a family of property-level middleware instances that had grown a shared dependency, and a "utility" that had quietly become the group's certificate authority. Both reviews moved the line, promoted the CIs, and left a dated note in the rules explaining why. An exclusion rule without a review cadence is how the next blind spot gets institutionalised; the cadence is cheap and has paid for itself both times it fired.

One list, and what it made possible

The stalled portfolio review reconvened three months in, and the opening debate about whose list to trust simply did not happen, because the lists agree and can prove it. That alone repaid the work, in the client's own assessment. But the durable value shows up inside Sparx EA, where every application component now carries operational fact, at most a day old, alongside architectural judgement: an architect assessing a capability sees the support group, the contract end dates and the operational status of every supporting application without leaving the repository, and impact analysis stopped being an exercise in stale data.

The retirement pipeline benefited most concretely. Cross-referencing architectural lifecycle intentions with operational reality surfaced a steady stream of candidates — applications architecture had marked for retirement that operations was still paying to support, and vice versa. A dozen retirements in the first year traced directly to the exchange making that mismatch visible, and the three ownerless applications found during matching were only the first.

Operations gained the reverse view: from any CI, the EA GUID leads to the component, its capabilities and its target-state fate, which quietly improved change risk assessment — a change request against an application marked for decommissioning in six months now looks different in the queue. Neither team changed tools, which was the promise the whole design kept: the integration respects both, and each keeps mastering what it masters. Designing that respect is the heart of our Sparx EA consulting work on repository integrations.

What we would do differently

We deliberately did not import CI dependency relationships, and we stand by it — with a refinement. ServiceNow's discovered dependency data was rich, voluminous and noisy: server-to-process links, transient connections, duplicates from overlapping discovery sources. Importing it wholesale would have buried the architects' curated integration model under discovery exhaust, so the first release imported no relationships at all. What we would change is the timeline for the second step: a year later, a narrow import of two curated dependency types, human-reviewed like the original matching, proved genuinely useful for outage impact views, and we would plan that phase from the start rather than discovering it. The limitation is real, though — an architecture repository cannot absorb a discovery tool's output unfiltered, and any integration that pretends otherwise trades a naming drift problem for a noise problem.

We would also version the ownership agreement the way we version code. It lived for the first year as a document with a date, which worked until the first genuine dispute about whether an amendment had been agreed — the extended field scope was reconstructed from meeting notes when it should have been a numbered revision history from day one. It is a one-page document; giving it a change log costs nothing and ends a category of argument. The agreement now lives in the repository itself, attached to the exchange's own model element, which is where the description of an integration between two tools probably always belonged.

The other honest note is effort distribution: the class-model mapping — deciding what a "business application" means across two tools with different ontologies — consumed more workshop time than every script combined. We now open engagements of this shape with that mapping, not with the API documentation.

If your organisation runs a CMDB and an architecture repository that tell different stories — or is cleaning up after an integration attempt that wrote first and asked questions later — 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.