Building an Internal Sparx EA Practice

A licence renewal that almost lapsed

A public social services organisation — around nine hundred people administering benefits, family support and reintegration programmes — nearly cancelled the maintenance and support on its Sparx Enterprise Architect licences the year before we met them. The renewal request landed on a new IT manager's desk with no context, a four-figure line for maintenance on software whose repository had not seen a meaningful change in a year and a half. The obvious decision was to cancel. To their credit, they asked a better question first: is this tool worthless, or have we been holding it wrong?

The history was a familiar one. Years earlier, an enthusiastic analyst had built a genuinely useful model of the organisation's application estate and core processes, mostly alone, mostly unasked. When they left, the repository froze at the moment of their departure — nobody else had the habits, the conventions lived in the leaver's head, and the model aged quietly into a museum of the organisation as it had been. The maintenance kept renewing because cancelling felt like admitting something — the licences themselves are perpetual, but nobody wants to own software the organisation has stopped believing in.

The IT manager's brief to us was refreshingly blunt: either build us the ability to use this properly, with our own people, or tell us honestly to cancel and we will part as friends. Twelve months of maintenance were approved as the window. That framing — capability or cancellation, with a deadline — shaped everything about the engagement, because it ruled out the one thing consultancies default to: doing the modelling ourselves and leaving behind a better museum.

Why training alone had failed twice

This organisation had already bought training, twice. Both courses were competent, and both evaporated within a quarter, for reasons that had less to do with course quality than with everything that surrounds a course.

Nobody modelled anything real in the weeks after either course, so the skills decayed on schedule, the way any unused skill does. There was no repository administrator, so version conflicts and a corrupted project file were met with shrugs and a retreat to Visio. There were no conventions, so the few post-course attempts at modelling produced content in four personal dialects that could not be joined together, which convinced everyone the tool was the problem. And there was no occasion — no meeting, no deliverable, no rhythm — where modelling was expected, so it competed with day jobs and lost every time.

We tell clients considering a training-only purchase the same thing we told this one: a course teaches people to operate the tool, and operating the tool is perhaps a fifth of a working practice. The other four fifths — administration, conventions, rhythm, and a reason — have to be built, and they are built in the organisation, not in a classroom. That is the difference between training and what this engagement became: nine months of coaching, administration guidance and modelling clinics, run inside their real work rather than beside it.

There was also a subtler cost to the two failed rounds, which the interviews surfaced repeatedly: learned scepticism. Several of the six occasional modellers had privately concluded that the organisation was not serious — that modelling was a management enthusiasm that would pass, as it had passed twice — and rational people do not invest skills in an enthusiasm. Rebuilding that belief was not a training problem at all. It was done with structural signals: a named lead with real hours, an administrator, a board with the authority to change rules, and a repository that visibly stopped losing work. The scepticism took about four months to dissolve, and we would estimate it cost more clinic energy than every technical topic combined.

An honest starting point

We began with a two-week assessment rather than a plan, because the plan depends on facts it is cheap to get and expensive to assume. We interviewed the eight people who might plausibly model, reviewed the frozen repository, and examined the installation itself — the same structured pass we offer as a Sparx EA maturity assessment, applied with the gloves off.

The findings set the agenda. The inherited model was better than feared: the application inventory's bones were sound, and perhaps two thirds of it was salvageable with a structured refresh, which meant the new practice could start from restoration rather than a blank page — psychologically a very different opening. The installation was worse than feared: a file-based project on a network share, accessed by whoever double-clicked it, no backups that anyone could demonstrate restoring, versioning features untouched. And the people were exactly as expected: two candidates with real appetite — a senior business analyst and an infrastructure engineer with a modelling past — plus six occasional contributors-to-be, all of whom had been burned by the previous false starts and needed convincing that this attempt would be different.

We wrote the assessment up in plain language, including the sentence the IT manager had asked for: the tool was worth keeping if, and only if, the organisation staffed the practice it had never staffed. Half a person, formally, to start. They agreed, and named the senior analyst as practice lead the same week — the single most important decision of the engagement, made before any modelling began.

Designing the practice around real people

The operating structure we designed was deliberately modest, because a nine-hundred-person organisation does not need — and cannot feed — an architecture function copied from a bank. Three roles, one rhythm, one board.

The practice lead owns the repository's content: conventions, quality, what gets modelled and to what depth. The infrastructure engineer became model librarian and administrator — the person who owns the installation, the backups, the security groups and the upgrade calendar, distinct from content on purpose, since the two jobs fail differently and had both been unstaffed. Around them, the six occasional modellers — analysts and project leads — contribute through their normal project work, with no pretence that they would ever be full-time architects. Governance is a monthly model board of forty-five minutes: the practice lead, the IT manager, and a rotating business voice, deciding rule changes and reviewing what entered the repository that month.

What we did not create matters as much: no architecture review gate on projects, no mandatory modelling standard imposed organisation-wide, no steering committee. Structures like that, bolted onto a practice that does not yet exist, are how the third false start happens. The design principle throughout was that every structure had to be light enough to survive the month nobody has time — because in social services administration, that month comes several times a year, usually with a policy change attached.

The coaching rhythm

The heart of the engagement was a fortnightly modelling clinic, ninety minutes, run without interruption for the full nine months. The format was borrowed from teaching hospitals rather than classrooms: bring your own case. Participants arrived with the model they were actually working on — a subsidy process being redesigned, an application due for replacement — and the room worked the real problem, with one of us facilitating and, progressively, the practice lead taking over the chair.

The clinic's rules were few and enforced. Real work only; no toy exercises, because toy exercises are what the failed courses had been made of. Every clinic ends with each participant naming the next concrete thing they will model, which the following clinic opens by reviewing. And no problem is too embarrassing — the fourth clinic, by common consent the turning point, was spent untangling a diagram one analyst had been quietly ashamed of for weeks, and the room's discovery that everyone's first diagrams look like that did more for participation than anything we said all autumn.

The clinic's syllabus was whatever walked in the door, but looking back across nine months the same themes recurred on a rhythm we now expect in any small practice. The early sessions were tool mechanics dressed as modelling questions — where things live, how not to create a duplicate, why a diagram is not the model. The middle months were conventions in practice: which viewpoint for which audience, how much detail a process model owes its readers, when a relationship earns its place. The late sessions turned political in the best sense — what to model at all, whose questions the repository should answer first, and how to decline work politely. That progression, from keystrokes to judgement, is the practice growing up, and it cannot be compressed by better teaching; it is paced by the real work arriving.

Between clinics we ran paired modelling on the two live projects that had volunteered as vehicles: a case-management replacement and a data-sharing initiative with another agency. Pairing means the client's person holds the keyboard and makes the decisions while we sit alongside — slower than doing it ourselves by a factor of three, and the entire point of the engagement. The case-management project's target architecture became the repository's first new content in two years, modelled to the new conventions by the people who would live with it, and it was presented to the project's steering group from the repository, not from slides — a small ceremony we insisted on, because a practice becomes real the first time its output carries weight in a decision.

Administration is a job, not a hobby

In parallel, we rebuilt the installation around the librarian, working from a simple premise: a practice that cannot trust its repository will abandon it at the first incident, and this organisation had already had the incident. The file-based project on the network share was migrated to a proper SQL Server-backed repository — the usual move for a multi-user installation like theirs, for the reasons we set out in our comparison of repository database options — with security groups mapped to the three roles rather than to individuals, so the next departure changes a group membership instead of orphaning the estate.

The librarian's playbook, written together over the nine months, runs to about twenty pages and covers the unglamorous entirety of the job: nightly backups with a quarterly restore test that is actually performed and logged — the previous regime's backups had never once been test-restored, so nobody could say whether there were backups at all — a baseline policy for the packages that matter, the upgrade cadence and its test sequence, and the small set of health checks run monthly against the repository database. None of it is sophisticated. All of it was new here, and the quarterly restore test alone justified the playbook's existence in the eyes of the IT manager, who had lived through the corrupted-file era.

Conventions sized for a small team

The conventions document is six pages, and its brevity was fought for. It fixes the package structure — a stable spine for applications, processes, data and projects, with project work quarantined from reference content; a naming pattern per element type; the short list of tagged values that must be filled, owner and lifecycle first; and the definition of done for a model that enters the reference packages, which includes the sentence "another modeller can explain this diagram without its author present".

Everything else went into a starter kit inside the repository instead of into prose: a template package with pre-built diagram skeletons for the three viewpoints the organisation actually uses, worked examples salvaged and polished from the inherited model, and a small pattern library — how we model an application, an interface, a process handoff — copied rather than described. People do not read conventions documents under deadline; they copy the nearest good example. The starter kit makes the nearest example a good one, and the salvage of the founder's best work into it had a second effect nobody planned: it turned the museum into an inheritance, which the practice lead noted was the first time anyone had said the leaver's name without a sigh.

Restoring the inherited model

The frozen repository deserved a decision, not a default, so in month three we ran a triage of the inherited content with the practice lead and two of the analysts who had known the organisation longest. Every top-level package got one of three verdicts, recorded as a tagged value: refresh, meaning the structure was right and the facts needed updating; archive, meaning historically interesting and operationally dead; or salvage, meaning individual elements worth rescuing from a package whose structure was not.

The refresh itself was distributed rather than heroic. Each of the six occasional modellers took a slice of the application inventory — the systems their own work touched — and brought it up to date against reality, with the changes reviewed in clinic. Spreading the refresh had an unstated second purpose: it forced every future contributor through the new conventions on low-stakes content, before their project work depended on the habits. The archive went into a clearly named package, read-only under the security groups, with a note explaining what it is and why it was kept; deleting a predecessor's work sends a message to every future contributor about what will happen to theirs, and we advise against it wherever storage allows.

Provenance became a small permanent convention. Every element in the reference packages carries a tagged value naming its last verification date and verifier, and the monthly board reviews a short list of the longest-unverified elements in the packages that matter. The mechanism costs minutes and answers the question that had killed the previous repository's credibility — "is this still true?" — with a date instead of a guess. Eighteen months of staleness was never the founder's failure; it was the absence of exactly this loop.

The nine months, phase by phase

The engagement ran in three deliberate phases, each ending with something the organisation kept.

The stepping back was engineered, not hoped for. From month seven we attended clinics as observers only; from month eight we did not attend at all, and the clinic survived — attendance actually rose slightly, which we have learned not to take personally. The model board took over rule changes in the same period, making two convention amendments we would not have made, both of which were right for them. The final month repeated the opening assessment with the same criteria, partly for the genuine comparison and partly because a before-and-after the organisation can show its own management is worth more to the practice's survival than any external endorsement.

What independence looked like

Independence has a concrete test: something new, modelled unaided, carrying weight. It came in month ten, after our exit, when a national policy change forced a rapid redesign of a benefits process. The practice lead ran the impact analysis from the repository — which applications, which interfaces, which teams — in an afternoon, modelled the to-be process with one of the clinic regulars, and the package went to the programme board as the working reference. Eighteen months earlier, the same question would have produced a fortnight of meetings and a diagram drawn the night before the deadline.

The quieter measures matter as much. The repository has had content committed every month since the migration, by five distinct people at last count. The restore test has been run every quarter since the migration and passed every time. The clinic has continued fortnightly, chaired by the practice lead, with the starter kit growing a new pattern roughly every quarter. And the maintenance renewal that started everything went through the following year without discussion — the line item now has a story attached, which is ultimately what a practice is.

The fragility that remains

Honesty requires naming what nine months did not fix. The practice stands on two people, and small practices always do; a resignation letter from either the lead or the librarian starts the museum clock again. We mitigated what can be mitigated — the playbook exists precisely so the librarian's job is documented rather than personal, group-based security means access outlives individuals, and the board institutionalises the rules — but succession in a two-person practice is a risk to be watched, not a problem to be solved, and we said so in the closing report rather than burying it in an appendix.

The second honest limit: depth. Six occasional modellers sustain an application inventory, process models for active projects and impact analysis on demand. They do not sustain enterprise-wide current-state coverage, and pretending otherwise is how small practices burn out. The closing report drew that boundary explicitly — what this practice can promise its organisation, and what it should decline — and the model board has so far held the line, declining two requests that would have quietly re-frozen the repository under their own weight. Scoping a practice to its real capacity is, in our experience of Sparx EA enablement work, the least glamorous and most decisive thing a consultancy can leave behind.

Where they are now

Two years after the renewal that nearly became a cancellation, the organisation runs a small, unspectacular, working architecture practice: a current application inventory, process models that match how benefits are actually administered, and a repository that answers questions the day they are asked. Our involvement has shrunk to an annual health check against the original criteria, at their initiative. The IT manager who once weighed cancelling the licences now cites the practice, a little wryly, as the cheapest capability their department built that year — the licences were never the cost; the missing half-person was.

If your organisation owns Sparx EA licences that outlived their champion — a frozen repository, training that evaporated, a renewal that gets harder to justify each year — 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.