⏱ 25 min read
If you work in retail architecture, you rarely begin with a clean repository and a neatly agreed metamodel. You begin with a mess.
Usually there is a central architecture function trying to hold together some version of enterprise standards, roadmaps, and investment priorities. Around that sits a set of domain architects embedded across merchandising, e-commerce, supply chain, stores, payments, loyalty, customer identity, data, and sometimes a separate marketplace team if the retailer has evolved that way. Then compliance joins the conversation with perfectly fair questions on a completely unfair timeline: who owns this customer data flow, where is cardholder data segmented, which application enforces retention, what decision approved this exception, and can you prove it?
Meanwhile, Sparx EA is already in the picture. Of course it is. Nobody is having a fresh debate about whether to adopt it. The organization made that choice years ago. The real issue is that six teams are using it in six different ways. One group models applications well but barely touches business capabilities. Another produces strong diagrams but almost never reuses elements. A third uploads vendor PDFs and treats them as architecture evidence. A fourth uses package names that only make sense if you happened to be in a steering committee meeting eighteen months ago.
That is the real starting point.
And the tension underneath it is familiar. Federated autonomy versus repository discipline. Speed versus traceability. Local convenience versus enterprise coherence. Retail sharpens all of this more than many industries because the architecture is cross-cutting by nature. Omnichannel order journeys do not care about your org boundaries. PCI-sensitive payment flows certainly do not. Pricing and promotions logic bleeds across merchandising, commerce, stores, loyalty, and finance in ways that get ugly fast. Add third-party logistics, marketplaces, cloud integrations, Kafka event streams, IAM dependencies, and regional store variants, and the repository becomes part knowledge system, part control mechanism, part political battlefield.
So this article is not really about folders.
It is about operating model, with Sparx EA as the place where that operating model either becomes visible and usable, or collapses into diagram sprawl. In my experience, package strategy fails when it reflects what architects say they value instead of how teams actually behave when delivery pressure and audit pressure show up together. Sparx EA training
And pressure is the point. Regulatory scrutiny exposes weak repository design faster than any architecture review board ever will.
The mistake most teams make in Sparx EA
Here is the blunt version: most teams organize packages around whatever feels intuitive at the time.
That may mean mirroring the org chart. Or the current transformation portfolio. Or a generic UML taxonomy someone picked up in training years ago. It feels harmless early on. It never stays harmless.
Org-chart-driven package structures are especially tempting in federated teams because ownership appears obvious. The merchandising architect gets a merchandising tree, the payments architect gets a payments tree, and so on. But retail orgs change constantly. Customer and loyalty merge. Digital and stores split. Supply chain gets folded into operations. Suddenly your package semantics have changed even though the architecture itself has not.
Project-based structures are no better, and in some environments they are worse. Every strategic initiative creates its own copy of reality. “POS Modernization” models transaction, customer, inventory, payment. Then “Unified Checkout” models them again. Then “Returns Transformation” creates another set because the first two are too hard to find or too hard to trust. You do not get reuse. You get archaeology.
Technology-only structures fail in their own way. A giant “Applications” tree with no lifecycle, no ownership, and no business accountability is common in Sparx EA repositories. From a distance it looks tidy. Up close it is just a list. Nobody can tell which applications are authoritative, which are transitional, which ones handle regulated data, or who is actually allowed to update the model. Sparx EA guide
I have also seen repositories where the architecture review board spent more effort governing diagrams than governing reusable assets. In practice, that is almost always a sign that the repository has become a presentation store rather than an architecture system.
A retail example makes this pretty obvious. Take a “Store Systems” package that contains POS, clienteling, local inventory, digital receipts, workforce scheduling, queue management, handhelds, store network devices, and maybe a few edge compute components for good measure. Everything operational in stores gets dumped there because “it’s all store tech.” But those things do not share the same lifecycle. The business concepts they support are different. Their regulatory relevance is different. Their ownership is different. Some are stable domain assets. Some are initiative designs. Some are deployment evidence. Some are just device references. Once you mix them together, you lose the ability to separate what is enduring from what changes every release.
Before you decide package structure, you have to decide what the federation is actually federating.
That sounds abstract, but in practice it is not.
What a federated architecture team actually needs from the repository
A federated architecture team is not decentralized chaos. It is a deliberate compromise.
Domain architects need controlled independence. They need to move at the speed of their domain, make local decisions, and model things in enough depth to be genuinely useful. Enterprise architecture needs comparability, traceability, and enough consistency that cross-domain analysis is still possible. Risk and compliance teams do not need elegant diagrams. They need evidence they can rely on.
That leads to a very different view of the repository.
What matters is not whether the package tree looks neat. What matters is whether the repository gives you clear ownership boundaries, stable identifiers for important assets, predictable reuse patterns, decision traceability, and an audit-friendly change history. Those are the outcomes that matter.
And it helps, a lot, to separate three things that teams often mash together:
- collaboration structure
- content structure
- governance structure
Those should not be assumed to be the same.
The people who collaborate together are not always the people who own the same architectural assets. The packages where content lives are not automatically the same as the governance boundaries through which changes are approved. When teams force all of that into one structure, friction is guaranteed.
Take payment tokenization in a regulated retailer. It spans payments, customer account services, fraud platforms, store checkout, e-commerce, IAM, and often data platforms consuming payment events through Kafka for analytics or reconciliation downstream. No one team can model the full picture without crossing into someone else’s territory. If the repository assumes every package is a self-contained domain silo, you end up with duplication or endless permission battles. Usually both.
A more practical sequence works better:
- Define modeling intent.
- Design package strata.
- Assign ownership.
- Enforce creation rules.
- Govern changes proportionately.
- Measure drift.
That order matters more than people think.
Step 1 — Decide what belongs in Sparx EA at all
This is one of the least discussed decisions in architecture tooling, and in my view one of the most important.
Not every artifact deserves repository permanence.
Teams get into trouble because they treat Sparx EA as both the canonical architecture repository and the dumping ground for every visual thought they have ever had. That creates bloat, and repository bloat is governance debt. Once a package exists, someone eventually assumes it matters. Sparx EA maturity assessment
I usually split content into four asset classes:
- canonical architecture assets
- working design artifacts
- temporary initiative diagrams
- imported reference material
Canonical assets belong in the repository. These are things other teams will reuse, things that define ownership or standards, and things that support controls or traceability. Capability maps for merchandising and fulfillment? Yes. The target-state payment service interaction model? Yes. The authoritative customer identity service model tied to IAM patterns and consent controls? Definitely yes.
Working design artifacts are more conditional. Some deserve promotion into canonical assets later. Some should stay local to a solution effort and expire when that effort is done.
Temporary initiative diagrams are often useful, but only for a while. A whiteboard-like model for one sprint’s returns exception handling may help a team reason through a problem. It does not automatically belong in the long-term repository.
Imported reference material is where discipline usually breaks down. Vendor PDFs, implementation guides, screenshots, and random cloud architecture exports get uploaded into model packages because it is convenient. Usually they should not be there, or only as governed references with metadata and a clear purpose. A vendor deck is not architecture truth. I have had to unwind that confusion more than once.
The basic criteria are straightforward:
- will this be reused?
- does it support a control obligation?
- does it define ownership or standards?
- does another team need to trust it?
If the answer is no across the board, think twice before adding it.
A repository where everything is labelled architecture is a repository where nothing is really governable.
Step 2 — Build the package strategy around asset lifecycle, not just domain
This is the core recommendation, and in practice it is the one that changes repository behavior the most.
Package hierarchy should reflect both domain ownership and architectural lifecycle.
A pure domain tree sounds sensible but breaks down quickly. It tells you where something conceptually belongs, but not what kind of thing it is, how stable it should be, how tightly it should be governed, or whether it is reusable beyond a single initiative. In federated teams, that missing lifecycle signal becomes a real problem fast.
What works better is a layered package concept. Not a rigid universal metamodel, just a few clear strata:
- enterprise reference layer
- business/domain architecture layer
- solution architecture layer
- implementation/deployment evidence layer
- governance/decision layer
These layers can coexist without forcing every team into one modeling style.
The enterprise reference layer contains things that should change slowly and be broadly reusable: integration patterns, eventing standards for Kafka, data classification rules, IAM principles, PCI segmentation standards, approved cloud landing zone patterns, canonical relationship types, and shared taxonomy primitives.
The business/domain architecture layer is where domain architects do their real long-lived work: Order Management, Pricing, Loyalty, Store Operations, Inventory, Customer Identity. This is where stable domain concepts, capabilities, business services, key information objects, and bounded domain relationships should live.
The solution architecture layer is where initiative-specific designs belong. Buy Online Pick Up In Store modernization. Mobile POS rollout. Marketplace returns integration. New fraud orchestration. These packages will change quickly, and that is fine. They should trace back to domain and reference assets rather than replace them.
Then there is implementation and deployment evidence. This is often neglected, but in regulated environments it matters. Which payment interfaces were deployed in which regions? What AWS account or Kubernetes cluster hosts the tokenization service? Which API gateway routes traffic to the new provider? Which store estate still uses a deprecated edge component? This is not the same as solution design, and bundling the two together muddies both.
Finally, there is the governance and decision layer: ADRs, review outcomes, waivers, policy exceptions, and architecture decisions tied to actual model elements.
That last part matters. A lot. Packages should make bad behavior hard, not merely document that it is prohibited.
Here is a concrete package model that has worked better than the usual alternatives.
A few interpretation notes matter more than the table itself.
First, reusable elements should live in reference or domain packages, not in initiative packages. If a solution package creates a useful application component, domain service, or business object that survives the initiative, it should be promoted into the appropriate authoritative package.
Second, diagrams can live close to the consumer context, but elements should live where they are owned. That sounds obvious until you watch teams create duplicate elements because they want the diagram to be “self-contained.”
And third, element ownership matters more than diagram ownership. Every time. I have not seen many exceptions to that.
Step 3 — Define ownership with uncomfortable clarity
A lot of repositories fail because “shared” ends up meaning “editable by whoever got there first.”
That is not collaboration. That is entropy.
Ownership needs to be assigned at several levels:
- package owner
- content steward
- approval authority
- contributor roles
Those are not the same thing. The package owner is accountable for the package boundary and quality. The content steward handles day-to-day upkeep and quality control. The approval authority decides on certain kinds of changes. Contributors can add or suggest content within agreed rules.
Stewardship is not admin rights, and admin rights are not architecture authority. That distinction saves a lot of pain. TOGAF roadmap template
Some practical rules help:
- only designated owners create root packages
- cross-domain reuse happens by referencing, not cloning
- deprecation requires a named decision owner
- package ownership changes must be explicit, especially after re-orgs
Retail examples expose where this matters quickly. The loyalty architect may own customer engagement domain objects, while the payments architect references them for token-linked offers or refund scenarios. That is fine. What is not fine is a store operations architect quietly redefining “transaction” to mean only till events because that suited one rollout.
I have also seen platform teams try to take technical package control over business-facing assets because those assets eventually map to systems they operate. That usually creates an accountability mismatch. On the other side, I have seen central EA overreach into every edit, which slows teams down enough that they retreat to PowerPoint and spreadsheet architecture.
The right answer is usually less democracy and more clarity.
Not centralization for its own sake. Just explicit rights and responsibilities.
A detour that matters: diagrams are not the architecture repository
This is where I get a little opinionated.
Teams obsess over pretty diagrams because diagrams are visible. They are reviewable. They look like architecture. But if your package strategy is really just a filing system for pictures, you have missed the point of Sparx EA.
The value of the repository is in elements, relationships, tags, statuses, ownership, versioning, and traceability. Diagrams are views into that model.
Get that wrong and the consequences show up immediately: duplicate elements across diagrams, fake consistency, no lineage from control obligations to application components, no trustworthy impact analysis.
I once saw a fraud service appear as three different elements in three different domains: e-commerce, payments, and customer service. All three teams believed they were modeling the same thing. They were not using the same element. By the time the architecture review happened, nobody could say which package was authoritative. That is how you end up unable to answer very basic governance questions when pressure hits.
A practical governance move here is to review element reuse rates and duplicate rates, not just diagram counts.
Diagram counts are vanity metrics.
Step 4 — Create package rules for federated collaboration
Once the structure exists, you need behavioral rules. Otherwise the repository simply reflects the loudest team, or the fastest one.
At minimum, define:
- where new elements may be created
- who can create relationships across domains
- when controlled vocabularies and stereotypes must be used
- how external vendor and SaaS representations should be handled
- what gets promoted from solution packages into authoritative packages
Some minimum package rules I recommend:
- no direct editing of enterprise reference assets without a governance path
- no initiative package may own enterprise business capabilities
- no copy-paste of application or data object elements across domains
- all solution packages must trace to relevant domain and reference assets
- vendor products in evaluation stay separate from approved enterprise application inventory
- deployment instances may be added by delivery teams, but they do not redefine logical ownership
Retail examples make these rules easier to defend. A new marketplace integration should reference the existing order and product entities, not create “Marketplace Order” as a duplicate enterprise concept unless there is a genuinely different bounded context and that distinction is intentional. A regional store rollout package can add deployment instances, local integrations, and transition states; it should not redefine the checkout application itself.
Sparx EA gives you enough mechanism to support this if you use it sensibly: security groups, locked packages, naming conventions, controlled package structures, and MDG or custom stereotypes where they actually add clarity.
But there is a warning here. Too much metamodeling becomes its own bureaucracy. I have seen teams create elaborate stereotype hierarchies that nobody understands outside the architecture tool specialists. That is not maturity. That is overhead.
Keep the rules few, visible, and enforced.
What to govern tightly, and what to leave alone
Not all packages deserve the same gatekeeping. This is where architecture teams often overcorrect.
Govern tightly where the blast radius is high:
- enterprise taxonomy
- regulated data classifications
- customer identity model
- payment and security architecture patterns
- authoritative application inventory relationships
- IAM trust boundaries
- event topics and canonical contracts where Kafka-based integration is an enterprise dependency
Govern lightly where exploration is the point:
- exploratory transition diagrams
- temporary roadmap views
- team-specific analysis models with no cross-enterprise dependency
- short-lived option analysis packages that will not become reference assets
In regulated retail, the tight governance list is not theoretical. Payment card flows need to be traceable. Customer consent and retention mappings often need defensible lineage across CRM, loyalty, support tooling, and marketing exports. Promotions can carry legal and financial implications in some markets, so pricing decision transparency matters more than teams often expect.
A practical cadence helps. Quarterly review for reference assets. Event-triggered review for risk-sensitive domains. Lightweight peer review for solution packages. And one nuance I think matters a lot: governance should follow blast radius, not hierarchy level.
A lower-level deployment package affecting tokenization or IAM federation may deserve tighter scrutiny than a lofty target-state diagram nobody will ever implement.
Step 5 — Handle cross-domain architecture without turning the repository into a battlefield
This is federated reality. The important things cut across domains.
Omnichannel returns touch stores, commerce, finance, fraud, inventory, customer servicing, and often payments. Customer identity unification affects loyalty, marketing, support, IAM, digital channels, and data platforms. Payment orchestration cuts across checkout, risk, settlement, order lifecycle, cloud networking, and security operations.
If the repository has no pattern for cross-domain work, people invent one. Usually badly.
What works better is a simple handling pattern:
- one accountable lead package
- referenced assets from participating domains
- explicit dependency map
- shared decision log for boundary changes
The lead package is not a junk drawer. It is the coordination context for the architecture concern. It owns the integrative view, not everyone else’s domain assets.
What not to do matters just as much. Do not create a generic “cross-domain” package where half-defined business objects go to die. And do not let each domain model the same business object differently and hope some future reporting layer will reconcile it.
Define a source-of-truth package per asset type, not per meeting outcome.
That sounds small. It is not.
The governance board should review package hygiene, not just architecture slides
A lot of governance boards are still optimized for presentation theater. They debate target-state diagrams, admire notation, and ask whether a box should move left or right. Then audit season arrives and everyone discovers the repository quality is poor. ArchiMate in TOGAF
Boards should review package hygiene as a first-class governance concern.
That means approving package taxonomy changes, arbitrating ownership disputes, monitoring duplicates and orphaned content, reviewing exception expiry, and making sure traceability exists for regulated changes. Those are governance activities. Arguing over whether one API should be shown above another on a slide is not.
Useful review artifacts include:
- duplicate element reports
- packages with no named owner
- stale solution packages past go-live
- exceptions older than their agreed threshold
- cross-domain assets with conflicting definitions
- reference assets changed outside the governance path
I have seen store platform transformations leave behind dozens of transitional packages that nobody retired. Every future initiative then has to guess which one is current, which one is superseded, and which one existed only for a region-specific pilot. That kind of clutter is not harmless. It slows delivery and weakens control evidence.
Mistakes we made, and what they taught us
This is the part teams usually skip, but it is where most of the useful lessons live.
We mirrored the operating model exactly once. It seemed sensible. Every domain got a clean top-level area. Six months later, a re-org merged digital and loyalty under customer, split stores platform engineering from store product, and moved payments under finance technology. Suddenly package ownership was politically contested and semantically broken. The correction was to decouple the package strategy from the org chart and keep ownership metadata explicit.
We allowed project teams to create application elements in initiative folders because they were moving quickly and central review was slow. Predictably, the application inventory duplicated itself. Some apps had three names. Others had one name but multiple inconsistent relationships. The fix was to centralize authoritative assets while still federating contribution through controlled update paths.
We treated vendor products as if they were stable enterprise applications before contracts were signed. That created false certainty in target-state models and made architecture reviews look more committed than procurement reality justified. Since then, candidate solutions get their own status and package treatment.
We mixed current-state, target-state, and retired assets in the same package tree. It felt efficient. It was not. Users could not tell what was live, what was planned, and what was historical. Lifecycle status had to become mandatory and visible.
And yes, we let exceptions live in email threads and meeting notes instead of linking them to model elements with expiry dates. That one always comes back during audit or incident review. Always.
None of these were theoretical mistakes. They all happened because delivery pressure was real and the repository rules were vague.
Step 6 — Introduce lifecycle states and archive rules early
Package strategy without lifecycle discipline becomes a museum.
You need lifecycle markers for elements, packages, decisions, standards, and solution architectures. Not because architects love statuses, but because users need to know what they can trust.
A workable set is usually enough:
- proposed
- approved
- active
- transitional
- deprecated
- retired
- archived
In retail, these states matter in very practical ways. A legacy POS may still be active in selected franchise regions even while deprecated enterprise-wide. A fraud provider may be deprecated but retained as fallback during a migration. An old loyalty integration may be retired operationally but archived because it forms part of audit evidence for historical retention handling.
Archive rules need to be explicit too:
- do not casually delete evidence-bearing packages
- separate active navigation from archival retention
- preserve references needed for regulatory traceability
- archive stale initiative content deliberately after go-live or closure
- make archived content visible enough to find, but not prominent enough to confuse active work
Users need a usable repository, not a perfect historical landfill.
Step 7 — Make traceability useful enough that teams will maintain it
Traceability is one of those words architects say with great seriousness and teams hear as admin burden.
The only way it survives is if it is visibly useful.
The places where it pays off are concrete: business capability to application mapping, control obligations to technology components, customer data objects to systems and interfaces, decision records to affected architectures, IAM policies to application trust boundaries, Kafka topics to consuming and producing services when event lineage matters.
A retail example makes this tangible. “Refund to original tender” is not just a policy statement. In practice it touches the returns process, store or digital channel workflow, payment service, settlement batch, reconciliation reporting, fraud checks, and sometimes customer support overrides. If you can trace those relationships, impact analysis is faster and control evidence is stronger.
Another example: personal data retention. If the policy changes, you need to know which systems hold the relevant customer data objects, where they are exported, which SaaS platforms receive them, and what deletion or suppression mechanisms apply. That is architecture value, not documentation theater.
The trick is to keep mandatory traces few but meaningful. Do not try to trace everything. Teams will stop maintaining it. Relationship types also need to stay limited and understandable. Too many custom connectors in Sparx EA create modeling paralysis.
If nobody can remember the difference between six near-identical relationship stereotypes, you have already lost.
When package strategy collides with delivery pressure
This is the real test.
Product teams under release deadlines will bypass governance if the repository feels slow, abstract, or disconnected from delivery. They will create shadow diagrams in PowerPoint, Visio, Miro, or draw.io. They will set up duplicate “temporary” packages. Ownership metadata will go stale because nobody sees a reason to update it before a release.
And honestly, sometimes that is the architecture function’s fault.
The practical responses are not glamorous: lightweight intake for new packages, standard starter structures for solution teams, architecture coaching embedded in domains, governance SLAs that people can actually rely on, and quick escalation paths for cross-domain conflicts.
Retail adds seasonal pressure that many governance models underestimate. Holiday trading freeze windows, peak promotions, regional events, and provider cutover constraints force rapid but controlled design changes. If your package strategy only works in calm periods, it is not a strategy.
It is a fair-weather preference.
A practical rollout sequence for a retail architecture function
Big-bang repository cleanup usually fails. Too much content, too many opinions, too little patience.
A phased rollout is more realistic:
- assess current repository sprawl
- identify authoritative assets
- define package strata and ownership model
- establish minimum modeling rules
- migrate only what is worth governing
- introduce board metrics
- train by domain, not by generic tool class
That last point matters. Generic Sparx training is rarely enough. Domain architects need examples grounded in payments, customer identity, order management, merchandising, or store operations. Otherwise the rules feel abstract and are treated as abstract.
In retail I would start with high-regulation, high-change domains first: payments, customer identity, and order management. Those areas usually expose the sharpest cross-domain and compliance problems. Once the model works there, expand into merchandising, supply chain, and store operations.
Migration itself needs restraint. Preserve IDs and traceability where possible. Do not remodel everything just for aesthetic consistency. Clean architecture is nice. Trusted architecture is better.
Metrics worth tracking in a federated Sparx EA model
I am skeptical of most architecture metrics, but a few are genuinely useful.
Track:
- packages with named owner
- duplicate core elements
- percentage of solution packages linked to domain and reference assets
- expired exceptions
- archived versus active package ratio
- number of regulated controls with model traceability
- cross-domain assets with unresolved ownership
- stale packages with no updates beyond an agreed threshold
Avoid fetishizing:
- raw diagram count
- total elements created
- number of reviews held
Those tell you almost nothing.
The right metrics should indicate whether the repository can support audit, impact analysis, modernization planning, and cross-domain delivery. They should trigger conversations, not vanity dashboards.
Closing argument — package strategy is governance made visible
In a federated architecture team, package strategy is not housekeeping.
It is how authority, accountability, reuse, and evidence are encoded in the repository. If that encoding is weak, governance becomes performative. If it is clear, teams can move faster without making enterprise truth unreliable.
That is especially true in retail. Under regulatory scrutiny and omnichannel complexity, repository structure becomes part of the control environment. Not the whole thing, obviously. But part of it. A payment architecture you cannot trace, a customer identity model with ambiguous ownership, or a pricing capability represented three different ways is not just messy architecture. It is operational and control risk.
So the goal is not an elegant taxonomy admired by architects.
It is a repository that lets domain teams work with autonomy while preserving enough coherence that the enterprise can trust its own architecture. That is what actually works.
FAQ — Questions architecture teams usually ask too late
How many root packages is too many in a federated model?
More than the team can govern coherently. I generally prefer fewer root packages with clear strata rather than lots of roots by team or initiative. Too many roots usually means taxonomy drift is already underway.
Should each domain have its own repository branch or a shared one with controls?
Usually a shared repository with controls works better for cross-domain traceability. Separate branches sound autonomous but often create reconciliation problems. I would only split physically when legal, security, or organizational separation genuinely requires it.
How do we handle mergers, divestments, or retail banners with semi-independent architecture?
Use lifecycle and ownership metadata aggressively, and treat banner-specific architecture as scoped domain variants rather than entirely separate taxonomies unless that independence is real and lasting. Temporary corporate structures should not permanently distort package semantics.
What belongs in Sparx EA versus Confluence, Jira, or document repositories?
Put canonical model assets, standards, traceability, decisions, and authoritative relationships in Sparx EA. Put narrative guidance, team playbooks, meeting notes, and delivery workflow in Confluence or Jira. Do not force the architecture repository to become the knowledge base for everything.
When is it acceptable to duplicate an element temporarily?
Rarely, and only with explicit intent to reconcile. For example, during migration from a poor legacy repository where IDs cannot be preserved cleanly. Temporary duplication without an owner and end date becomes permanent duplication.
How do we keep package governance from becoming central EA bottleneck behavior?
By governing the right things tightly, leaving low-blast-radius work alone, embedding architects in domains, and setting service expectations. Control without responsiveness just drives people off-platform.
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.