⏱ 19 min read
I’ve worked with Sparx EA repositories that were messy, political, overgrown, lightly governed, and occasionally downright strange.
That does not, by itself, mean they are broken.
This one, in a large insurer, was broken.
You could feel it in a Monday steering committee. The architecture review board needed the current-state claims integration model to support a decision linked to both a regulatory change program and a claims modernization release. Nobody could find a version everyone trusted. There were three capability maps for the same domain. The claims platform showed up multiple times in the repository with different owners. One senior solution architect admitted, almost under his breath, that he had exported the latest diagrams into PowerPoint because it was quicker than explaining which Sparx package was supposed to be “the real one.” TOGAF training
That was the point where the repository stopped acting like a repository and started acting like a source of dispute.
In insurance, that lands harder than many people expect. You are typically carrying regulatory change, policy administration replacement, claims transformation, some kind of cloud move, merger residue, and years of inconsistent business language all at once. If the repository cannot tell you what exists, what is changing, what is regulated, and what depends on what, architecture becomes a drag on delivery instead of an enabler.
The uncomfortable truth is that a Sparx EA repository almost never collapses because the tool itself failed. In most cases, the tooling is the least interesting part of the story. Repositories decay because structure, governance, naming, ownership, and day-to-day usage drift apart over time. The good news is that you can restructure one without losing data. The bad news, in my experience, is that you have to treat it as architecture transformation rather than admin cleanup. ArchiMate for governance
That distinction matters more than it first appears.
What “broken” looked like in this insurer
The organization was a mid-to-large insurer spanning life, commercial, and personal lines. A fairly typical hybrid estate: older policy admin platforms, a document management stack nobody particularly liked but nobody could switch off, a newer cloud-based API layer, Kafka being introduced for event-driven claims processing, IAM modernization in flight, and a data lake initiative that had produced more diagrams than usable value.
The Sparx repository reflected all of it.
Poorly.
There was package sprawl by business unit and by program. The same claims application existed in multiple folders because the personal lines team modeled it one way, the commercial lines team another way, and a transformation office had created its own version for roadmap packs. Diagrams sat in odd places. Business process models were mixed in with application deployment views. Conceptual, logical, and physical content were blended together as though those distinctions were optional. ArchiMate, UML, BPMN, and homegrown stereotypes were used interchangeably, often inside the same package and sometimes on the same diagram. ArchiMate relationship types
And yes, there were package names like Final_v2_Revised, Current State NEW, and Claims Future State Old.
That sort of naming is funny exactly once.
There was hidden damage as well, and this is the part people often underestimate. Impact analysis looked plausible, but it was not dependable. Regulatory traceability was incomplete in ways nobody had properly surfaced. Cloud target-state conversations dragged on because teams did not trust the application landscape or the interface inventory. Architects rebuilt knowledge in SharePoint, Visio, PowerPoint, Confluence, and spreadsheets. Once that starts happening, the repository is no longer the system of architectural memory. It is just another place content goes to age.
In my experience, once architects believe SharePoint is safer than the repository, decline is already underway.
The tempting fixes we rejected
There were four obvious responses, and all of them were risky.
First: start a fresh repository. It always sounds cleaner than it turns out to be. New container, new standards, fresh discipline. In reality, it usually means losing relationships, losing context, and quietly abandoning historical traceability that you later discover you still need for audit, decommission planning, or operational resilience evidence.
Second: archive everything older than 18 months. Also attractive. Also naive. Insurance estates have very long tails. An old policy admin model from a retired product line may still matter because of an unresolved integration, a retention obligation, a legal hold, or a data subject rights process that still touches it.
Third: lock editing, centralize cleanup, and let the architecture function sort it out. That tends to create two immediate problems: political backlash and shadow architecture outside the tool.
Fourth: export and import only the “important” packages. I’ve never liked that phrase much. Important according to whom? It almost always preserves the visible diagrams while damaging less visible but more valuable things: relationships, references, tagged values, ownership metadata, lifecycle states.
So we did not redesign first.
We gathered evidence first.
The forensic assessment came before the restructure
This was the turning point, honestly. Not glamorous. Very necessary.
We ran a repository forensic assessment as a controlled discovery exercise. Not a six-month architecture theory project. Just a disciplined inventory of what was actually there, how it was being used, and where the damage was concentrated.
We looked at hierarchy depth and inconsistency. Duplicate elements by name and alias. Stereotype usage patterns. Connector volumes and invalid references. Tagged value inconsistency. Diagrams with missing elements. Coverage of owner metadata. Date-of-last-modification patterns.
That last measure was more useful than expected. A lot of content had not been touched in years, but some of it was still referenced by active diagrams. That told us quickly that “stale” did not mean “safe to delete.”
The insurance examples made the problem tangible. We found First Notice of Loss processes duplicated across commercial and personal lines, with only minor variation but completely separate modeling histories. Policy servicing APIs had been represented in some places as applications, in others as interfaces, and in one memorable case as business services. The underwriting rules engine appeared three different ways depending on which program had funded the diagram. Customer master data mappings between CRM and policy administration were inconsistent enough to derail sensible information architecture discussions.
And the mess was not evenly spread.
That mattered.
Only a minority of repository content was truly active. More importantly, a small number of critical domains generated most of the confusion: claims, policy admin, integration, and customer information. Once we saw that pattern, the strategy changed. We stopped talking about “cleaning the repository” and started talking about targeted restructuring in high-value domains.
That made the effort manageable.
It also made it easier to defend.
Principles that kept us from losing data
We wrote down a small set of non-negotiables. I’m usually a bit skeptical of principle posters in architecture programs, but here they were useful because they stopped people making bad cleanup decisions under pressure.
First: preserve element identity wherever possible. If an application object already had relationships, history, and references, we did not recreate it unless we absolutely had to.
Second: restructure packages before remodeling content. Move the house numbers before repainting the walls.
Third: separate active architecture from historical evidence. Do not force current-state consumers to dig through retired content, but do not destroy material that still has compliance, audit, or decommission value.
Fourth: standardize viewpoints, not creativity. We needed consistency in how people found and interpreted architecture, not robotic sameness in every diagram.
Fifth: every top-level domain needed an accountable owner.
And sixth: no bulk deletion without dependency review.
I feel strongly about this one. Deleting duplicate-looking elements too early is one of the fastest ways to destroy trust. Things that appear redundant often carry different relationships, different aliases, different business references, and different reporting usage. If you remove them before understanding those connections, you do not clean the repository. You amputate it.
In a regulated insurance environment, that is reckless.
The future-state repository shape was deliberately boring
People sometimes expect a heroic target structure. Something elegant. Clever. Deeply metamodel-driven.
We did not build that.
We built something boring on purpose.
The top level looked roughly like this:
- Enterprise Context
- Business Architecture
- Information Architecture
- Application & Integration Architecture
- Technology Architecture
- Transformation Portfolio
- Reference Models & Standards
- Archived Baselines
That was enough.
Not because it was perfect, but because people could navigate it without needing a briefing deck. Findability beat elegance. Repeatability beat originality.
Under Business Architecture we used domains the enterprise actually reasoned about: Distribution, Underwriting, Policy Administration, Billing, Claims, Reinsurance, Finance & Regulatory.
Under Application & Integration, we anchored around real estate concerns and canonical platforms: Guidewire claims, policy admin core, broker portal, fraud analytics, document composition, event-driven integration, IAM services, API management, and related integration building blocks.
What did we exclude from the top level? Scratch work. Personal folders. Program-specific dumping grounds. Duplicate line-of-business copies of enterprise reference material.
That last point caused some friction. A few teams wanted their own local version of enterprise concepts because it felt easier. We pushed back. The repository structure had to reflect architecture consumption patterns, not org-chart politics. Otherwise, you just preserve the mess under cleaner labels.
Here’s the kind of simplification we were aiming for:
It is not exciting.
That is the point.
Old patterns versus the new structure
A lot of the repository recovery came down to replacing recurring bad patterns with more controlled ones.
That table makes it sound tidy.
It wasn’t. There were arguments most weeks.
We made one mistake early
We tried to normalize notation too soon.
This was a bad instinct dressed up as discipline.
At the start, a few of us thought we should settle the notation question before restructuring: when to use ArchiMate, when to use UML, where BPMN belonged, which stereotypes were allowed, whether custom profiles should be retired. Reasonable questions, in theory. ArchiMate modeling guide
In practice, it derailed progress almost immediately.
Solution architects defended the notations they were comfortable with. Integration teams wanted UML sequence and component views. Business architects wanted BPMN. Enterprise architects wanted more ArchiMate. Some teams had perfectly valid reasons. Others mostly had habits. But suddenly every cleanup workshop became a philosophical argument about notation purity rather than a practical effort to restore trust in the repository. ArchiMate layers explained
So we backed off.
We focused first on structure, ownership, lifecycle, searchability, and canonical elements. Notation rationalization became a second-wave activity. That was the right call.
If everything is broken, fix the things that block trust first.
The migration sequence that actually worked
The operating model became simple: move, map, reconcile, then retire.
Not glamorous. Very effective.
Step one was to freeze high-risk package changes. Not a full repository lockdown. That would have failed politically. We just put enough control in place to stop further drift in the domains under restructure.
Step two was identifying canonical elements: applications, business capabilities, interfaces, information objects. We needed one agreed record for core assets before we could untangle duplicates around them.
Step three was moving packages into the new hierarchy with minimal content change. This mattered. We resisted the temptation to “improve” everything while relocating it.
Step four was mapping duplicates to canonical records.
Step five was repairing or redirecting relationships.
Step six was marking deprecated content before deletion.
Step seven was archiving only after usage review.
In sequence form, it looked like this:
That order reduced political friction because teams could see their content was not being erased. It preserved traceability because IDs and relationships were maintained wherever possible. And projects kept moving because we were not forcing a giant stop-the-world migration.
Claims was the proving ground
Claims was the first domain where the restructure had to prove itself.
The original state was familiar to anyone who has worked in insurance transformation. Claims intake, adjudication, fraud review, and payment were modeled differently by each program. The enterprise integration team had one set of interface artifacts. The claims modernization team had another. Kafka event streams were represented as applications in some diagrams and interfaces in others. IAM dependencies around broker access, adjuster access, and service-to-service authentication were inconsistently captured, even though they mattered for cloud deployment decisions.
We started by creating one canonical claims capability map. Not because capability maps are magical, but because everybody was using them and nobody agreed on which one was current.
Then we linked the major business processes properly: FNOL, triage, assessment, settlement. We established a single application inventory for claims platforms and separated systems of record from integration services. That sounds obvious now, but it was one of the biggest sources of confusion. Event streaming components, API gateways, and orchestration services had been drawn as if they were business applications. Once you are trying to design a cloud target state, that kind of semantic blur becomes expensive.
We also introduced lifecycle states for legacy and target applications. Again, not exciting. But very useful. Once claims teams could distinguish active, tolerating, target, deprecated, and retired states consistently, roadmap discussions sharpened quickly.
The preservation techniques were practical rather than fancy: alias retention, tagged value crosswalks, package relocation instead of recreation, and review scripts to find broken connectors. We kept historical references visible during the transition so people could still find “the old name” while learning the new canonical one.
The benefits showed up fast. Impact analysis for claims transformation became more credible. Event-driven target-state discussions improved because Kafka topics, producer systems, consumer systems, and integration services were no longer mashed together conceptually. Audit and operational resilience teams got better traceability from claims processes to systems and supporting interfaces.
That was when people started trusting the repository again.
Not universally. But enough.
Policy administration needed a different treatment
Claims got the attention, but policy administration taught a different lesson.
This domain was legacy-heavy and acquisition-heavy. There were multiple policy admin platforms from acquired businesses, old product lines still in runoff, and enough historical process and integration models to fill a small museum.
At first, some people wanted to clean this area up aggressively. I disagreed, and I still think that was the right instinct.
Deletion was too risky here. Old diagrams still mattered for decommission planning. Some “retired” systems still had unresolved downstream integrations. Certain historical models were relevant to retention obligations and regulatory evidence. In insurance, “not current” is not the same as “safe to remove.”
So instead of pushing hard cleanup, we leaned on archive strategy.
We moved obsolete but still relevant material into Archived Baselines, applied read-only controls, and made timestamps, business owner, and retirement status explicit. That reduced search clutter without pretending historical architecture had no value.
This was one of those moments where an architecture team either earns credibility or loses it. If you treat enterprise memory like clutter, the business notices.
The metadata cleanup mattered more than prettier diagrams
If I had to name the most underappreciated part of repository recovery, it would be metadata.
Not because metadata is exciting. It isn’t. But because it makes the repository usable.
We focused on owner assignment, lifecycle status, criticality, regulatory relevance, data classification, and line-of-business applicability. We kept it intentionally lean at first. Minimum viable metadata model, not taxonomy theater.
That improved searchability, reporting, impact analysis, portfolio rationalization, and cloud migration planning more than any visual cleanup did. Once you can query for applications in claims that are business-critical, contain regulated data, are still active, and depend on legacy IAM patterns, you can have much better conversations about migration sequencing and risk.
I have seen teams overengineer tagged values before they have basic ownership in place. That is backwards. If nobody owns the object, the metadata model is not your main problem.
Governance came after visible improvement
This sequencing matters, and a lot of architecture teams get it wrong.
If we had introduced heavy governance upfront, people would have treated it as bureaucracy layered on top of a repository they already distrusted. That would have failed.
Instead, once the new structure was visible and some domains were clearly easier to use, we added governance. Domain ownership. Review checkpoints for canonical element creation. Package-level stewardship. Archive and retention policy. Naming conventions. Quarterly hygiene reviews.
The model was practical. The claims architect owned business-to-application traceability in the claims domain. The enterprise information architect owned canonical customer and policy information objects. The platform architect owned integration patterns for cloud APIs, Kafka events, and common IAM dependencies.
That governance stuck because it attached to something people could now see working.
What we automated, and what we didn’t
We automated duplicate detection reports, orphaned element checks, metadata completeness reports, invalid connector scans, and stale package alerts. Those are good candidates because they surface possible issues without pretending to resolve them.
We did not automate canonical ownership decisions. We did not automate semantic duplicate resolution. We did not automate decisions about whether archived content still held compliance value. And we definitely did not automate reconciliation of business vocabulary across acquired insurance brands.
Too much automation in repository repair can accelerate bad decisions. I believe that fairly strongly. Scripts are excellent at finding suspects. They are terrible at understanding meaning.
The political layer was real
Nobody likes to admit this, but repository repair is partly political.
Some teams felt their models were being judged. Some architects had built little kingdoms inside package structures and did not want them normalized. Program leaders worried that cleanup would expose inconsistency. Business stakeholders had stopped engaging because prior architecture had been unreliable, and they did not want to sit through another argument about diagrams.
What helped was going domain by domain rather than running a central big bang. Claims and integration gave us quick wins. We preserved contributor history where possible. We made archive status explicit rather than quietly deleting old work. That reduced the emotional sting.
People accept structure more easily when they do not feel erased by it.
That sounds soft.
It isn’t. It is operationally important.
How we knew the repository was recovering
The most useful signs were behavioral.
Architects started linking to repository objects in design reviews again. Search results became usable. Fewer duplicate application elements were created in new projects. Impact analysis for API decommissioning became credible enough to support planning. Target-state diagrams began referencing canonical objects instead of copied shapes.
And architecture board conversations changed.
They stopped being dominated by “which model is right?” and shifted toward “what decision do we make?”
For the insurer, that translated into a clearer modernization roadmap for claims and policy domains, better mapping of critical processes and systems for regulatory needs, and a stronger base for cloud landing zone, integration transformation, and IAM decisions.
That is what a healthy repository is supposed to do. Support decisions. Not consume them.
If you inherit a damaged Sparx EA repository
If you are a cloud transformation architect walking into one of these situations, my advice is fairly simple.
Assess before redesign. Find the high-value domains first. Define the future structure around consumption and stewardship, not around theoretical purity. Preserve identities and traceability. Archive explicitly. Fix metadata early. Phase governance in after trust improves.
If you want a next-week checklist, do this:
- run a duplicate application inventory
- identify the top 20 active packages by actual usage
- nominate domain stewards
- define archive criteria
- pilot the new structure in one domain, not across the whole enterprise
And avoid the usual traps:
- mass deletion
- notation wars
- top-down taxonomy workshops with no repository evidence
- rebuilding diagrams from scratch unless technically necessary
You do not need a perfect metamodel to get real value back. You need enough structure and stewardship to make the repository believable again.
The bigger lesson
A Sparx EA repository is not a filing cabinet.
It is an operating model for enterprise memory.
When it fails, the root cause is usually not the tool. It is unmanaged architecture growth, weak stewardship, blurred semantics, poor lifecycle discipline, and a lack of agreed ownership. Insurance makes those weaknesses visible faster because the estate is complex, regulated, and full of historical baggage that does not disappear just because a program wants a cleaner slide.
You can restructure a broken repository without losing data.
But only if you treat the content as enterprise memory, not clutter.
That was the real lesson from this insurer. We did not build a perfect repository. I am not sure such a thing exists. We built one people trusted enough to use for decisions again.
That is the bar that matters.
FAQ
How do you decide what to archive versus what to keep active?
Look at current usage, dependency relevance, regulatory value, decommission planning needs, and business ownership. If it is not current but still materially relevant, archive it explicitly rather than deleting it.
Can you restructure Sparx EA without a full repository freeze?
Yes. In fact, you usually should. Freeze high-risk package changes in target domains, but avoid a total lockdown unless the repository is in severe operational distress.
What’s the safest way to handle duplicate elements with live relationships?
Identify a canonical element, map duplicates to it gradually, preserve aliases and historical tags during transition, and review relationships before retiring anything.
Should we standardize on one notation before cleaning the repository?
Usually not. Fix trust, structure, lifecycle, and ownership first. Notation rationalization matters, but it is rarely the first blocker.
How much metadata is enough to make the repository useful again?
Less than people think. Start with owner, lifecycle, criticality, regulatory relevance, and a small number of business context fields. Keep it maintainable.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.
How does ArchiMate support enterprise architecture?
ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.
What tools support enterprise architecture modeling?
The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.