CelinQ Insights · No. 26

Ending the big-bang merge at the close of every project

Continuous reconciliation instead of a painful integration at the finish line.

Every experienced architect knows the shape of the week that waits at the end of a project, even before they can see it on the calendar. Several people have spent months working on their own parts of the model — one on the application landscape, one on the integrations, one on the data structures, one on the technology mapping — each in their own copy or their own carefully fenced-off area, each moving fast because they were not tripping over anyone else. And now it all has to come together into a single coherent model that can be handed over, published, or reviewed. That coming-together has a name in most teams, usually said with a slight grimace: the integration, the merge week, the consolidation. Whatever it is called, everyone knows it is going to be unpleasant, and everyone knows it is going to take longer than anyone planned.

The reason it is unpleasant is not that the individual pieces are bad. Usually they are perfectly good. The problem is that they were built in isolation over a long period, and the decisions made in one piece silently invalidated assumptions in another. The person modelling integrations referred to application components that the person modelling the application landscape has since renamed, restructured, or split in two. The data architect introduced entities that overlap with elements someone else created independently, and now there are two representations of the same real-world thing that have to be reconciled by hand. Relationships point at elements that have moved. Naming conventions diverged. None of this was visible while the work was happening, because the work was happening in separate places, and it all surfaces at once, at the worst possible time, when the deadline is closest and the tolerance for surprises is lowest.

Why integration gets deferred to the end

It is worth asking why teams do this to themselves, because nobody sets out to schedule a painful week at the finish line. The deferral is not a mistake so much as a rational response to bad options, and understanding that is the key to seeing how it can be avoided.

The first pressure is speed. Working in isolation is fast. When you have your own copy of the model, or your own fenced-off territory within it, you can move at full pace without waiting for anyone, without collisions, without the constant low-grade coordination that shared editing in a single file imposes. Given the choice between working fast in isolation and integrating continuously at the cost of speed, most people quite sensibly choose speed and promise themselves they will sort out the integration later. The trouble is that "later" accumulates all the divergence into one lump, and the lump grows in difficulty faster than it grows in size, because the interactions between changes multiply.

The second pressure is the poverty of the tools available for bringing work together. When the only mechanism for integration is a person opening two versions of a model side by side and reconciling them by eye, integration is expensive per unit, and expensive things get batched. You would not want to do that reconciliation every day; it is tedious and error-prone, so you do it once, at the end, and try to get it over with. The batching is a direct consequence of the cost. If reconciliation were cheap and reliable, there would be no reason to save it all up for one dreaded week; you would do a little of it all the time, the way you might tidy a workshop as you go rather than letting it become a hazard you have to clear in one exhausting session.

The third pressure is fear of the merge itself. Many teams have been burned by a bad reconciliation — one where changes were lost, where somebody's month of work quietly disappeared because a tool picked the wrong winner, where the merged model turned out to be subtly broken in ways nobody noticed until much later. Once that has happened, people become reluctant to merge at all until they absolutely must, which perversely makes the eventual merge larger and more dangerous, which makes them more afraid, and so on. The fear of integration becomes self-reinforcing, and the big-bang at the end becomes not just a habit but a dreaded event that the whole team braces for.

What the big-bang actually costs

The cost of deferring integration to the end is not only the unpleasant week itself, though that week is real and it is expensive. The deeper costs are the ones that hide inside it, and they are worth setting out plainly because they explain why the pattern is more damaging than it looks.

The most obvious cost is that problems are discovered late, when they are most expensive to fix. A naming divergence caught on the day it happens is a thirty-second correction and a quick word between two colleagues. The same divergence caught three months later, after both people have built extensively on their respective versions, is a tangle: fixing it means unpicking downstream work, and the two people who need to talk about it may have half-forgotten the reasoning that led them to their choices. Architecture is full of decisions that are cheap to reconcile when fresh and ruinous to reconcile when stale, and the big-bang merge guarantees that every one of them is reconciled at its most stale.

The second cost is the risk of silent loss. When a great deal of divergent work is being reconciled by hand under deadline pressure, mistakes are inevitable, and the most dangerous mistakes are the ones nobody notices. An element that should have been merged gets dropped. A relationship that existed in one version fails to make it into the consolidated model. A deliberate deletion in one branch is undone because the merge treated the element's continued presence in the other branch as authoritative. These errors do not announce themselves. They sit in the model, quietly wrong, until someone relies on the model for a decision and discovers too late that it did not say what they thought it said. The big-bang merge is precisely the condition under which silent loss is most likely, because it maximises the volume of change being reconciled at once and the time pressure under which the reconciliation happens.

The third cost is to the schedule and to trust in the schedule. Because the integration week is unpredictable in length — you genuinely do not know how bad the divergence is until you start reconciling it — it is impossible to plan around reliably. It expands to fill whatever time is available and then some, and it does so at the end of the project when there is no slack left to absorb it. Teams learn to pad their estimates with a vague allowance for "integration pain," which is both wasteful when the pain is mild and insufficient when it is severe. A cost you cannot predict is a cost you cannot manage, and the big-bang merge is the least predictable phase of the whole endeavour.

Integration is not hard because models are complicated. It is hard because we save it all up. A month of divergence reconciled in an afternoon is a crisis; a day of divergence reconciled continuously is barely an event.

The alternative is not "merge less" but "merge always"

The instinctive response to a painful merge is to try to avoid merging — to fence people off more strictly into non-overlapping territories so that there is less to reconcile. This is understandable, and in moderation it has its place, but as a strategy it fights against what architecture actually is. Architecture is inherently cross-cutting. The integrations refer to the applications; the applications realise the business capabilities; the data flows through all of them. You cannot partition an architecture model into truly independent territories, because the whole value of the model is in the relationships that cross the boundaries. Strict territories either prevent the cross-cutting work that gives the model its worth, or they leak, and the leaks are exactly the hard-to-reconcile divergences that make the eventual merge painful. Partitioning is a way of postponing integration, not avoiding it.

The genuinely different approach is to make integration continuous rather than eventual — to reconcile constantly, in small increments, so that divergence never has a chance to accumulate into a lump. This only works if reconciliation is cheap and trustworthy, which is why the tooling matters so much. If every reconciliation required a person to compare two models by hand, continuous integration would be absurd; nobody could afford to do it. But if reconciliation is automatic, deterministic, and reliable enough to be trusted with everyday changes, then it can happen quietly all the time, and the big-bang at the end simply never forms, because there is never a large accumulation of divergence to resolve. The end of the project becomes an ordinary day, because the model was coherent yesterday and it is coherent today.

The requirements for this to work are exacting, and it is worth stating them, because a continuous merge that is not trustworthy is worse than an occasional manual one. Reconciliation has to operate at the level of individual model facts, not whole files, so that two people changing different aspects of the same area do not conflict merely because they touched the same region. It has to be deterministic and reproducible, so that the same inputs always produce the same result and the team can build confidence in it over time rather than treating every merge as a roll of the dice. It has to treat deletions honestly, so that when someone deliberately removes an element, that removal is respected rather than silently reversed by the continued presence of the element in someone else's copy. And above all it must never resolve a genuine conflict by simply picking a winner, because last-write-wins is the exact mechanism by which the silent losses of the big-bang merge occur — just spread out over time instead of concentrated at the end.

How CelinQ approaches it

CelinQ is a local-first collaborative modelling platform that works alongside Sparx Enterprise Architect rather than replacing it. Each architect edits their own 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 arrangement is what makes continuous integration possible without asking anyone to give up the speed of working in isolation. You still work locally, still move at native pace, still never wait on anyone — and yet your work is being reconciled with everyone else's continuously, in the background, rather than saved up for a merge week at the end.

The reconciliation is done by the merge engine, CelinQ Fusion, and its properties are exactly the exacting ones the continuous approach demands. Fusion performs a deterministic, reproducible three-way merge at the granularity of individual model facts. Because it works at fact level rather than file level, two architects editing different aspects of the same package do not conflict simply for being in the same neighbourhood; their changes combine cleanly, which is what allows reconciliation to happen constantly without generating a stream of false collisions that would exhaust everyone's patience. Because it is deterministic and reproducible, the same situation always resolves the same way, so the team can build the trust that continuous integration requires — the merge is not a gamble you brace for but a mechanism you rely on.

Fusion also handles the two things that make big-bang merges dangerous. Deletions are represented explicitly, with tombstones, so that a deliberate removal is understood as a deliberate removal and is not quietly undone because the element still exists in someone else's copy. This is precisely the silent-loss failure mode of the manual end-of-project merge, and it is designed out at the mechanism level rather than left to a reviewer's vigilance. And genuine conflicts — the cases where two people really did change the same fact in incompatible ways — are never resolved by last-write-wins. They are isolated explicitly and surfaced for a human to settle deliberately. Nothing is silently overwritten; the disagreement is preserved and made visible, so that a person makes the call, with full sight of both sides, rather than a rule discarding half the work behind everyone's back.

The cadence of this synchronisation adapts to the situation rather than being fixed. Smart Sync adjusts how often the companion service reconciles with the shared workspace, so that the continuous integration is genuinely continuous when it needs to be and does not impose unnecessary chatter when it does not. The practical effect is that reconciliation keeps pace with the work without the architect having to think about it. You save; the sync happens; the shared workspace stays current; and the divergence that would otherwise have been accumulating toward a painful merge is dissolved continuously into a coherent shared model.

It is worth being honest that this does not abolish conflict. Two people can still change the same fact in incompatible ways, and when they do, someone has to decide. What changes is the size and timing of that decision. Instead of a hundred such decisions dumped on a team in one exhausting week at the end, spread across changes that are all months old and half-forgotten, you get one or two at a time, surfaced while the work is fresh and the reasoning is still in everyone's head. A conflict resolved on the day it arises, by the two people who created it, with the context still vivid, is a small and manageable thing. That is the real transformation: not the elimination of conflict but its dispersal into small, timely, well-understood decisions instead of a single overwhelming batch.

What changes when integration is continuous

The most immediate change is that the merge week disappears as an event. The end of a project stops being a distinct, dreaded phase and becomes an ordinary continuation of the work, because the model has been coherent all along. There is no accumulation to resolve, no bracing, no unpredictable stretch of reconciliation that expands to swallow the schedule's remaining slack. The handover or the publication happens against a model that was already whole yesterday, which removes an entire category of end-of-project risk that teams have simply learned to live with.

The second change is that problems are caught while they are cheap. When reconciliation happens continuously, a naming divergence or an overlapping-entity problem surfaces within a day or so of being created, while both contributors still remember exactly what they were doing and why. The correction is a quick conversation and a small edit, not an archaeological dig through three months of downstream work. The cost of a class of problems does not disappear, but it is paid at the point where it is smallest, which over the life of a project is an enormous saving compared with paying it all at the end at maximum expense.

The third change is to the team's relationship with merging itself. When reconciliation is deterministic, honest about deletions, and never silently discards work, the fear that drives teams to defer integration dissipates. People stop treating the merge as a hazard to be avoided until the last possible moment and start treating it as a routine background fact of working together. That shift in attitude is what makes the continuous approach self-sustaining: because the merge is trustworthy, people merge often; because they merge often, the merges stay small and easy; because the merges stay small and easy, trust grows. The vicious circle of fear-driven deferral is replaced by a virtuous one of confidence-driven continuity.

And none of this asks the architect to sacrifice the speed of working in isolation that made deferral attractive in the first place. That is the point worth emphasising to a reader who suspects a catch. You still work locally, at full speed, online or offline, in your own repository alongside Sparx Enterprise Architect. You do not wait on anyone, you do not coordinate every edit, and you do not give up the flow of solitary deep work. The continuous integration happens in the background, through the companion service and Fusion, without slowing you down. You get the speed of isolation and the coherence of continuous integration at the same time, which is precisely the combination that the old choice between fast-but-divergent and integrated-but-slow said you could not have.

A grounded takeaway

The big-bang merge at the end of a project is not a law of nature. It is a consequence of a specific situation: work done in isolation for speed, reconciliation too expensive to do more than once, and past experiences of loss that make people defer the merge until they must. Change the economics of reconciliation — make it automatic, deterministic, honest about deletions, and unwilling to silently pick winners — and the whole pattern comes apart. There is no longer any reason to save up divergence, because dissolving it continuously costs almost nothing, and so the accumulation that makes the end-of-project merge painful simply never forms.

What replaces the dreaded week is not a different kind of merge but the near-absence of a discrete merge at all. Reconciliation becomes a continuous background fact, conflicts become small and timely decisions made while the work is fresh, and the model stays coherent from one day to the next so that the finish line is just another ordinary day. That is what CelinQ is built to deliver: the speed of working alone and the coherence of working together, without the tax that used to be charged all at once at the worst possible moment. The team keeps its pace, keeps its trust in the schedule, and keeps its model whole — and the integration week becomes a piece of history that newer members will struggle to believe was ever real.