CelinQ Insights · No. 01

The one-editor-at-a-time problem, and what it quietly costs

Why a shared project file makes a whole team wait, and what that waiting adds up to over a year.

There is a particular message that anyone who has worked in a shared Sparx Enterprise Architect repository knows by heart. You open the project, navigate to the package you were asked to update, double-click an element, and start typing. Nothing happens, or worse, a small dialog appears telling you the item is locked by a colleague. You check the clock. It is the middle of the afternoon. The colleague is in a workshop until five. You have a diagram to finish before a review tomorrow morning, and the part of the model you need to touch is, for the moment, someone else's territory. So you do what everyone does. You find something else to work on, you send a message asking them to release the lock when they get a chance, and you make a mental note to come back later. The afternoon reorganises itself around a lock you did not create and cannot clear.

This is such a routine experience that most teams have stopped thinking of it as a problem at all. It has become weather. You plan around it, you grumble about it, and you assume it is simply the price of working together in one model. But it is worth stopping to look at what is actually happening here, because the mechanism is not inevitable and the cost is larger and stranger than it first appears.

Where the lock comes from

Enterprise Architect, in its traditional shared-repository setup, keeps the whole model in one place: a single project file on a network share, or a single database that everyone connects to. That design decision made complete sense when it was made. A model is a densely interconnected thing. An element in one diagram is referenced by relationships, by other diagrams, by tagged values, by documentation. If two people were allowed to change the same interconnected structure at the same time with no coordination, the model would corrupt itself in short order. Relationships would point at elements that no longer existed in the form the other person expected. The repository would become internally inconsistent, and inconsistency in a model is not a cosmetic flaw; it is the whole thing losing its meaning.

The defence against that chaos was locking. Before you can change something, you take a lock on it, and while you hold that lock nobody else can change the same thing. It is a pessimistic strategy in the technical sense: it assumes a collision will happen and prevents it by forbidding concurrency in advance. And as a way of protecting the integrity of a single shared store, it works. The model stays consistent. The trouble is that the protection has a reach that extends well past the thing you are actually editing, and it turns a data-integrity problem into a human-scheduling problem.

Locks in practice are rarely as surgical as the theory suggests. People lock a whole package because it is easier than reasoning about exactly which elements they will touch. People forget to release locks and go home. People take a lock to read something carefully and never remember they took it. A checkout that was meant to protect a single element ends up sitting across a branch of the tree that three other people need. And because the model is so interconnected, the boundaries that feel natural to lock along are almost never the boundaries along which work is actually divided. Two architects working on genuinely different concerns can still find themselves contending for the same corner of the tree, not because their work overlaps but because the structure they are editing happens to live in the same package.

The cost nobody puts on the invoice

Ask a team what the locking model costs them and the first answer is usually a shrug and the word "waiting." That is true but it undersells it, because the waiting is only the visible part. The expensive part is what the waiting does to how people work.

Consider what happens to concentration. An architect deep in a piece of structural work is holding a lot of context in their head at once: the reasoning behind a decomposition, the relationships they are about to draw, the way this part of the model connects to a stakeholder concern three diagrams away. That mental state is fragile and it takes real time to build. When the work is blocked by a lock, that context does not politely wait for you. You switch to something else, you build up a different context for the new task, and when the lock finally clears you have to reconstruct the first one from scratch. The interruption does not cost you the thirty seconds it took to read the lock dialog. It costs you the fifteen or twenty minutes it takes to get back to where you were. Do that a few times a day and the arithmetic gets uncomfortable.

Then there is the quieter cost, the one that never shows up as a complaint because nobody experiences it as an event. People route around locks by not doing things. An architect who knows that a particular package is usually checked out by a colleague simply stops planning work there. They defer the tidying-up they meant to do, the small correction they noticed, the refinement that would have made the model clearer, because the friction of coordinating access is not worth it for a minor improvement. The model slowly accumulates the small debts that nobody was willing to fight the locking system to repay. None of this is visible. It is the work that quietly did not happen, and over a year it is a great deal of work.

The most expensive thing about a shared lock is not the time you spend waiting for it. It is the good, small improvements to the model that nobody bothers to make because coordinating access costs more than the improvement is worth.

There is also a coordination tax that scales badly. With two people, a shared repository and a bit of goodwill mostly works; you can shout across the room or send a quick message. With five or six, the informal negotiation of who has what checked out becomes a genuine overhead. Someone becomes the unofficial traffic controller. The daily stand-up acquires an item that is really just lock logistics dressed up as planning. And the moment part of the team is remote, or working across time zones, or simply offline on a train, the informal system breaks entirely, because the whole thing depended on everyone being reachable at the moment a lock needed clearing.

Offline is where it gets worse

The shared-file model has an assumption baked so deep into it that it is easy to miss: it assumes everyone is connected to the same store, all the time. The moment that assumption fails, the whole arrangement degrades from inconvenient to unworkable. An architect on a client site with no access to the internal network cannot take a lock, cannot check anything out, and therefore in the strict sense cannot work in the shared model at all. What they can do is keep a private copy and promise themselves they will reconcile it later, which is exactly the situation the locking model was invented to prevent. The safety mechanism has quietly pushed people into the unsafe practice it was meant to eliminate.

This matters more than it used to. The way architects actually work has changed. The expectation now is that you can pick up your laptop, go to a workshop, sit on a train, work from home, and keep making progress. A collaboration model that only functions when everyone is docked to the same network share is a model that is fighting how people genuinely spend their days. It punishes exactly the flexibility that good architectural work depends on, because the best modelling often happens away from the desk, in the quiet after a workshop when the picture is fresh in your head and there is no network in sight.

A different starting assumption

The reason locking exists is worth respecting: model integrity is real, and it is not optional. But it is worth asking whether the way we protect that integrity has to also be the way we schedule the team. Those two problems got fused together because, historically, they had the same solution. They do not have to stay fused.

CelinQ starts from the opposite assumption to the shared file. Instead of one store that everyone reaches into and takes turns with, each architect works in their own local repository. It is genuinely theirs and genuinely local, which means it responds at full speed and does not care whether you are online. You open your model, you edit, you draw, you refactor, and nothing waits on anyone else because there is no shared lock to contend for. The thing you are editing is yours. This is what "local-first" actually means in practice: the fast, private, always-available copy is the primary one, not a temporary checkout you have to hand back.

The obvious objection is the one the locking model was built to answer. If everyone has their own copy, how does the model stay consistent? This is the real question, and the honest answer is that it is not free; it is the hard part, and it is where the actual engineering lives. A background companion service watches for each save you make and synchronises your changes with a shared workspace that your organisation runs on its own infrastructure. The reconciliation is handled by a deterministic merge that works at the level of individual model facts rather than whole files, so that two people editing genuinely different things simply both succeed, and the only moments that require a human are the moments where two people really did change the same fact in incompatible ways. Those genuine conflicts are preserved and surfaced rather than silently resolved. The rest of the article series goes into how that merge works and why it does not lose anyone's work, because it is the part that deserves the most scrutiny.

The point for now is narrower. The reason you had to wait for a lock was never really about your safety. It was about protecting a single shared store from concurrent edits, and it protected that store by forbidding the concurrency. Move the primary copy to each person's machine and reconcile afterwards, and the waiting simply has nowhere to live. Two architects can work on the same package at the same time. One of them can be on a plane. Neither of them takes anything away from the other.

The rhythm of collaboration, not a fixed cadence

There is a natural worry that arises the moment you move to synchronising local copies rather than sharing one store: does it now chatter constantly, pushing and pulling in a way that gets in the way, drains a laptop battery on a train, or floods a slow client network with traffic nobody asked for? A system that synchronised at a fixed, aggressive interval regardless of what people were doing would trade the old friction of locks for a new friction of noise, and that would not be much of an improvement. The answer is that the synchronisation adapts its rhythm to the work rather than running to a metronome. When a team is actively collaborating, changes flowing back and forth in a busy session, it keeps pace so that everyone stays close to current. When things go quiet, it settles down and stops making work for itself and for the network.

This matters for the offline case in particular. An architect working on a train with no connection is not fighting the tool, because the tool is not trying to reach a server that is not there. The local work simply accumulates, fast and unhindered, and when a connection returns the synchronisation catches up. The experience is that connectivity becomes a detail rather than a precondition. You stop organising your day around whether you will have the network, because the presence or absence of the network no longer decides whether you can work. It only decides when your work becomes visible to everyone else, and that can happen whenever the connection allows without any of it being lost in the meantime.

The deeper point is that a shared file has exactly one cadence, and it is the harshest one imaginable: everything must be reconciled instantly and in advance, by refusing concurrency, because the single store cannot tolerate anything else. Separating the copies is what buys the freedom to have a cadence at all, to be busy when the team is busy and quiet when it is not, rather than being permanently locked into the one rhythm that a single shared store can survive.

What changes on a Tuesday afternoon

It is easy to talk about this at the level of architecture and miss what it feels like day to day, so let us go back to the afternoon we started with. You need to update a diagram before tomorrow's review. The colleague who used to hold the lock is still in their workshop until five, and that is now simply irrelevant to you. You open your local model, you make your changes at full speed, and you save. The companion service notices the save and quietly brings your work into the shared workspace. Your colleague, when they come out of their workshop and save their own afternoon's work, finds that the two sets of changes have been reconciled without either of you having to negotiate a handoff. Nobody sent a message asking for a lock to be released. Nobody rebuilt lost context. The review happens tomorrow with both people's work in it.

Multiply that small non-event across a team and across a year and you recover something that is hard to measure precisely but easy to recognise once it is gone: the ability of everyone to work at the same time on the same model without a queue forming. The improvements that used to be too much bother to coordinate get made, because there is nothing to coordinate. The remote member of the team stops being a second-class participant who has to catch up when they get back to the office. The traffic-controller role dissolves because there is no traffic to control.

It is worth dwelling on the team-scale effect, because that is where the change compounds. A single blocked architect is an annoyance. A whole team whose members are each, several times a day, either blocking someone else or being blocked themselves is something else: it is a standing drag on the entire group's throughput that grows with the size of the team. Every additional person is not just another contributor but another source of potential contention against everyone already there. The informal negotiation that held together at two or three people becomes a genuine coordination cost at six or seven, and it is a cost that rises faster than the team does. Removing the queue does not just help each individual; it removes the term in the arithmetic that was making the team harder to grow.

The honest limits

It would be a poor argument if it pretended there were no trade-offs, so here are the real ones. Working local-first means there is a moment of reconciliation that the single-file model does not have, because the single-file model reconciles continuously by simply refusing to let the situation arise. That reconciliation is where the engineering effort has to be spent, and if it were done badly it would be worse than a lock, because a lock at least fails loudly and in advance. A merge that quietly made the wrong choice would be a much nastier problem than an afternoon of waiting. This is precisely why the merge has to be deterministic and reproducible, why it has to preserve genuine conflicts for a person to look at rather than guessing, and why "last write wins" is not an acceptable shortcut. The value of the whole approach rests on the reconciliation being trustworthy, and that trust has to be earned rather than asserted.

There is also a cultural adjustment. A team used to locks is used to the certainty that if they hold a lock, nobody else can touch the thing. Moving to a world where two people can both touch it and the system sorts it out afterwards asks people to trust a process they cannot watch happening. That trust comes from the process being visible after the fact: a complete, ordered history of what changed and when, clear review and governance over changes, and conflicts that are surfaced honestly rather than swept away. The comfort of the lock is replaced by the comfort of an audit trail and a merge you can inspect. That is a fair trade, but it is a trade, and it is worth naming rather than glossing over.

And none of this replaces Enterprise Architect. CelinQ works alongside EA, not instead of it. Each architect keeps using the tool they already know, at full speed, in their own repository. What changes is not the modelling environment but the thing underneath it that decides who can work when. That is the deliberate scope. The modelling tool was never the problem. The single shared store and the queue it created were the problem.

What the waiting was really costing

If you total up the honest cost of the one-editor-at-a-time model, very little of it is the raw minutes spent staring at a lock dialog. Most of it is second-order. It is the reconstructed context after every interruption. It is the small improvements that never got made because coordinating access was not worth the trouble. It is the remote and offline work that quietly stopped happening, or happened in private copies that later had to be reconciled by hand with all the risk that implies. It is the slow drift of a team toward doing less in the model than they would like to, because the model has become a place you have to book time in rather than a place you can simply go and work.

Those costs are real precisely because they are invisible. Nobody logs the improvement they decided not to make. Nobody records the twenty minutes of context they had to rebuild. It never appears on an invoice or in a status report, which is exactly why it persists: a cost that no one measures is a cost no one is motivated to remove. But the team feels it, in the form of a model that is always slightly behind where it should be and a working day that is always slightly more fragmented than it needs to be.

The one-editor-at-a-time problem is not a law of nature. It is the visible edge of an old and reasonable engineering decision, made when the only way to protect a shared model was to stop people from touching it at the same time. That decision solved a real problem and created a hidden one. The hidden one is now the larger of the two. Separating the protection of the model from the scheduling of the team is what lets you keep the first and throw away the second, so that the model stays consistent and nobody has to wait until five o'clock to do their job.