1. TOGAF-Based Repository Structure in Sparx EA
TOGAF is widely adopted in enterprise architecture. Its ADM (Architecture Development Method) guides modeling across business, application, data, and technology domains.
- Architecture Vision (Phase A) - Business Architecture (Phase B) - Application Architecture (Phase C) - Data Architecture (Phase C) - Technology Architecture (Phase D) - Opportunities & Solutions (Phase E) - Migration Planning (Phase F) - Implementation Governance (Phase G) - Architecture Change Management (Phase H) - Requirements Management - Reference Models & Standards - Architecture Repository - Architecture Governance - Stakeholder Views & Dashboards
Advantages:
- Follows a formal methodology for architecture lifecycle
- Supports traceability and audit-readiness
- Ideal for large, regulated environments
2. Zachman Framework Repository in Sparx EA
The Zachman Framework emphasizes perspectives and abstractions. It’s ideal for organizations focused on traceability and completeness across viewpoints.
- Planner (Scope) - Owner (Business Concepts) - Designer (Logical Models) - Builder (Technology Model) - Subcontractor (Detailed Specs) - Enterprise Operation (Live Systems)
Each row covers: What, How, Where, Who, When, and Why.
Advantages:
- Clarifies responsibilities and viewpoints
- Improves architecture completeness through a matrix view
- Ideal for traceability across abstraction levels
3. Agile and Product-Centric EA Repository Structure
For teams using SAFe, Scrum, or domain-driven design (DDD), this structure enables modular, decentralized modeling aligned with product teams.
- Product/Capability Areas
- Product A
- Epics & Stories
- Architecture Models
- Roadmap & Milestones
- Personas & Use Cases
- Domain Models
- APIs & Integrations
- Cloud & DevOps Stack
- Reusable Patterns & Components
- Developer Views & Team Workspaces
Advantages:
- Fast and scalable for agile delivery environments
- Supports domain-driven design and decentralized governance
- Easy to align architecture with DevOps pipelines
4. Data-Centric Repository Structure
Designed for data governance, analytics, and integration, this structure supports end-to-end information lifecycle management. integration architecture diagram
- Business Glossary & Terminology - Data Domains - Data Models - Conceptual - Logical - Physical - Metadata & Lineage - Master Data Management - Data Integration (ETL, APIs, Streaming) - Data Governance (Stewardship, Quality, Compliance)
Advantages:
- Excellent for compliance, data lineage, and governance
- Aligns well with data catalogs and regulatory reporting
- Helps standardize data views across departments
5. Project & Portfolio-Based Structure
This structure supports IT project delivery and transformation initiatives across portfolios. ArchiMate for digital transformation
- Project Portfolio
- Project A
- Scope & Vision
- Business & IT Requirements
- Solution Architecture
- Roadmap & Milestones
- Architecture Standards
- Risk & Compliance Models
- Transition Architectures
- Program Roadmaps
Advantages:
- Keeps each project self-contained and traceable
- Supports architecture governance and milestone tracking
- Useful for architecture in transformation programs
The Hybrid Most Estates Actually Run
The five structures above are presented as alternatives, and in the field almost nobody runs one pure. The shape that survives contact with real organisations is a hybrid with three distinct zones, each governed differently — and being explicit about the zones matters more than which framework labels the folders.
The top zone is the reference library: principles, standards, the approved building blocks, the capability map. TOGAF-flavoured, slow-moving, tightly permissioned, and the only zone where a framework purist would recognise their diagram. The middle zone is the domain landscape — one package tree per business domain holding the current-state applications, data and technology for that domain, owned by that domain's architect and structured identically across domains, because the portal, the scripts and the new joiners all rely on the symmetry. The bottom zone is working space: per-initiative packages where solution work happens at speed, deliberately looser, with the rule that anything an initiative wants to promote into the domain landscape passes review on the way. Content flows upward through governance, never sideways by copy — and that single flow rule does more for repository quality than any amount of folder taxonomy.
What makes the hybrid stable is that it maps zones to change velocity. Reference content changes quarterly, landscapes monthly, working space daily — and putting them in separate zones means locking, review and publication can each run at the pace their zone needs. The pure structures fail precisely here: a Zachman grid asks daily solution work to live inside a classification scheme built for reference material, and an agile product structure asks slow governance content to live inside team folders that reorganise every planning cycle. Match governance to velocity and the framework debate mostly dissolves.
Structure Is Also Your Security and Locking Model
A Sparx repository structure is not just navigation — packages are the unit at which EA applies security, locks and baselines, which means the folder tree quietly is the access-control design. This deserves to be decided consciously rather than inherited from whatever taxonomy felt tidy.
Three consequences follow. Domain packages should align with team boundaries so that "Require User Lock to Edit" produces locks people expect — an architect locking their own domain inconveniences nobody, while a package that interleaves two teams' content generates the lock collisions that make people hate the feature. Sensitive perimeters — the security architecture, an unannounced programme — need their own top-level branches, because package security in EA flows down the tree and a perimeter buried inside a shared branch inherits that branch's audience. And baselines operate per package too, so the packages you will want to baseline as a unit — a domain's current state before a transformation, the reference library before a standards revision — should exist as clean subtrees rather than as selections someone assembles by hand each quarter. Structure drawn with these three uses in mind almost designs itself; structure drawn purely for browsing gets redesigned the first time security or governance arrives with requirements.
Restructuring a Live Repository Without Breaking It
Most readers of this article are not choosing a structure — they have one, it has decayed, and the question is whether reorganising is safe. The reassuring half of the answer: element identities in EA are GUIDs, so moving packages breaks neither relationships nor diagrams nor cross-package traces. The model's semantic web survives any amount of tree surgery.
What does break is everything that referenced paths: document generation templates pointed at package locations, scripts that walk from a named root, model search definitions, Prolaborate section configurations, and — most often forgotten — the mental maps of every user, which are a real dependency with a real migration cost. The restructuring playbook is therefore less about the model than about the periphery: inventory the path-dependent artefacts first (search the script library and RTF templates for package names), stage the move in one announced weekend rather than as a months-long drift, leave a small note element behind at each old top-level location for a quarter pointing to the new home, and re-run the full publication and document generation immediately after, because those two consumers will find whatever the inventory missed. Done this way, a reorganisation is a weekend and a week of grumbling; done by drift, it is six months of "where did the integration models go" and a script library nobody trusts.
The Signs a Structure Is Failing
Finally, the diagnostic list, because structures decay gradually and the trigger for action is easier to see with symptoms named. Duplicate elements appearing in different branches — the same application modelled twice because neither team knew of the other's copy — is the classic, and it means the domain boundaries no longer match how work arrives. A "Misc", "Temp" or personal-name package accumulating real content means the structure has no obvious home for a whole category of work. Browsing time creeping up — people finding things through search alone because the tree stopped meaning anything — is quieter but just as damning. And lock collisions between teams that should never touch the same content mean the packages have drifted out of alignment with the organisation.
Any two of these together justify the weekend of surgery described above. The structures in this article are not right answers to copy; they are starting points whose only test is operational — can people find, edit, secure and publish without friction — and a practice that reviews that test annually keeps its repository navigable for a decade, while a practice that treats structure as a launch-day decision rebuilds from frustration every three years.
A Starter Tree You Can Adopt Tomorrow
Because abstractions about zones convince and templates get adopted, here is the concrete top level we hand to new estates, ready to be renamed into your vocabulary:
- 00 Governance — principles, standards, decision records, the metamodel documentation and viewpoint contracts. Tightly permissioned, baselined at every standards revision.
- 01 Reference — the capability map, approved building blocks, imported control catalogues, master data about the estate. Changed through review only.
- 02 Landscape — one child package per business domain, identical internal shape (Applications / Data / Technology / Integrations), owned by that domain's architect. The publication's main source.
- 03 Initiatives — one child per active programme, looser rules, promoted content flows to 02 through review, archived wholesale when the initiative closes.
- 04 Operating — the practice's own machinery: script library, document templates, validation fixtures, import staging.
- 09 Archive — retired content, read-only, excluded from publication scope but present for provenance.
The numbering is deliberate — it pins the browser order to the governance gradient, most controlled at the top — and the two-digit gaps leave room for the additions every estate eventually wants without renumbering. Adopt it as-is, rename the labels, and spend the energy this template saves on the part no template can supply: writing the one-line ownership note inside each package, because a tree whose every branch can answer "whose is this and what belongs here" is the entire difference between structure and decoration, whatever the folders are called.
Conclusion
The best Sparx EA repository structure depends on your modeling goals and organization context. Whether you follow TOGAF, Zachman, Agile, or a hybrid, consistent structuring improves usability, traceability, and long-term maintainability. ArchiMate in TOGAF ADM
If you’d like hands-on training tailored to your team — Sparx Enterprise Architect, BPMN, SysML or the Archi tool — or modelling coaching in ArchiMate and TOGAF-aligned governance, you can reach us via our contact page.
Getting more from your Sparx EA investment
Most organizations use less than 20% of Sparx Enterprise Architect's capabilities. Three underutilized features deliver disproportionate value when activated: model validation, document generation, and the automation API. Sparx EA training
Model validation checks every element and relationship against metamodel rules, catching errors that human reviewers miss. Enable ArchiMate validation under Specialize → Technologies to prevent invalid relationships (for example, a Composition between elements in different layers). Add custom validation scripts that enforce your organization's naming conventions, required tagged values, and maximum elements per diagram.
Document generation produces Word or PDF reports directly from the model. Configure templates that pull element properties, tagged values, relationships, and diagrams into formatted documents. When the model changes, regenerate the document — it is always synchronized. This eliminates the manual document maintenance that typically consumes 30-40% of architect time.
The automation API (JavaScript, VBScript, or .NET) enables bulk operations that would take hours manually: updating tagged values across hundreds of elements, generating traceability matrices, exporting element catalogs to Excel, or validating naming conventions. A single validation script that runs nightly catches more errors than a monthly manual review.
Frequently Asked Questions
What is Sparx Enterprise Architect used for?
Sparx Enterprise Architect (Sparx EA) is a comprehensive UML, ArchiMate, BPMN, and SysML modeling tool used for enterprise architecture, software design, requirements management, and system modeling. It supports the full architecture lifecycle from strategy through implementation.
How does Sparx EA support ArchiMate modeling?
Sparx EA natively supports ArchiMate 3.x notation through built-in MDG Technology. Architects can model all three ArchiMate layers, create viewpoints, add tagged values, trace relationships across elements, and publish HTML reports — making it one of the most popular tools for enterprise ArchiMate modeling.
What are the benefits of a centralised Sparx EA repository?
A centralised SQL Server or PostgreSQL repository enables concurrent multi-user access, package-level security, version baselines, and governance controls. It transforms Sparx EA from an individual diagramming tool into an organisation-wide architecture knowledge base.
And whichever structure you adopt, write the decision down — one page, the zones, the ownership rule, the promotion flow — and put it in the 00 Governance package where the structure itself can cite it. Repositories outlive their designers; the note is how the design survives the handover.
A closing reassurance for the team staring at a decade of accumulated structure and dreading the weekend of surgery: every well-structured repository you will ever envy went through exactly that weekend, usually later than it should have. The GUIDs will hold, the links will survive, and the Monday-morning grumbling fades in a fortnight. What does not fade is the compounding return of a tree that means something — faster onboarding, cleaner locks, saner publications — collected daily, for years, from two days of deliberate housekeeping.
The structures in this article, the hybrid, the starter tree — none of them is the point. The point is that a repository's folder tree is a set of promises: about who owns what, who may change what, what gets published and what stays private. Choose a structure that makes promises your organisation can keep, write them down where the tree can cite them, and review them once a year. Everything else is labels.