Connecting Enterprise and Solution Architecture

Two tools, two truths

A pharmaceutical company ran its architecture on two tools, for reasons that were individually sound. LeanIX held the application portfolio: every application as a fact sheet, with lifecycle, ownership, business criticality and cost data, maintained by a small enterprise architecture team and consumed by IT management. Sparx EA held the solution architecture: integration designs, data flows, deployment views, built by solution architects embedded in delivery programmes, several of them heavily regulated systems where design documentation is not optional.

Each tool was the right one for its audience. LeanIX gave management a portfolio view that Sparx EA's reporting would have laboured to produce; Sparx EA gave solution architects a modelling depth that fact sheets cannot hold. The problem was the space between them. The same application existed in both tools under names that had drifted apart, with lifecycle states that disagreed, and with no link from the fact sheet a portfolio decision was based on to the solution models describing what the decision would actually disturb.

The two teams had discussed replacing one tool with the other and rightly abandoned the idea; neither tool covers the other's ground. What they asked us for was an integration: a designed, governed connection that would let each tool keep its strengths while ending the double bookkeeping. Our role covered the integration design, the mastership and identity rules underneath it, and a first working implementation of the exchange, drawing on the kind of automation work we describe in our guide to the Sparx EA automation API.

What the drift was costing

Before designing anything we spent a week measuring the divergence, because "the tools disagree" persuades nobody and a table of disagreements persuades everyone. We exported the LeanIX application fact sheets — around five hundred and forty at the time — and matched them against application components in the Sparx EA repository, first by the identifiers nobody had maintained, then by increasingly forgiving name matching, then by hand for the stubborn remainder.

The picture was worse than either team had guessed. Roughly one application in five existed in only one of the two tools. Among the matched majority, lifecycle states disagreed for about a hundred applications — systems marked as retiring in LeanIX that solution models showed acquiring new integrations, and in one memorable case an application LeanIX had as retired that a current design depended on. Names had drifted enough that a reader could not reliably tell whether two entries were one system. None of this was anyone's negligence; it was two conscientious teams maintaining two truths with no mechanism obliging the truths to meet.

We also timed two questions with a stopwatch, because durations argue better than adjectives. "Which solution designs does this retirement candidate appear in" took an experienced architect just over two hours, spread across both tools and a shared drive. "Who owns the system this design depends on" took twenty minutes and produced two different names. Both questions are asked weekly in an organisation this size; after the integration went live we timed them again, and neither took longer than getting a coffee.

The concrete costs followed the same pattern. Portfolio reviews were making rationalisation calls without seeing solution dependencies. Solution architects were re-asking questions — who owns this, what is its lifecycle — that LeanIX could have answered. And a regulatory inspection had recently asked for the design documentation of a system via its portfolio entry, a request that took days instead of minutes because nothing connected the two.

The mastership decision

The foundational design decision in any two-repository integration is mastership: for each attribute, exactly one tool gets to be right. Skip this and synchronisation becomes a coin toss about whose edit survives; settle it and most other questions answer themselves.

We ran two workshops with both teams and landed on a clean split. LeanIX masters the portfolio facts: the application's existence, its official name, lifecycle state, ownership, business criticality and cost attributes. Sparx EA masters the structural facts: how the application decomposes, its interfaces, its data flows, its deployment. Where a fact must appear in both tools, it flows from its master and is read-only in the other — enforced socially in LeanIX and technically in Sparx EA, where the synchronised attributes live in tagged values that the bridge maintains and reasserts on every run — EA has no field-level lock that could make a single tagged value read-only, so the enforcement is the reassertion itself.

One rule needed defending repeatedly: the application list itself belongs to LeanIX. A solution architect who needs a component for a system not yet in the portfolio does not create a free-floating one; the system enters LeanIX first, then arrives in Sparx EA at the bridge's next run — overnight, or within minutes when someone triggers the on-demand run rather than waiting. This felt bureaucratic on paper and proved painless in practice, precisely because the on-demand run was there. The rule buys the property the whole engagement existed for: there is one list of applications, and both tools display it.

Identifiers before interfaces

Synchronisation lives or dies on identity, so the unglamorous first implementation step was giving every application a durable shared key. LeanIX provides one naturally — each fact sheet has a stable technical identifier — and we carried it into Sparx EA as a tagged value on the corresponding application component. The initial population reused the matching exercise from the measurement week: the confident matches were stamped automatically over the automation API, and the ambiguous couple of hundred went through a review spreadsheet where both teams confirmed or split them by hand. Tedious, finite, and done once.

From then on the identifier, never the name, is the join. Renames — common in a portfolio where systems get rebranded — stopped mattering: the name flows from LeanIX as ordinary data while identity holds steady underneath. The identifier tag itself is defined in a dedicated profile, so it travels with XMI exports and survives model restructuring, and the bridge treats any EA component carrying an identifier that LeanIX no longer recognises as an incident to report, not an entry to delete. Deletion is a human decision in this design; the scripts only ever flag.

The attribute map in detail

The mastership principle only becomes real when it is written down attribute by attribute, so the design document's centrepiece was a plain mapping table, agreed line by line in the second workshop. An abbreviated version, close to what shipped:

Two details in the table did more work than their size suggests. Criticality arriving as a tagged value let us wire a diagram legend to it, so solution views could colour components by portfolio importance without anyone maintaining colours by hand. And the "editable in EA: no" column is enforced, not advisory — the bridge reasserts mastered values on every run, so a well-meaning local correction lasts at most a day and the correction conversation happens where it belongs, in LeanIX. People learned the rule fastest by watching the tool politely undo them.

Suites, platforms and other awkward cases

Every portfolio integration meets the same three awkward customers, and pretending the clean model covers them is how integrations rot. We handled each explicitly in the design document.

Suites first: the ERP existed in LeanIX as one fact sheet, while the solution repository sensibly modelled its finance, procurement and manufacturing modules separately. We allowed a one-to-many mapping for exactly this case — module components carry the suite's identifier plus a module qualifier, the bridge treats the suite as the unit of portfolio truth, the name-overwrite rule applies only to one-to-one mappings so modules keep their own names, and the derived integration count aggregates across modules. Second, shared platforms: the integration platform and the laboratory data backbone are applications in their own right and infrastructure to everyone else. The temptation is to hang every consumer off them with dependencies, which turns diagrams into hairballs; instead their flows were modelled only where a specific, named exchange exists, and their fact sheets carry a platform marker so portfolio reports can treat them separately. Third, the things LeanIX tracked that have no structural existence at all — a licence bundle, an outsourced service with no distinct system behind it. Those simply do not cross the bridge; a filter list in configuration names the fact sheet types that become components, and everything else stays portfolio-only.

The common thread is that each awkward case got a written rule rather than a per-instance improvisation. When a new architect asks why the ERP looks different from everything else, the answer is a paragraph in the design document, not archaeology.

The bridge itself

The implementation is deliberately modest: a scheduled bridge, written in Python, that runs nightly and can be run on demand. It reads from the LeanIX GraphQL API — fact sheets, their attributes, their relations — and talks to the Sparx EA repository through the automation interface. Each run walks the LeanIX side, resolves each fact sheet to its EA component by identifier, and applies the mastership rules: new applications become new components in a designated portfolio package, changed attributes update their tagged values, retirements set a lifecycle tag that the diagram legend colours amber on every view using it, rather than deleting anything.

The return direction is thinner by design. Sparx EA does not push structure into LeanIX — fact sheets have no use for deployment nodes — but it does push back two things the portfolio side wanted: a link, on each fact sheet, to the corresponding solution documentation, and a small set of derived facts such as the count of modelled integrations per application, which turned out to be a surprisingly good conversation starter in portfolio reviews. An application whose fact sheet says "retiring" while wearing forty modelled integrations invites exactly the right question.

We resisted the temptation to make the bridge clever. No conflict-resolution heuristics, no bidirectional merging, no diagram generation. Every behaviour is a stated rule both teams signed, and the code is short enough that their own automation engineer read it end to end at handover. Integration scripts of this kind are infrastructure; boring is the compliment to aim for.

Two implementation choices earned their keep in the first month. The bridge processes the portfolio in stable order and writes an explicit action plan before touching the repository, so a dry-run mode came for free: the same code, with the write step disabled, produces the full list of what tonight's run would do. Both teams used dry runs heavily while trust was being established, and the mode remains the standard way to preview the effect of a portfolio clean-up. And every value the bridge writes is compared before it is written, so an unchanged attribute produces no update, no baseline noise and no misleading modification date in EA — a small courtesy to everyone who later asks the repository what changed and when, and one that keeps the repository's history honest under automation.

Reconciliation, not blind sync

Every run ends with a reconciliation report, and the report is honestly the half of the deliverable the teams value most. It lists, in a short fixed format: applications new to LeanIX and therefore newly created in EA; attribute changes applied; EA components whose identifier no longer resolves; solution models referencing applications marked retired; and name collisions where a human should look. The report lands in the shared channel both teams read, and its normal state is nearly empty.

The report also gave the integration its governance rhythm without inventing meetings. The two teams already met monthly; the reconciliation summary became a standing five-minute item, and the handful of structural questions it raises — should this cluster of components be one fact sheet or three, is this retired system genuinely still integrated — get settled there, by the people who own the respective truths. In the first quarter the report drove the correction of the hundred lifecycle disagreements found during measurement; since then it mostly confirms that the two tools agree, which is the point.

Operating the bridge

An integration that only its authors can operate is a liability with a delivery date, so the handover was designed into the build. The bridge runs as a scheduled task on a server the client's automation engineer owns, with its LeanIX token and repository credentials in the company's standard secrets store rather than in configuration files. Every run writes a log with one line per action taken and ends by writing the reconciliation report; a run that fails part-way leaves the repository untouched for the entities it had not yet reached and says exactly where it stopped — the actions are idempotent, so the recovery procedure is the least dramatic one available: fix the cause and run it again.

The failure modes we planned for were the boring, likely ones. LeanIX API changes arrive on a deprecation schedule, so the bridge pins its query shapes and the runbook includes a quarterly check against the announced changes. The EA repository being locked for maintenance simply skips the run and says so. And the one genuinely dangerous scenario — a mass change on the LeanIX side, such as a bulk re-lifecycling during a portfolio clean-up — is guarded by a threshold: if a run would touch more than a configured fraction of the portfolio, it stops and asks a human first. That guard has fired twice, both times for legitimate bulk edits, and both times the human confirmation took five minutes. Cheap insurance.

Handover itself was a working session, not a document drop: the automation engineer ran the bridge, broke it deliberately three ways, and recovered it three ways, with us watching rather than typing. Since then our involvement has been two questions by email, which is the level of dependency on us that we consider a successful exit.

What changed in daily work

For solution architects, the visible change is that portfolio context is simply present in Sparx EA. Dragging an application component onto a diagram brings its lifecycle, ownership and criticality along as tagged values, current as of last night. Solution designs began flagging their own risks — a data flow into a component whose lifecycle tag reads "phase-out" is visible at design review, not at deployment. The questions architects used to park — who owns this, is it strategic — stopped requiring a second tool or a corridor conversation.

For the enterprise architecture team, portfolio decisions acquired structural evidence. Rationalisation candidates now arrive at review with their modelled dependency counts attached, and twice in the first year the solution models overturned a retirement plan — cheaper, in both cases, than discovering the dependencies during decommissioning. The inspection scenario that had embarrassed the organisation was rehearsed deliberately after go-live: from fact sheet to current solution design in under a minute, through the link the bridge maintains.

Neither team's tool changed, and neither team's autonomy shrank; the integration added obligations only at the seam. That is, we think, why it held. Integrations between practices fail socially before they fail technically, and the mastership split gave each team full authority over exactly the facts it already cared about — the design formalised the existing division of labour instead of contesting it. The pattern generalises well beyond this pair of tools, and it is close to the approach we take when connecting enterprise architecture practices to delivery organisations generally.

What we deliberately did not synchronise

Three exclusions were argued over and are worth recording, because the requests will recur in any similar engagement.

We did not synchronise diagrams. LeanIX generates its own visualisations from fact sheet relations; Sparx EA diagrams are authored artefacts with intent in their layout. Pushing either into the other produces clutter that neither audience trusts. The fact-sheet link to the EA-generated design documentation serves the actual need, which is "show me the real design", not "show me a degraded copy of it".

We did not synchronise LeanIX's business capability model into the EA repository as editable content. It arrives read-only, in a reference package, refreshed by the bridge, so solution models can trace to capabilities without creating a second editable capability tree that would immediately fork. And we did not build bidirectional attribute merging, though it was requested more than once, usually framed as flexibility. Bidirectional merging without a mastership rule is drift with automation behind it; the whole design exists to prevent it, and we said so in exactly those terms.

Limits and lessons

The named limitation: the bridge is nightly, not real time, and the two tools can disagree for up to a day. We judged that acceptable against the alternative — event-driven synchronisation through LeanIX webhooks was designed as an option, and the organisation declined it, preferring a mechanism their own team could operate and debug. A day of drift, visibly reconciled every morning, beats a real-time integration nobody dares touch. The second limit is coverage: the matching stops at applications, plus the read-only capability tree. Interfaces exist in both tools at different granularities, and after one workshop we agreed not to force a mapping that would have been maintained by hand and believed by no one. That seam remains, documented rather than hidden.

The lesson we carry forward is about sequence. The measurement week, the mastership workshops and the identifier work consumed half the engagement before any integration code ran, and that half made the code almost incidental. Organisations tend to ask for the connector first; the connector is the last twenty percent. If your portfolio tool and your modelling tool are drifting apart — LeanIX and Sparx EA or any comparable pair — the drift is measurable in a week and fixable in a quarter, and we are happy to help with both; 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.