CelinQ Insights · No. 72

AI-Assisted Refactoring for Enterprise Architect: Rename, Move and Restructure Safely

A model that has grown for two years usually needs tidying, not rebuilding. The trouble has always been that tidying it by hand is exactly risky enough that people leave it alone.

Every long-lived Enterprise Architect repository accumulates the same kind of debt. A naming convention that made sense two reorganisations ago is now inconsistent with the one the rest of the portfolio uses. A package that started as a tidy grouping of three related components has grown, additions creeping in over months, into a sprawling catch-all that nobody would design that way if they were starting fresh. Two components that were created independently by two different teams, months apart, turn out on close inspection to represent the same underlying application under two different names. A single monolithic component has quietly absorbed responsibilities that would be far clearer as two or three smaller ones. None of this is a modelling mistake in the sense of anyone doing something wrong. It is simply what happens to any structure that grows incrementally under real deadline pressure, in a repository touched by several people over a long stretch of time, without anyone having the mandate or the appetite to stop and clean it up.

The reason it stays uncleaned is not that architects do not notice. Most experienced architects can point at the messy corners of their own repository without hesitation. The reason is that the cleanup itself is dangerous in a way that discourages starting it. Renaming an element that is referenced from a dozen diagrams, several tagged values and an external requirements-traceability spreadsheet is not a cosmetic edit; it risks quietly breaking every one of those references if it is done carelessly, and Enterprise Architect gives you very little visibility, in the moment, into exactly how far the blast radius of a single rename actually extends. Moving a subtree of components into a different package can silently change the effective scope of relationships that were implicitly relying on package boundaries. Consolidating two duplicate components into one means deciding, correctly, which relationships, tagged values and diagram appearances survive the merge and which are now redundant. Each of these operations is individually well understood by an experienced architect. Doing dozens of them correctly, across a repository with thousands of elements, without missing a reference or silently orphaning a relationship, is a different kind of task altogether, and it is exactly the kind of task most teams quietly decide is not worth the risk relative to the benefit.

Naming the operations that make up a refactor

It helps to be precise about what "refactoring a model" actually consists of, because it is not one operation but a small, recognisable set of them, each with its own failure mode if done by hand. A rename across the model changes an element's name everywhere it is displayed or referenced, which sounds trivial until you remember that names sometimes leak into tagged values, documentation text and external references that a simple find-and-replace inside EA will not reliably catch. Moving a subtree relocates a package and everything beneath it to a new parent, which is safe for the elements themselves but can quietly change what "local" means for any relationship or rule that assumed the old package boundary. Consolidating duplicates merges two elements that represent the same real-world thing into one, carrying forward the relationships and tagged values that matter and retiring the element that does not survive. Splitting an overloaded component pulls a single element that has accreted too many responsibilities apart into two or three more focused ones, redistributing its relationships accordingly. Each of these is a legitimate, common piece of architectural housekeeping, and each of them, in a large repository, touches far more of the model than the single element or package where the change appears to start.

A worked scenario: two payment gateways that turned out to be one

It is easier to see why any of this matters with a concrete case rather than an abstract description. Imagine a portfolio repository maintained across two teams over eighteen months, where one team modelled a PaymentGateway component during an early integration project and, a year later, a second team, working on a different initiative and unaware of the first component, modelled a PaymentProcessingService that turns out, on inspection, to represent exactly the same underlying application. Both elements have their own relationships — the first connects to an order-management system and a fraud-detection interface; the second connects to a settlement service and carries tagged values recording its hosting environment that the first element never captured. Both appear on separate diagrams that different stakeholders review regularly. Nobody planned for this duplication; it simply happened, the way it always does in a model maintained by more than one team over more than one project.

An architect who spots the overlap and wants to consolidate the two is, under the old way of working, facing exactly the kind of task described earlier: find every relationship either element participates in, decide which survive under a single identity, update every diagram that shows either one, and do all of this without missing a reference buried in a package neither the architect nor their reviewer regularly opens. Framed as a refactoring request instead — "these two elements represent the same payment gateway; consolidate them, keeping the settlement relationship and the hosting tagged values from the second and the fraud-detection interface from the first" — the same task becomes a proposal an architect reviews rather than a manual audit an architect has to perform from scratch. The preview surfaces both sets of relationships side by side, flags the tagged-value conflict explicitly rather than silently picking one side, and lists every diagram that will need the surviving element's identity in place of the retired one. The architect's actual judgement — is this really the same gateway, and which side's data should win where the two disagree — is exactly the part the tool cannot and should not make for them; what it removes is the much larger amount of time that used to be spent simply finding everything that judgement needed to be applied to.

Where the request starts, and where it does not end

The refactoring workflow in CelinQ begins the same way the rest of its AI-assisted features do: an architect describes an intent in natural language, from inside Enterprise Architect through the add-in's Ask CelinQ AI entry point or against a selected package through Generate into Selected Package, and CelinQ retrieves the model context relevant to that intent — the element or package in question, and, critically for a refactor, every relationship, tagged value and diagram reference that touches it. This is the detail that separates a useful refactoring proposal from a dangerous one: the proposal is not built from the element in isolation, it is built from the element and its full footprint in the model, because a rename or a merge that does not account for that footprint is not actually safe, it is just quiet.

What comes back is a proposed semantic change set, not an edit already applied. For a rename, that means every place the old name is referenced, together with what the new name will be. For a subtree move, it means the new parent package and an explicit list of everything that moves with it. For a consolidation, it means which of the two elements is treated as the surviving identity, which relationships and tagged values carry over, and which duplicate is marked for retirement rather than silently deleted. The proposal is deliberately exhaustive rather than terse, because the entire point of asking for help with a refactor is to see the blast radius laid out in front of you before committing to it, not to get a shorter version of the risk you were already worried about.

Impact preview before anything moves

Nothing in this process writes to the repository until an architect has reviewed a preview of the proposed change set against the actual current state of the model. The preview answers the question that made the refactor risky in the first place: exactly what does this touch? For a rename, it lists every diagram, relationship and tagged value that carries the old name and will carry the new one. For a subtree move, it shows what leaves its current package and what, if anything, would be left behind because it turned out to be referenced from outside the subtree in a way that makes moving it less clean than it first appeared. For a consolidation, it shows, element by element and relationship by relationship, what survives under the merged identity and what is retired — which is often the moment an architect realises that two elements that looked identical from the outside actually differ in one tagged value that matters, and the merge needs to be adjusted rather than accepted as proposed.

This preview step is not a formality bolted onto an otherwise automatic process. It is the actual point at which architectural judgement is exercised. A tool that renamed, moved or merged elements the instant a request was phrased clearly enough would be optimising for the wrong thing — speed over correctness, in a context where correctness is the entire reason the manual version was too risky to attempt. The preview is where an architect gets to say, correctly, that the proposed consolidation is missing a relationship that matters, or that the subtree move should exclude one component that turns out to have a life of its own outside the package it currently sits in, before any of it becomes part of the model's history.

The risk in a large refactor was never the individual rename or move. It was never being sure you had found everything that operation actually touched. A preview that lists the full footprint before anything changes removes exactly that uncertainty, which is the uncertainty that made people leave the mess alone.

Preserving stable identity through the operation

What makes a rename, a move or a consolidation safe to apply as a single coordinated operation, rather than as a manual sequence of individually risky edits, is that CelinQ tracks elements by a stable underlying identity rather than by name or by location in the package tree. A rename changes a label; it does not change which element every relationship in the model is pointing at, because those relationships were never keyed on the name in the first place. A subtree move changes a parent package reference; it does not sever or reinterpret the relationships the moved elements participate in, because those relationships are recorded against the elements' stable identities, not against a path that happened to include the old package. This is the same principle that underpins how CelinQ handles rename-plus-move situations arising from concurrent edits during synchronisation, and it is what makes a deliberate, AI-proposed refactor and an accidental concurrent rename-and-move from two different people resolvable by the same underlying mechanism rather than two entirely different code paths.

Consolidation is the one operation in this set that does genuinely retire an identity — the duplicate that does not survive the merge is not simply hidden, it is recorded as retired, with a clear trace to the surviving element it was merged into, so that anything still pointing at the old identity by way of an external reference or a stale bookmark can be traced forward rather than simply failing to resolve. This matters more than it might seem, because a merge that behaves as a plain deletion of one side loses exactly the kind of provenance a later audit or a later "why did this application disappear" question needs.

One transaction, not a hundred small ones

A refactor that touches forty relationships across a dozen diagrams is, structurally, forty or more individual model changes. Applying them as forty independent edits would create a moment, mid-operation, where the model is genuinely inconsistent — half-renamed, half-moved — and would leave an audit trail that looks like forty unrelated small edits rather than one coherent, intentional restructuring. CelinQ groups the approved change set into a single Fusion transaction, so that the entire refactor lands as one coherent revision in the model's history, and so that anyone reading the revision log later sees a single, named operation — "renamed PaymentGateway to PaymentGatewayService across 14 references" — rather than a confusing cluster of unrelated-looking small changes that happen to have landed in quick succession.

This grouping also matters for how the change interacts with anyone else working in the model at the same time. If a colleague is concurrently editing an element caught up in your refactor, Fusion's ordinary three-way merge handles the collision the same way it handles any other concurrent edit — most of a large refactor's forty-odd changes will not collide with anything a colleague happens to be doing at the same moment, and the ones that genuinely do are surfaced as a normal conflict rather than silently overwritten by whichever side happened to synchronise last. A refactor is deliberately not treated as a special, privileged kind of change that bypasses the model's ordinary safety net; it is a large, coordinated, human-approved change set that goes through exactly the same reconciliation machinery as everything else.

Rollback and the revision history behind it

Because a refactor lands as a single named revision rather than a scattering of untraceable small edits, it is also straightforward to reason about afterwards, in the same way any other revision in the workspace's ordered history is. If a consolidation turns out, on reflection, to have merged two elements that a domain expert insists were genuinely distinct, the revision history shows exactly what that revision changed, which makes it possible to have an informed conversation about reverting it or adjusting it, rather than trying to reconstruct forty scattered edits from memory to figure out what a "refactor" even did. This is not a promise that every refactor is free of judgement calls — consolidation in particular is a genuinely subjective decision in ambiguous cases, and no amount of tooling turns that judgement call into a purely mechanical one — but it is a promise that the judgement call, once made, is visible, attributable and reversible rather than buried.

Human approval, every time

It is worth restating the shape of the pipeline explicitly, because it is the property that makes AI-assisted refactoring defensible rather than merely convenient: the architect's request goes to CelinQ, which retrieves the relevant model context and proposes a semantic change set; CelinQ validates that proposal deterministically against the current model; a human reviews the preview and approves it, adjusting scope where the proposal got something wrong; only then does the approved change set become a canonical revision, grouped into a single Fusion transaction, that synchronises down to local EA repositories through the add-in exactly like any other change. At no point does an AI model write directly to repository rows, and at no point does an ambiguous consolidation or an uncertain rename get auto-committed on the strength of a confident-sounding suggestion. The proposal can be wrong, or incomplete, or based on a misunderstanding of what an architect actually meant, and the preview step exists precisely because that is a realistic possibility, not an edge case being guarded against for form's sake.

The core works without any of this

None of the AI-assisted part of refactoring is required for CelinQ to function. Renaming, moving and consolidating elements by hand inside Enterprise Architect, then letting Smart Sync and Fusion reconcile the result with everyone else's concurrent work, has always worked and continues to work identically whether or not AI assistance is configured for a workspace. The AI-assisted proposal step is an accelerant for finding and scoping the footprint of a refactor correctly, not a prerequisite for doing one safely. Every capability that actually enforces safety — stable identity tracking, deterministic three-way merge, transaction grouping, revision history — is part of the deterministic Fusion core and has no dependency on AI whatsoever. AI is switched off by default in every workspace; an administrator enables it explicitly in the Control Plane, per capability, and a restricted workspace can leave it disabled entirely, with sovereign mode blocking any external AI path outright, while refactoring by hand, synchronisation, conflict resolution, monitoring and audit continue to work exactly as they do everywhere else.

The honest limits

A proposed refactor is only as good as the model context it was built from, and a model with thin or missing relationship data will produce a proposal that understates the true footprint of a change, not because the reasoning is wrong but because the evidence it had to work from was incomplete. This is a real limitation, and it is not one that better prompting solves; it is a reason to treat the preview as a starting point for the architect's own knowledge of the domain, not a substitute for it, particularly for older packages where documentation habits were looser than they are today. Consolidation is the operation most exposed to this risk, because deciding that two elements are "the same" is ultimately a domain judgement, and a proposal that gets the surface signals right — similar names, overlapping relationships — can still be wrong about the underlying intent in a way only a person with real context can catch.

There is also an organisational risk worth naming, separate from the mechanics: making large-scale restructuring cheap and low-friction removes a natural brake that used to exist, however imperfectly, in the form of "this is too risky to attempt casually." A team that refactors aggressively because it is now easy can accumulate a different kind of churn — a model whose structure keeps shifting under people who are trying to build a stable mental map of it — and that churn has its own cost even when every individual refactor was executed correctly and safely. The tool removes the mechanical risk of restructuring. It does not, and should not be expected to, replace the governance conversation about how often restructuring should happen and who gets to decide it is warranted. That conversation stays a human one, exactly as it should.

Finally, a refactor proposal is bounded by what the model can express about intent. A rename that is proposed because two names look similar can occasionally be proposed for the wrong reason — two elements that happen to share a naming pattern by coincidence rather than by representing genuinely related concepts — and the preview step exists exactly to catch that kind of false positive before it becomes a revision. The tool is deliberately conservative about what it treats as evidence: it works from the relationships, tagged values and structure actually recorded in the model, not from an assumption about what an architect probably meant. Where the model's record is ambiguous, the honest outcome is a proposal that flags the ambiguity for a human decision rather than one that guesses confidently and hopes the guess was right.