The starting point
The organisation, active in financial services, had used Sparx Enterprise Architect for the better part of a decade — as a desktop tool. Around fifteen architects and business analysts each kept models locally or on a departmental file share: a scatter of .eapx files, some current, some abandoned, several of them rival versions of the same landscape. Sharing meant emailing a file or exporting diagrams into slide decks. Version control meant a filename convention that had long since collapsed under final, final_v2 and final_v2_JK.
The arrangement had been tolerated for years, as these arrangements are, because each individual architect could work perfectly well. What broke the tolerance was a combination familiar in regulated industries: a new head of architecture who wanted one answerable model of the estate, and an internal audit finding that noted, correctly, that the firm's architecture documentation had no single authoritative source, no access control worth the name, and no way of demonstrating who had changed what. The mandate that reached us was short: give us one shared repository, hosted centrally, with controlled access — and get everyone onto it without losing what they have.
What the file era was actually costing
Before designing anything we spent a few days quantifying the pain, partly to shape the solution and partly because a migration like this needs sponsorship, and sponsorship feeds on specifics. The specifics were easy to find. Two architects had spent overlapping weeks modelling the same payments landscape in separate files; reconciling their work was judged harder than redoing it, so one fortnight of senior effort was simply discarded. The file share held over forty model files, and nobody could say which of them mattered. The most recent attempt to assemble an estate-wide view had involved copying elements between files by hand — with every pasted element getting a fresh identity, so the copies drifted from their sources the moment they landed.
The subtler cost was behavioural: because sharing was awkward, models were built for their authors. Naming, structure and depth varied by personal taste, and reuse across the team was near zero — why search someone else's file for an element you can draw in thirty seconds? The file era did not just fragment storage. It quietly trained a team of capable people out of the habit of building on each other's work.
What centrally hosted had to mean
"A shared repository" underdetermines the design, so we pinned down with the client what the phrase had to mean in practice. Five requirements carried the design. Concurrent access: fifteen people modelling at once without stepping on each other, from two office locations and from home over VPN. Access aligned to the organisation: domain teams edit their own areas, read everything else; a small group administers; auditors and interested outsiders read without a modelling licence. Traceable change: the audit finding had to be answerable — who touched what, and when. Recoverable state: point-in-time recovery of the repository, and model-level baselines for the packages that feed formal documentation. And workable performance over the actual network, including the VPN paths, not just the LAN next to the server.
Just as important was what centrally hosted did not have to mean. There was no requirement for internet-facing access, no requirement for external collaborators, and the firm's security team had a clear preference for keeping the whole installation inside the corporate network. That ruled out cloud hosting early and honestly, and it simplified the security review that followed.
We also sized the thing before buying anything. A fortnight of observation and a short survey established real concurrency: fifteen named modellers, but rarely more than eight modelling at once, with predictable Tuesday peaks around the architecture board. That number drove the floating licence pool and kept the Pro Cloud Server edition modest, and it is a piece of homework we now consider mandatory — the difference between licensing for headcount and licensing for concurrency funded a good part of the engagement.
The target architecture
The design we implemented is deliberately conventional. A SQL Server database, provisioned by the firm's own database team on their standard clustered infrastructure, holds the repository — the platform choice followed the client's operational strengths, a decision we discuss in our comparison of repository databases for Sparx EA. In front of it sits Sparx Pro Cloud Server on a hardened Windows virtual machine, exposing the repository to EA clients over HTTPS on a single port, with a certificate from the firm's internal authority. Desktop clients connect through a cloud connection rather than a direct database connection, which keeps database credentials out of every laptop and gives the firewall team exactly one path to reason about. WebEA, served through the firm's standard reverse proxy, gives read access to anyone on the network with a browser and a licence-free way in for auditors and management.
Floating licences replaced the accumulated stock of node-locked ones, pooled on the Sparx licence server alongside Pro Cloud Server — with fifteen modellers of varying intensity, a smaller pool of floating licences covers realistic concurrency and removes the perennial question of whose laptop a licence died on. The whole arrangement passed the firm's architecture and security review in one iteration, which we credit less to brilliance than to boringness: every component sits where such components normally sit, and the security team had seen every pattern before.
Access control that matches the organisation
Repository security only works when it mirrors how the organisation actually divides its work, so we started from the package structure rather than the permission screens. The top level of the repository follows the firm's architecture domains — payments, lending, channels, data, shared infrastructure — plus a governed area for approved, published views and a sandbox area where anything goes. Each domain package is owned by a named team; the governed area is writable only by the architecture leads.
Onto that structure we enabled EA's model security with user groups, and connected authentication to the corporate directory so that people log in with their normal accounts and leavers lose access when their account closes — no separate password estate to manage. Groups map one-to-one to the domain teams, and permissions follow the ownership rules: each domain package carries a group lock held by its owning team, so editing your own domain and reading everyone else's falls out of the locking model, and the require-lock-to-edit discipline means concurrent work collides in locks rather than in overwrites. It is worth being precise about what this does and does not give you: EA's security model controls editing, not visibility — everyone who can open the repository can read all of it. Pro Cloud Server's visibility levels on SQL Server could have hidden whole subtrees outright, but the firm explicitly wanted every domain readable to every architect, so we left them unused. For this client full readability was acceptable and even desirable; a firm needing genuinely confidential compartments inside one repository would need a different design, and we said so in the review.
The security review, and what it asked
In a financial services firm nothing reaches production without a security review, and a modelling repository gets no exemption — reasonably so, since an architecture repository is a map of exactly the systems an attacker would like a map of. The review asked the questions we had prepared for. Where does the data live, and who administers the box? On the firm's own database cluster, administered by the same team and regime as every other internal database. What travels on the wire? HTTPS only, internal certificate, one port; the direct database port is closed to everything except the Pro Cloud Server host. How do people authenticate? With their directory accounts; there is no local account store to forget about, and the joiners-movers-leavers process the firm already runs covers the repository for free. Who can reach WebEA? Anyone on the internal network, read-only, behind the standard proxy — and nothing is reachable from outside.
Two review outcomes actually improved the design. The reviewers asked for the Pro Cloud Server VM to be enrolled in the firm's standard hardening and patching baseline rather than treated as an appliance, which forced the documented update procedure that later made handover clean. And they flagged the repository's own backup files as sensitive material — a map of the estate is a map wherever it is stored — so backups inherited the same access restrictions as the live database. Neither point had been on our initial list; both have been on it for every engagement since.
Consolidating years of file models
The forty-odd files on the share held perhaps a decade of accumulated modelling, and the temptation in every such migration is to import everything. We resisted it with a simple triage rule agreed with the domain leads: content came across if a named person vouched for it and expected to use it. Each lead nominated their living models; everything else stayed behind in a read-only archive of the original files, findable but not polluting the new repository. In the end, roughly a third of the files contributed content, and nobody has gone looking for the rest since.
The mechanics were package-level XMI exports from each nominated file, imported into a staging area of the new repository — a project transfer would have replaced the whole target, so consolidation had to happen package by package — followed by restructuring into the domain packages. Where the same real-world system existed in several source files we merged duplicates, keeping the element with the richest history and re-pointing relationships from the others — scripted where rules could decide, by hand in working sessions where they could not; the payments landscape alone took the two architects who had once modelled it in parallel a full day to unify, which had a certain justice to it. Elements kept their identities through transfer wherever possible so that existing generated documents and cross-references survived, and we took a baseline of every package the moment it reached its final home, giving the new repository a clean day-zero mark to measure change against.
The rollout, in stages
We rolled out in three stages over about two months, resisting the big-bang instinct. First a pilot: the payments team, three people, worked exclusively in the new repository for two weeks while everyone else carried on in files. The pilot existed to surface the problems you only meet in real use — a proxy setting that broke cloud connections from one office, a lock discipline misunderstanding that produced the first friendly argument about who owned an element — and it surfaced exactly those, cheaply. Second, the remaining domain teams came across one per week, each with a half-day hands-on session covering the new connection, the package structure, locking, and where their archived files had gone. Third, the file share was made read-only, with a dated banner file in every folder pointing to the repository — gentle, unambiguous, and surprisingly effective at ending the file era without confiscating anything.
Communication ran a week ahead of the moves throughout. Each team knew, before their turn came, what would move, what would be archived, and the one decision we needed from them — which of their files were alive. The single message that did the most work was also the least technical: nothing gets deleted. Every original file survives, read-only, exactly where it was. Migrations of personal working material stir a possessiveness that project plans underestimate, and the guarantee of a permanent archive dissolved objections that no amount of feature demonstration would have touched. By the third week, teams were asking to be moved earlier — partly enthusiasm, partly not wanting to be the last people modelling alone in the old world.
Training deliberately spent more time on habits than on features. Fifteen people who have modelled alone for years do not need to be shown where the toolbox is; they need the working agreements — lock before you edit, model in your domain, promote to the governed area through review, search before you create. We wrote those agreements on one page, and the one page has outlived every slide deck from the rollout.
Performance over the wire
Performance is where centrally hosted repositories earn their reputation, good or bad, and the honest version is that the first week of the pilot was not good. Opening the repository from the secondary office took long enough to fetch coffee, and one architect's browsing felt like wading. None of this was mysterious, but all of it needed attention. The wins came in layers: moving the pilot users off the interim direct database connection they had started the pilot with, onto the Pro Cloud Server cloud connection cut round trips dramatically, since PCS batches repository traffic in a way raw database protocols over a WAN do not; from there, sensible housekeeping — trimming auto-loaded reference data, switching off an unused technology load on startup, and one index the database team added after watching the query profile — brought repository open times to a few seconds everywhere and diagram loads to effectively instant on both office networks. VPN use remains noticeably slower than office use, which we told the client plainly rather than tuning towards a promise we could not keep; it is workable for modelling, and the heaviest remote users have learned to keep big reorganisations for office days. Our notes on Pro Cloud Server troubleshooting collect the recurring culprits from engagements like this one.
Running it after we left
A hosted repository is an operated service, and we treated handover as part of the engagement rather than an afterthought. The database sits in the firm's standard backup regime with point-in-time recovery, and — because a backup nobody has restored is a hope, not a plan — we ran a full restore drill with the operations team before go-live, from tape to a working repository a test client could open. Pro Cloud Server got a named owner in the infrastructure team, a documented update procedure, and a monthly patch window aligned with the firm's normal cycle. On the model side, the architecture leads own a small operational rhythm: weekly automated integrity checks and a quarterly review of accounts and groups against the directory, plus baselines of the governed area before each formal publication. None of this takes much time, and all of it is the difference between a repository that stays trustworthy and one that decays into the very file share it replaced — just with a server bill attached.
The audit trail deserves its own word, because it was the original finding and because expectations need setting honestly. With security enabled, EA records who holds and held locks and stamps elements with author and modification dates; we also switched on EA's built-in auditing for the governed packages, which logs element-level changes with user and timestamp, and the repository database sits under the firm's normal database auditing — together, enough to answer "who changed this package and when" at the granularity audit actually asked for. What EA does not give you out of the box is a field-level change history of everything forever; where the client needed provable state at a point in time — the landscape as approved in a given quarter — the instrument is the baseline, taken deliberately, at the moments that matter. We wired baseline-taking into the publication rhythm of the governed area, so every formally published view has a stored, diffable model state behind it. Auditors, it turns out, are very satisfiable people once "what did it look like in March" has a five-minute answer.
What changed for the client
The audit finding closed. That was the headline for the sponsor, and it closed not with a policy document but with a demonstration: the auditor watched a change being made under a named login, saw it in the change log, and browsed the governed landscape through WebEA without anyone installing anything. But the change the architects themselves cite is smaller and daily: there is one place, and things are where the structure says they are. Estate-wide views stopped being assembly projects. The payments landscape exists once, and the two architects who once maintained rival copies now maintain complementary halves of the same one.
Reuse, the habit the file era had trained away, came back slowly and then visibly: within half a year, most new solution models were referencing shared elements rather than redrawing them, which is the quiet mechanism by which a repository becomes an asset instead of a filing cabinet. And management, who had never opened Sparx EA and never will, read the architecture through WebEA links pasted into steering papers — read access without licences turned out to be, for the wider organisation, the most valuable feature of the whole migration. A year on, the metric we find most telling is the one nobody planned: the number of architecture questions answered with a link instead of an attachment. Attachments age from the moment they are sent; the link always shows the repository as it is, and the difference has slowly retired a whole genre of "which version is this?" email. Engagements like this are a large part of our Sparx EA consulting practice, and the pattern transfers across sectors with the security posture adjusted to taste.
Limits and lessons
The limitations worth naming. Pro Cloud Server and the annual licence support renewals are a real recurring cost, and a firm should walk into that with eyes open; for this client the discarded fortnight of parallel modelling alone made the arithmetic short. EA's package-level security is coarse — it governs who edits, not who sees, and organisations needing confidentiality inside the repository must either split repositories or accept that boundary. WebEA runs read-only in this deployment — it can be configured to allow limited editing, which we deliberately left off — and occasionally renders an elaborate diagram differently from the desktop client, so we advise treating it as the distribution channel and the desktop as the source of truth. And the require-lock discipline that prevents overwrites also means people encounter each other's locks, which is a feature, but one that needs the working agreement — release locks when you stand up — or it breeds small frustrations.
A shared repository is a social change delivered through infrastructure. The infrastructure was stood up in a week; the habits took two months — and the habits, not the server, are what the client actually bought.
What we would do differently: start the performance work before the pilot rather than during it, because first impressions of a shared repository harden fast, and a slow first week costs goodwill that tuning only partially refunds. And we would make each team's corner of the file share read-only on the day that team moves, rather than leaving the whole share writable until the end — the writable share during the rollout produced a handful of stragglers modelling in both worlds, each of whom needed a second, entirely avoidable migration of their fresh work.
If your architecture practice still lives in model files on laptops and a shared drive, and an audit or a merge disaster is forcing the question, this path is well worn and the missteps are avoidable — you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.