CelinQ Insights · No. 53

Enterprise Architect Presence Without Hard Locking

Knowing that a colleague is looking at the same diagram is often more useful than being stopped from touching it. CelinQ treats presence as information, not permission.

There is a small, specific moment that a traditional locked repository and a fully local-first one handle in almost opposite ways. An architect opens a package, and a colleague is already working somewhere inside it. In a locking system, that fact is enforced: the second architect is told, explicitly and immediately, that they cannot touch whatever is locked, and the tool refuses to let them try until the lock is released. In a purely local-first system with no equivalent mechanism at all, the second architect is told nothing whatsoever. They have no idea their colleague is even in the building, let alone the same package, and they proceed exactly as if they had the model entirely to themselves. Both of these are honest positions, and both are wrong for most teams most of the time. CelinQ's presence system exists in the space between them: it tells you what a lock would enforce, without enforcing anything at all.

What hard locking actually buys you, and what it costs

It is worth taking hard locking seriously before setting it aside, because the reasoning behind it is not foolish. A lock is a promise: while you hold it, nobody else can change the thing it covers, full stop, no exceptions, no room for two people's edits to collide because the collision is structurally impossible. That promise is genuinely valuable in narrow, specific circumstances — a financial system posting the same ledger entry twice because two processes both believed they had exclusive access is a real and serious problem, and locking exists in computing generally because sometimes the cost of a collision so far outweighs the cost of waiting that forbidding concurrency outright is the right call.

The trouble, as anyone who has waited for a Sparx Enterprise Architect element to unlock knows firsthand, is that this promise is expensive to keep and the expense is paid by everyone, not just the people who would otherwise have collided. A lock does not know whether the two people it is separating were actually going to conflict; it only knows that it cannot take the risk, so it stops both of them, even in the much more common case where their work would never have touched the same fact at all. The everyday cost of that arrangement — the blocked afternoon, the lost context, the small improvements nobody bothers to make because coordinating access is not worth it — is well documented elsewhere in this series, and it does not need repeating in full here. What matters for this article is the alternative CelinQ builds instead, and why it deliberately does not reach for the same tool.

Presence: telling people what is happening, not deciding what they may do

CelinQ's presence system is built around a simple idea: an architect's EA session periodically tells the CelinQ Server what it is currently looking at — which package, which diagram, which element, when that is known — and the server keeps a live, short-lived record of who is where. Every other client in the same workspace can see that record. Open the Control Plane's Clients view, or glance at the add-in's status surface, and you can see that a colleague is currently in the same package you are about to open, or working on the exact diagram you were planning to touch next. That is the entire mechanism. It is a heartbeat and a shared registry, nothing more elaborate than that, and deliberately so.

What that heartbeat does not do is stop you. If you know a colleague is in the same package and you decide to proceed anyway, nothing in CelinQ prevents you. There is no dialog demanding you wait, no element that refuses to open because someone else has it, no moment where the tool inserts itself between your intention and your keyboard. The information is there for you to use with judgement — perhaps you message the colleague first, perhaps you decide your changes are unrelated to theirs and continue without a second thought, perhaps you simply note it and carry on — but the decision remains entirely yours. This is the crucial difference in kind, not just in degree, between presence and locking: a lock makes a decision on your behalf and enforces it; presence gives you the information a sensible person would want in order to make that decision themselves.

Why this works without becoming reckless

The obvious worry is that removing enforcement removes safety along with it, and it is worth explaining directly why that worry, while reasonable on its face, does not hold up against how CelinQ actually protects the model. Presence is advisory information layered on top of a system that already does not depend on avoidance to stay correct. Underneath presence sits Smart Sync, which propagates changes quickly enough that most potential collisions never get the chance to happen at all, and underneath that sits CelinQ's Fusion merge engine, which resolves the collisions that do occur deterministically, at the level of individual model facts rather than whole elements, and only escalates to a human the narrow set of cases where two people genuinely changed the same fact in incompatible ways. Presence is not the last line of defence against a corrupted model. It never was designed to be. Its job is much smaller and much more human: to give an architect the same situational awareness a colleague sitting at the next desk would have simply by glancing over, restored for a world where the colleague might be in another office or another country.

Think about what actually goes wrong without any awareness mechanism at all, in a purely local-first system with no presence whatsoever. Two architects can spend an entire morning independently restructuring the same corner of a model, each unaware the other is there, and by lunchtime they have produced two versions of the same intention pulling in different directions — not a technical conflict Fusion cannot resolve, necessarily, but a wasted morning and a human coordination failure that no merge engine, however clever, can undo after the fact. Presence exists to prevent exactly that waste, not by stopping either architect, but by letting each of them notice the other early enough that a two-minute conversation replaces a wasted morning. That is a genuinely different failure mode from data corruption, and it deserves a genuinely different remedy than a lock.

What CelinQ actually tracks, and how quickly it forgets

The mechanics are kept deliberately lightweight, because presence that is expensive to maintain or that lingers past its usefulness stops being a convenience and starts being a liability of its own. Each connected client sends a small heartbeat to the server carrying its client identity, the EA version it is running, and its current location in the model when EA can report one — a package, a diagram, an element. The server holds this information in memory only, with a short time-to-live, thirty seconds by default. If a heartbeat is not refreshed within that window, the entry is treated as stale and pruned the next time anyone reads the registry.

That short TTL is doing more work than it looks like it is doing. It means presence never becomes a permanent record — a server restart clears it entirely, and no history of who was where is retained once an entry expires, which matters because presence is meant to answer "who is here right now," not to become a surveillance log of everyone's past movements through the model. It also means a client that disappears abruptly — a laptop that loses power, a network that drops without a clean goodbye — does not leave a ghost entry behind that misleads everyone else into thinking someone is still there when they are not. The entry simply ages out within thirty seconds, exactly as it would if the architect had closed EA politely. When a client does exit cleanly, an explicit removal call clears its entry immediately rather than waiting for the timeout, so the common case of someone finishing up and closing their model is reflected right away rather than lingering for the better part of a minute.

This staleness handling matters more than it might initially seem, because a naive presence system without a TTL would eventually accumulate exactly the kind of false signal that erodes trust in the whole feature. An architect who sees a colleague apparently still working on a diagram, when in reality that colleague's laptop crashed an hour ago, learns quickly to stop trusting the presence indicator at all — and once that trust is gone, the feature is worse than useless, because it now actively misleads rather than simply doing nothing. A short, honestly enforced TTL is what keeps presence trustworthy: what you see reflects who is genuinely active right now, not who was active at some point in the recent past.

Granularity: why package, diagram and element all matter separately

Presence is only useful in proportion to how precisely it answers the question an architect actually has in mind, and "someone else is in the workspace" is far too coarse an answer to be worth anything on a model of any real size. A repository with hundreds of packages and thousands of elements has dozens of people working in it on an ordinary day without any of them meaningfully being "near" each other in a way that matters, so CelinQ tracks presence at three levels rather than one: the package an architect currently has open, the diagram they are viewing or editing, and, where EA can report it, the specific element they have selected. Each level answers a slightly different question. Knowing that a colleague is somewhere inside a large package that spans an entire subsystem is only mildly useful — it tells you to be generally aware, nothing more. Knowing that they are on the exact diagram you were about to open is considerably more actionable, because it tells you the two of you might genuinely be about to look at, and possibly change, the same handful of things within the next few minutes. Knowing the specific element they have selected is the most precise signal of all, and it is exactly the signal that feeds Hot Collaboration's detection of sustained, same-diagram contention rather than the coarser package-level view.

This layered granularity also keeps the feature honest about what it does and does not know. CelinQ never claims to know what a colleague is about to do, only where they currently are, and it is careful not to blur that distinction into something that sounds more predictive than it is. An architect who has a diagram open but has stepped away for a coffee looks, from the outside, identical to one who is actively working on it — presence reports location, not intent or activity level, and the interface is deliberately built not to imply otherwise. That restraint matters: a feature that overstated its own certainty would eventually mislead someone into a false sense of safety or a false sense of alarm, and either failure mode would cost the trust the feature depends on to be useful at all.

Where presence actually surfaces

None of this is worth much if it is buried somewhere nobody looks, so presence is surfaced in the places an architect and an administrator naturally already are. Inside the Control Plane's Clients view, every connected client appears with the user, the workspace, the EA version they are running, what they currently have open, when they were last seen, and a live indicator that makes the difference between "active right now" and "connected but idle" immediately visible at a glance — useful not only for an individual architect checking before they dive into a package, but for an administrator trying to understand, at any given moment, how busy a shared workspace actually is and where the real concentration of activity sits. Inside EA itself, the add-in's status surface carries the same information down to where the architect is actually working, so that checking presence does not require switching away from the modelling tool to a separate web console in the middle of a task. The intention throughout is that this information should cost an architect a glance, not a context switch, because a convenience that requires leaving your work to check it will simply not get checked often enough to matter.

Advisory leases: the deliberately unbuilt next step

It is worth being candid about a feature that sits adjacent to presence and that CelinQ has deliberately not built yet, because the reason for the gap is more interesting than the gap itself. For high-contention situations — a diagram several architects genuinely need to work on together, in sequence, over a short period — a natural next step beyond pure presence would be an advisory lease: a soft, time-boxed, self-expiring claim that says "I am actively working here for the next few minutes," visible to everyone else, that carries social weight without carrying enforcement. This is designed for, in the sense that the shape of the feature is understood, but it has been deliberately deferred rather than shipped.

The reason for the deferral is precisely the concern this whole article has been building toward: a lease, however soft its intent, risks being read by users as a lock, and a system that lets a soft lease quietly become a hard expectation has smuggled locking back in through a side door while claiming not to have done so. Offline editing must always remain possible in CelinQ's design, and an advisory lease that someone felt obligated to respect even when honouring it meant an offline colleague could not work would be a lock in every practical sense that matters, whatever the interface called it. Building this feature well means building the social and interface cues carefully enough that "advisory" stays true in practice, not just in the documentation, and that is harder to get right than the underlying heartbeat mechanism itself. Until that balance is worked out properly, leaving the gap unfilled is the more honest choice than shipping something that quietly implies a guarantee the platform does not make.

A soft lease that people feel they must not violate is not soft. The entire value of an advisory system rests on nobody ever being structurally punished for ignoring it — the moment that stops being true, you have rebuilt a lock with worse enforcement than the one you replaced.

What this feels like day to day

Picture an architect, Nadia, about to open a package to add a new interface. Before she does, she glances at the presence indicator and sees that a colleague, Bram, is currently working on a diagram two levels inside that same package. Nothing stops her from proceeding — she is not blocked, no dialog appears, the package opens instantly exactly as it always does. But she now knows something she would not otherwise have known: someone else is actively in this part of the model right now. Perhaps she sends Bram a quick message to check whether their work will overlap. Perhaps she can see from the diagram name that he is nowhere near the interface she plans to add, and she proceeds without a second thought. Either way, the decision belongs to her, informed rather than blind, and she made it in the two seconds it took to glance at a status indicator rather than the minutes it would have taken to send a message and wait for a reply under a locking system that forced the conversation to happen before she could do anything at all.

Now picture the case where their work genuinely does collide — both of them, unknown to each other for a moment, decide to restructure the same subtree. Presence gave Nadia the chance to notice Bram was there, but suppose she did not check, or checked and judged, reasonably, that their work would not overlap when in fact it did. This is exactly the scenario Hot Collaboration is built to detect and respond to automatically — the server's presence registry itself is what notices two clients reporting the same current diagram, and that detection tightens Smart Sync's cadence specifically for that hot spot, without either architect having to notice or act on anything themselves. Presence, in other words, is not only a human-facing indicator; it is also the raw signal that other parts of CelinQ use to adapt their own behaviour automatically, which is a second reason it needed to stay lightweight and structural rather than becoming an enforcement mechanism in its own right.

Where hard locks still earn their place

Locking is not always the wrong answer, and it would be intellectually dishonest to pretend otherwise. There are narrow, specific situations within a modelling workflow where a genuinely exclusive claim on something is the right tool — a bulk migration script that must not have anyone editing the repository underneath it while it runs, a scheduled maintenance window where the organisation deliberately wants to prevent any concurrent writes, or a governance process that, for compliance reasons rather than technical ones, requires that only one designated person touch a specific artefact during a formal review. In cases like these, the thing being protected is not the ordinary flow of collaborative modelling but a discrete, time-boxed operation with a genuine all-or-nothing character, and a lock is the honest tool for that job precisely because it enforces exactly the guarantee the situation needs.

What CelinQ's design rejects is not locking as a concept but locking as the default posture for ordinary, everyday collaborative editing — the state most architects spend most of their working hours in, where the actual rate of genuine, damaging collision is low enough that the cost of universal enforcement vastly outweighs the risk it prevents. The broader argument for which of these two postures — pessimistic locking or optimistic convergence — fits which kind of team is its own subject, and it is worth reading in full, because the honest answer is not that one approach is universally correct. It is that most teams doing most of their modelling work are better served by presence, Smart Sync, and Fusion working together than by a lock that stops them for a risk that, statistically, was never going to materialise that particular afternoon — while accepting that the narrow cases where exclusivity genuinely matters deserve a different, more deliberate tool than presence was ever meant to be.