CelinQ Insights · No. 25

Knowing who else is in the model right now

Lightweight presence turns coordination from a chat thread into a glance.

There is a small ritual that plays out in almost every architecture team that shares a repository, and it is so ordinary that most people have stopped noticing it as a cost. Before touching anything of consequence — before restructuring a package, redrawing a diagram that others depend on, or renaming a set of elements that are wired into half the model — someone types a message into a chat channel. "Is anyone in the integration package right now? I'm about to reorganise it." Then they wait. Sometimes the answer comes back in seconds. More often it does not, because the people who might be affected are heads-down in their own work, not watching the channel, and the person who asked is left to make a judgement call: proceed and risk stepping on somebody, or hold off and lose the momentum they had. Neither choice is good, and the fact that the question had to be asked at all is a symptom of something the tooling should have been telling them all along.

The question behind the ritual is simple and human. Who else is in here with me? Not in the abstract, historical sense of who has ever edited this model, but right now, this minute, while I am about to make a change. It is the same instinct that makes you glance around a shared workshop before you start using the loud machine, or check whether the meeting room is occupied before you walk in with your laptop. It is not about permission and it is not about surveillance. It is about the basic courtesy and the basic safety of knowing whether you are alone or working shoulder to shoulder with someone else. Shared architecture repositories have historically been very bad at answering this question, and the absence has quietly shaped how teams behave — usually toward caution, delay, and a low background hum of coordination overhead that never quite goes away.

Why the model has always been a dark room

To understand why presence is so often missing, it helps to look at how shared modelling has traditionally worked. When several architects share a single project file on a network drive, the file itself has no notion of who is looking at it. It is a document. It knows its own contents; it does not know that three people have it open, or that one of them is deep inside a particular diagram while another is editing a package on the far side of the model. Everyone is working in the same room, but the room has no lights and no windows. You cannot see anyone else, and they cannot see you. The only way to find out whether you are alone is to make noise and listen for a reply, which is precisely the chat-channel ritual described above.

Shared database repositories improve the situation for concurrent editing, because several people really can be connected at once without the crude file-locking problems of a single document on a share. But being connected is not the same as being visible. A database can happily support a dozen simultaneous sessions and still offer no ordinary, glanceable indication of who those sessions belong to or where in the model each person is currently working. The connections exist; the awareness does not. So even teams who have solved concurrency at the storage level often find themselves back in the same dark room when it comes to the everyday question of coordination, and back to typing into chat before they dare to make a structural change.

The workarounds that grow up around this gap are revealing. Teams carve the model into territories and assign each architect a zone, partly for sensible ownership reasons but partly just so that two people are less likely to collide in the dark. They schedule "modelling windows" so that only one person is making structural changes at a time. They keep a running conversation in a chat tool that functions as an improvised presence signal — you infer that someone is active because they were talking a few minutes ago. Each of these is a rational response to a missing capability, and each carries a price. Territories make the model rigid and discourage the cross-cutting work that architecture actually requires. Scheduled windows serialise a team that could be working in parallel. And the chat channel, useful as it is for many things, is a poor substitute for presence because it is asynchronous, easily missed, and tells you what someone said rather than what they are doing.

The real cost of not knowing

It is tempting to dismiss all of this as a minor inconvenience — a few messages, a little waiting, nothing that shows up on a budget. But the cost of not knowing who is in the model compounds in ways that are worth naming precisely, because the whole point of a shared repository is to let a team work together, and a team that cannot see itself working is not really collaborating so much as taking turns.

The first cost is hesitation. When you cannot tell whether a colleague is inside the area you are about to change, the safe move is to slow down. You ask, you wait, you double-check. Multiply that hesitation across every consequential edit and across every member of the team, and you have a repository where the dominant experience is caution rather than flow. The irony is sharp: the tooling was meant to enable collaboration, and instead it induces a reflexive carefulness that makes people reluctant to touch anything shared. The bravest maintenance work — the tidy-ups, the restructurings, the renamings that keep a model coherent — is exactly the work that hesitation suppresses, because it is exactly the work most likely to collide with someone else.

The second cost is collision itself, on the occasions when the hesitation fails and two people do end up working the same area at the same time without knowing it. In a well-built collaborative system this need not be a catastrophe, because a good merge engine can reconcile independent work. But even the best reconciliation is easier and cleaner when people are not unknowingly pulling the same structure in two directions at once. Presence does not replace a merge engine; it reduces the number of times the merge engine has to do its hardest work, by letting people notice each other before the collision rather than discovering it afterward. A conflict you avoided by glancing at who was active is cheaper than a conflict you resolved carefully after the fact, even when the resolution was clean.

The third cost is subtler and, over time, the most corrosive. It is the erosion of the sense that the model is a shared, living, occupied place. When you cannot see anyone else in the repository, it stops feeling like a common workspace and starts feeling like a series of private sessions that happen to touch the same file. The social fabric of a modelling team — the casual awareness that lets people coordinate without formal process, the knowledge that a colleague is around and can be asked a quick question — depends on being able to perceive one another at work. A dark room does not just make coordination harder; it makes the team less of a team.

The question is never really "may I edit this?" It is "am I alone in here?" A repository that cannot answer the second question forces people to keep asking the first, out loud, over and over, all day long.

What presence should and should not be

Before describing how CelinQ approaches this, it is worth being careful about what a good answer looks like, because presence is one of those features that is easy to get subtly wrong. The failure modes are as instructive as the goal.

The first thing presence should not be is a management dashboard. The moment a feature that shows who is active turns into a record of who was active, for how long, and how much they produced, it stops being a courtesy and becomes surveillance, and people quite reasonably resent it. The entire value of knowing who is in the model right now depends on it being about coordination among peers, not measurement from above. A presence signal that is logged and retained is a different and more sinister thing than a presence signal that simply reflects the current moment and then forgets. The distinction is not cosmetic; it determines whether the team experiences the feature as helpful or as something to be worked around.

The second thing presence should not be is heavyweight. If knowing who is active requires everyone to check into some central coordination tool, to set their status manually, or to maintain a separate awareness application alongside their modelling, it will fall into disuse for the same reason manual change logs fall into disuse: it depends on discipline, and discipline is the first thing to go under deadline pressure. Useful presence has to be a by-product of simply being at work. You open your repository and start modelling; the fact that you are present follows automatically, and it costs you nothing to maintain.

The third property, closely related, is that presence should be ephemeral by nature. Its whole meaning is tied to the present moment. Someone is here now; when they leave, they are no longer here, and the signal should reflect that immediately and without residue. Presence that lingers after a person has gone is worse than no presence at all, because it actively misleads — you avoid an area because it looks occupied, when in fact the colleague left an hour ago. The signal must expire cleanly when someone steps away, so that what you see is always a truthful picture of the current moment rather than a stale one.

And the fourth property is that presence should be lightweight enough to glance at, not something you have to go and look up. The chat-channel ritual is slow precisely because it is a query-and-wait: you ask a question and hope for an answer. Presence done well inverts that. The information is simply there, in the periphery of your attention, the way you can tell at a glance whether a colleague's desk is occupied without having to ask anyone. Coordination becomes a glance rather than a conversation, and a glance is fast enough that it does not interrupt the flow of work.

How CelinQ handles it

CelinQ is a local-first collaborative modelling platform that works alongside Sparx Enterprise Architect rather than replacing it. Each architect edits a local repository at full speed, online or offline, and a background companion service syncs each save with a shared workspace on a server the organisation runs itself. That architecture, which was chosen primarily so that people could work fast and without depending on a live connection, turns out to give presence a natural home. Because a companion service is already running quietly alongside each architect's work, coordinating with the shared workspace, it is well placed to know who is currently connected and to make that fact visible to everyone else — without anyone having to announce themselves or maintain a status by hand.

The presence that CelinQ provides is deliberately lightweight. It shows who is active right now, so that the question that used to require a message in a chat channel is answered by a glance instead. You can see that a colleague is currently working in the shared workspace, and you can adjust accordingly — hold off on the restructuring for a few minutes, or simply go and ask them directly, now that you know they are around. The point is not to control who may do what; roles and governance handle the question of permission separately, through the Viewer, Editor, Administrator and Owner distinctions and through change review. Presence answers a different and more immediate question: are we in here together right now?

Crucially, this presence is ephemeral. It reflects the current moment and nothing more. When someone leaves, their presence expires; the signal does not linger to mislead the people who remain. There is no accumulating record of who was active when, because that is not what presence is for. What you see is a truthful picture of the present — the people who are actually here, now — and when they go, they are simply no longer shown. This is a deliberate design choice, not a limitation. A presence signal that expires cleanly is one that people can trust and one that never curdles into a monitoring tool.

It is worth being honest about what presence does and does not do, because overselling it would misrepresent how the platform actually holds together. Presence does not prevent two people from editing the same part of the model at the same time, and it is not meant to. In a local-first system where people work online and offline and sync when they can, you cannot and should not try to stop concurrent work; that would reintroduce exactly the serialisation and territory problems that make shared files so frustrating. What handles genuine concurrent change is the merge engine, CelinQ Fusion, which reconciles independent work deterministically at the level of individual model facts, isolates real conflicts for a human to settle rather than silently picking a winner, and never resorts to last-write-wins. Presence and merging are complementary. Presence reduces how often people collide by letting them see each other; Fusion ensures that when they do collide, the collision is handled honestly and reproducibly rather than by one person's work quietly overwriting another's.

That division of labour is the key to understanding why lightweight presence is enough and why a heavier mechanism would be a mistake. If the system relied on presence to prevent conflicts — by locking areas that someone else was viewing, say — it would be back in the world of file locks and modelling windows, forcing a team to serialise work that could be parallel. By keeping presence light and letting Fusion do the reconciliation, CelinQ gets the human benefit of awareness without the operational cost of enforced exclusivity. You see who is around; you coordinate as peers if you want to; and the merge engine guarantees that even uncoordinated concurrent work comes back together cleanly and reviewably.

What changes when you can see the room

The difference this makes is not dramatic in any single moment, which is exactly why it is easy to underestimate. It shows up as the quiet disappearance of a whole category of friction. The pre-emptive chat message before a structural change becomes unnecessary, because you can simply see whether anyone is in the area you care about. The hesitation before a consequential edit shrinks, because caution has been replaced by information. The scheduled modelling windows and rigid territories start to feel like solutions to a problem the team no longer has, and can be relaxed in favour of the more fluid, parallel working that architecture genuinely benefits from.

There is also a change in the texture of the team's collaboration that is harder to quantify but easy to feel. When you can see who else is present, the model stops being a dark room and becomes an occupied, shared space again. You know your colleagues are around; you can catch them for a quick question because you can see they are active; you get the ambient, low-effort coordination that people in the same physical room take for granted and that distributed teams so often lose. This matters especially for organisations whose architects are not all in the same building, or the same country, or the same time zone as one another for the whole day. Presence gives back a little of the awareness that physical proximity used to provide for free, and it does so without any of the surveillance connotations that make people wary, because it is ephemeral and peer-facing by design.

None of this asks the architect to change how they work. That is the point worth holding onto, because a skeptical reader has heard the promise of frictionless collaboration before and been handed a tax on every edit in return. In CelinQ, you open your local repository and model exactly as you always have, at full speed, online or offline, alongside Sparx Enterprise Architect. The companion service handles the sync in the background, and the fact that you are present follows automatically from your being at work. You do not set a status, you do not check into anything, and you do not maintain a separate awareness tool. Presence is simply there when you glance for it, and gone when you leave.

A grounded takeaway

The chat message that opens this piece — "is anyone in the integration package right now?" — is such a familiar part of shared modelling that most teams have stopped seeing it as a defect. But it is a defect, or at least the visible symptom of one. It exists because the tooling could not answer a basic, human question about who was in the room, and so people were forced to answer it the slow way, by asking out loud and waiting. Every such message is a small tax on collaboration, and the caution it induces is a larger tax that never appears on any invoice.

Lightweight, ephemeral presence removes that tax by making the answer a glance instead of a question. It does not control who may edit, and it does not try to prevent concurrent work; those jobs belong to roles, to governance, and to a merge engine built to reconcile independent changes honestly. What presence does is restore awareness — the simple, ambient knowledge of who is here with you right now — and then get out of the way, forgetting each person the moment they leave. That is a modest-sounding capability, but its absence has quietly shaped shared modelling toward hesitation and territoriality for years. Give a team the ability to see the room they are working in, and they stop taking turns in the dark and start working together in the light. That is the outcome CelinQ is built to make ordinary, and it does so while leaving every architect free to work exactly as they already do.