AI Power Tools for Sparx EA Docs Release 3.6.4

Compare the as-is and to-be architecture

Goal

See what a target architecture adds, removes and changes compared with the current one, and what depends on each removal. For an architect preparing a roadmap, a transition plan or a review of a proposed design. You end with a gap list (added, removed, changed, with the properties that changed) and the dependants of everything removed, with the method stated so the list can be trusted.

Where it runs

This scenario needs the MCP server. Computer use covers its UI steps.

Surface How it runs
Claude Code Fully
Claude Cowork Fully
Claude Desktop chat Fully, except the UI steps, which you perform: starting EA and opening the model, and handling any dialog EA raises (you screenshot it, paste the screenshot into the conversation so the assistant can analyze it, then dismiss it).
VS Code with GitHub Copilot Fully, except the UI steps, which you perform: starting EA and opening the model, and handling any dialog EA raises (you screenshot it, paste the screenshot into the conversation so the assistant can analyze it, then dismiss it).

Before you start

  • The start-of-session check done. The comparison reads only. Taking a baseline adds a snapshot to the repository.
  • Know how your team holds the two states. There are three common ways, and each has its own method:
How the two states are held Method How exact it is
One package, changed in place. The as-is is a baseline taken before the to-be work started Compare the package with that baseline (compare_baseline) Exact, item by item and property by property
Two packages. The to-be is a copy of the as-is, for example made with Copy a package as new The AI matches the two packages' elements with direct queries A judgment: elements are matched by name and stereotype, unless the copy's identifier map was kept
One model, a lifecycle tag. Each element says whether it is current, planned or retiring Group the elements by the tag (aggregate_portfolio) As exact as the tags

If no baseline exists yet and you plan to model the to-be in place, take one now. That baseline becomes your as-is (Protect a change with a baseline).

Steps

  1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it. AI Power Tools ea-start-here runs the start-of-session check.
  2. You Say which of the three ways your team uses, and name the package or packages, the baseline, or the tag.
  3. AI Power Tools One package with a baseline: ea-change-management lists the package's baselines so you can confirm the one that holds the as-is (list_baselines), then compares the package with it (compare_baseline). Model-only items are added in the to-be, baseline-only items are removed, and changed items carry the properties that changed.
  4. (AI Power Tools, then AI) Two packages: the AI counts both package subtrees by stereotype with a read-only direct query, then matches their elements with read-only direct queries (execute_sql with writes refused). If the copy's old-to-new identifier map was kept, it matches by identifier. Otherwise it matches by name and stereotype, and lists separately every element it could not match one-to-one.
  5. You Two packages: decide the unmatched pairs. A renamed element looks like one removal and one addition until you say they are the same.
  6. AI Power Tools A lifecycle tag: ea-stakeholder-reporting checks how many elements carry the tag at all (summarize_tagged_value_usage), then groups them by its value (aggregate_portfolio).
  7. AI Power Tools For each removed or retiring element, ea-model-hygiene traces what depends on it (trace_connectors, upstream), and reads the guards on each trace.
  8. AI ea-stakeholder-reporting writes the gap list in display terms: added, removed, changed with the changed properties, and for each removal what depends on it. It states the method, the scope, the matching rule for two packages, and anything it could not resolve.

Prompts to use

Opening

Follow-ups

Model Fit Why
Claude Fable 5.1 Recommended Matching two packages and judging unmatched elements is reasoning-heavy
Claude Opus 5.5 Recommended The same
Claude Sonnet 5.5 Recommended The baseline and lifecycle-tag methods are mostly computed; capable on the two-package method with review
Claude Haiku 4.5 Capable Fine for reading a baseline comparison. Not for matching two packages

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks.

Checking the result

  • Accurate. For a baseline comparison, two items checked by hand: one added element exists in the package and not in the baseline, and one changed property reads as reported (get_element). For two packages, a sample of matched pairs really is the same element, and a sample of unmatched elements has no counterpart.
  • Complete. For two packages, matched plus unmatched equals each package's count from step 4. For a lifecycle tag, the elements with no tag are reported, because they are in neither state. Each dependency trace was not truncated, or the report says it was.
  • Nothing unintended changed. The comparison, the queries and the traces read only. A baseline taken in this session is the only addition.

Variations

  • One element's history. For "what happened to this system between the two states", read its changed properties from the baseline comparison, and its neighbors in each package (trace_connectors).
  • A transition plan. Feed each removal into Assess the impact of retiring a system for a full impact report.
  • Who made the to-be changes. Find out what changed, when and by whom lists the items modified in the window and their authors.

Limitations

  • A baseline comparison needs the baseline. The comparison is against a state saved as a baseline before the change. A baseline also covers one package subtree, and its connector counts include only connectors whose source element is inside the package.
  • Matching two packages is a judgment. Copies get fresh identifiers, so without the copy's identifier map elements are matched by name and stereotype. A rename, a split or a merge needs your decision.
  • A copy stays linked to the as-is. Connectors that crossed the copied package's boundary still end on the original elements outside it (Copy a package as new), so the to-be's dependencies can include as-is elements.
  • A lifecycle tag is only as good as its upkeep. Elements with a missing or stale tag are in neither state, or the wrong one.
  • Only connectors are traced. Dependencies recorded anywhere else are not found.