Sparx EA: 100 Questions Answered by Enterprise Architecture Practitioners

Sparx EA is a full-lifecycle modeling and enterprise architecture tool developed by Sparx Systems, an Australian software company. It supports UML, SysML, ArchiMate, BPMN, TOGAF ADM, DoDAF, NAFv4, and many other modeling languages and frameworks. It is widely used across enterprise IT, defense, government, systems engineering, and software development. It is available as a desktop tool (Windows) and as a web-accessible platform via Pro Cloud Server.

Visio is a diagramming tool; Sparx EA is a modeling tool. The distinction matters. In Visio, you draw shapes and connect them: the connections have no semantic meaning beyond what the shape label says. In Sparx EA, every element has a type (stereotype), properties (tagged values), relationships with governed semantics, and a single identity that can appear in multiple diagrams simultaneously. Changing an element’s property in one diagram updates it everywhere. Visio diagrams are documents; Sparx EA is a governed repository.

The most important first decision is your repository platform: file-based (.eapx or .qeax) for individual use or team development, or a database-backed repository (SQL Server, PostgreSQL, MySQL) via Pro Cloud Server for collaborative enterprise use. For any team with more than one architect, database-backed with Pro Cloud Server is the correct choice from day one. The second priority is activating the right MDG technology (ArchiMate, TOGAF, SysML) for your framework.

Sparx EA is available in Desktop and Enterprise editions. The Desktop edition covers modeling, diagramming, and most framework support. The Enterprise edition adds advanced code engineering, simulation, and additional framework profiles. For EA practice work: ArchiMate, TOGAF, capability modeling, requirements management: the standard Desktop edition is typically sufficient. Specific advanced framework features (UPDM/NAFv4 full MODEM compliance, advanced SysML parametrics) may require Enterprise edition or specific MDG add-ons.

Yes: but only with a database-backed repository via Sparx EA Pro Cloud Server. File-based repositories (.eapx) do not support multi-user concurrent editing. A properly configured Pro Cloud Server deployment with a SQL Server or PostgreSQL backend supports dozens of concurrent architects working in the same repository, with package-level locking and version control integration. For any team beyond a single architect, database-backed deployment is essential.

Sparx EA ships with MDG (Model Driven Generation) profiles for: ArchiMate 3.x, TOGAF ADM, UML 2.x, SysML 1.x, BPMN 2.0, DoDAF (via UPDM), MODAF (via UPDM), NAFv4, Zachman Framework, FEAF, BIAN, and several others. Additional framework profiles are available from Sparx Systems, Sparx Systems resellers, and the community. Custom MDG profiles can be created for organization-specific frameworks or to extend existing profiles.

Sparx EA has native requirements management built in. Requirements are first-class elements: they can have stereotypes (stakeholder requirement, system requirement, software requirement), relationships (derive, satisfy, verify, trace), and they appear in requirements diagrams and traceability matrices. The traceability matrix view shows requirement-to-element coverage across the full trace hierarchy. This is the foundation of certification evidence management for DO-178C, EN 50128, and similar safety-critical standards.

Yes. Sparx EA supports package-level version control via XMI export/import to Git, SVN, or other VCS. Individual packages can be controlled independently: the main repository holds the live working copy, while XMI checkouts enable parallel version control workflows. For enterprise deployments, Sparx EA Pro Cloud Server also provides built-in baseline functionality that snapshots the repository at a point in time, enabling before/after comparison and rollback. Baselines are the most commonly used version control mechanism for EA repositories.

The Model Wizard (new project wizard) provides pre-configured framework templates that create the recommended package structure and initial diagrams for common use cases: TOGAF ADM, SysML, ArchiMate, and others. For architects new to a framework, the wizard is a useful starting point. For organizations with existing governance standards and MDG profiles, the wizard should be bypassed in favor of the organization’s governed template: framework-specific guidance from the wizard may conflict with organization-specific MDG customizations.

The three most common early mistakes are: first, using diagrams as the primary organizing structure (elements should live in the package hierarchy, not be scattered across diagrams as diagram-only elements); second, using default UML types without stereotypes (everything looks the same, and MDG profiles cannot be applied retroactively without cleanup); third, not setting up a database-backed repository before starting collaborative work. All three mistakes create significant rework debt when the repository grows.

For most enterprise deployments, SQL Server or PostgreSQL are the recommended choices. SQL Server is preferred in Microsoft-stack environments (integrates naturally with existing DBA expertise, backup tooling, and Active Directory). PostgreSQL is preferred in cloud-native or mixed environments (open source, excellent performance, supported on Linux and all major cloud platforms). MySQL is supported but has known limitations at large scale. Oracle is supported for organizations with Oracle infrastructure standards. Avoid file-based repositories for any team use.

Pro Cloud Server is Sparx Systems’ server-side infrastructure for Sparx EA. It provides the database backend connection and management, web-based access to the repository (via WebEA: the browser client), HTTP API services, and integration server capabilities. PCS is the production deployment standard for enterprise EA repositories. It supports Windows Server and Linux. All serious enterprise Sparx EA deployments should be running PCS.

WebEA is the browser-based read/write client for Sparx EA, served by Pro Cloud Server. It allows stakeholders: business analysts, project managers, domain SMEs: to access the EA repository in a browser without installing the Sparx EA desktop application. WebEA supports browsing the model, viewing diagrams, reading element properties, and (with appropriate permissions) editing notes and tagged values. For broad stakeholder access to the EA repository, WebEA is the right mechanism: it requires only a browser and appropriate PCS credentials.

The recommended top-level structure separates: Framework/Views (ArchiMate diagrams, TOGAF views), Capability Library (the governed capability taxonomy), Application Portfolio (application components and their properties), Technology Components (infrastructure and platform components), Projects (change initiative architecture), and Reference (patterns, principles, standards, external definitions). Each top-level package is a separate controlled domain with its own access permissions. Avoid flat structures or diagram-centric organization: the repository hierarchy is what makes it navigable.

For database-backed repositories, the backup is a standard database backup of the underlying SQL Server, PostgreSQL, or other database: scheduled via the database platform’s standard tools. Sparx EA itself does not need to be backed up (it is software); the database is the artifact. In addition to database backups, Sparx EA’s baseline feature should be used before major changes: baselines create point-in-time snapshots of the entire repository stored within the repository itself. Export to XMI is also available as a secondary backup format.

Sparx EA repositories routinely hold hundreds of thousands of elements. Enterprise deployments at large organizations typically run 50,000-500,000 elements. There is no enforced element limit; practical upper limits are determined by database performance, server resources, and the complexity of the MDG profiles in use. Large repositories (>500K elements) benefit from partitioned package structures with appropriate indexing and regular database maintenance. Performance issues in large repositories are typically database configuration problems, not Sparx EA limitations.

Either is technically supported. On-premises deployment on Windows Server or Linux provides full infrastructure control and is appropriate for highly regulated environments (classified defense, NHS, financial services with strict data residency requirements). Cloud deployment on Azure, AWS, or GCP provides operational flexibility and is appropriate for organizations comfortable with cloud hosting. The most common cloud deployment pattern is Sparx EA PCS on an Azure VM with SQL Server or PostgreSQL. There is no Sparx-managed SaaS offering: the cloud VM is customer-managed.

Sparx EA supports integration through: the Automation Interface (COM API, scriptable in VBScript, C#, Java), the Integration Server (connects to Jira, Azure DevOps, Confluence, and other project tools), XMI import/export (the ISO standard for model exchange), direct database access (for reporting and external tooling), the read-only MCP server in Kernaro AI Hub, AI Power Tools for Sparx EA (a free local MCP server from NovoCircle), and community/third-party connectors. The Integration Server is particularly valuable for synchronizing EA requirements and elements with Jira or Azure DevOps work items.

Sparx EA PCS supports project-level security with user groups and permissions. The common access pattern is: Architects have full read/write access to their domains; Security reviewer roles have read-only access across the repository; Administrators have configuration access. Package-level locking prevents concurrent edits to the same package. For highly regulated repositories, Pro Cloud Server’s Active Directory integration enables SSO and centralized user management through existing enterprise identity infrastructure.

The most common causes of repository performance degradation are: missing or fragmented database indexes (run the database reindex/defragment procedure available in Sparx EA’s database management tools), oversized binary attachments in the repository (linked documents stored as blobs), excessively deep package hierarchies (degrade tree navigation), and large numbers of unmanaged diagram-only elements (elements that exist only on diagrams, not in the package hierarchy). Sparx Services provides performance assessment and remediation as part of ongoing platform support.

ArchiMate is the OMG and Open Group standardized modeling language for enterprise architecture. It provides a structured notation for describing business layer (motivation, strategy, business processes, roles, actors), application layer (applications, services, components), and technology layer (hardware, networks, platforms) architecture: with explicit relationship types connecting these layers. Use ArchiMate when you need a formal, interchangeable EA model: capability maps, application landscapes, integration architecture, and IT strategy artifacts. It is the default EA modeling language for most enterprise contexts.

BPMN (Business Process Model and Notation) is the OMG standard for detailed business process modeling. It supports pools, swimlanes, gateways (decision points), events (start, intermediate, end), and rich notation for parallel flows, exception handling, and process boundaries. ArchiMate’s business layer includes process elements, but at a coarser granularity than BPMN: suitable for process landscapes and high-level flow, not detailed process specification. Use BPMN for detailed operational process design; use ArchiMate for the process landscape. Sparx EA supports both in the same repository.

SysML (Systems Modeling Language) is a UML profile adapted for systems engineering work. It replaces some UML diagram types with systems engineering-specific types (Block Definition Diagrams, Internal Block Diagrams, Requirement Diagrams, Parametric Diagrams) and reuses others (Activity, Sequence, State Machine). Use SysML for systems engineering programs: aircraft systems, rail signaling, industrial automation: where you need to model physical system blocks, interfaces between subsystems, requirements traceability to design, and parametric constraints. Use UML for software engineering work where the subject is software rather than physical systems.

Yes. Sparx EA supports DMN 1.x through an MDG profile. DMN is the OMG standard for modeling business decisions using decision tables and decision logic. It is commonly used alongside BPMN to separate process flow (BPMN) from decision logic (DMN). In Sparx EA, DMN decision tables can be linked to BPMN business rule tasks, creating traceable connections between where a decision is invoked in a process and the decision logic that determines its outcome.

Yes: this is a common configuration for complex programs that have both enterprise architecture (ArchiMate) and systems engineering (SysML) dimensions. The typical division is: ArchiMate for the enterprise layer (capability maps, application architecture, IT strategy); SysML for the system engineering layer (system decomposition, interface specifications, requirements traceability). Sparx EA supports both MDG profiles simultaneously. Traceability links can connect ArchiMate capability elements to SysML block definitions that implement them.

UML Class diagrams provide formal data modeling capability: classes, attributes, operations, associations with cardinality, inheritance, and composition. ArchiMate’s data layer (Data Object, Representation) is less granular: suitable for identifying what data entities exist and their high-level relationships, but not for detailed schema design. Use UML Class diagrams for formal data architecture, logical data models, and physical schema design. Use ArchiMate Data Objects for enterprise-level data architecture: identifying key data entities and their relationship to applications and business processes.

Sparx EA provides a full UML State Machine diagram type with: states (simple, composite, submachine), transitions with guard conditions and triggers, entry/exit/do behaviors, pseudostates (initial, final, choice, fork, join, history), and orthogonal regions. State machines in Sparx EA can be attached to a class or component, making the state machine the behavioral specification of that element. For safety-critical systems (rail interlocking logic, avionics mode management), state machines are first-class architecture artifacts used for certification evidence.

An ArchiMate viewpoint is a predefined selection of element types and relationship types appropriate for a specific stakeholder concern. The ArchiMate specification defines viewpoints including: Capability viewpoint, Stakeholder viewpoint, Application Cooperation viewpoint, Technology viewpoint, Implementation and Migration viewpoint, and others. In Sparx EA, ArchiMate viewpoints are implemented as diagram frame templates that constrain the available element types via the MDG toolbox. Using governed viewpoint templates ensures that diagrams contain the elements appropriate for their purpose.

Yes. Sparx EA supports XMI (XML Metadata Interchange: the ISO/OMG standard for model exchange), which enables import/export of UML, SysML, and ArchiMate models to and from other compliant tools. Sparx EA also supports direct import from Visio (.vsdx), Rose (.mdl), and other formats. For reporting and documentation, EA can generate Word documents, PDF reports, HTML sites, and CSV exports. For AI and BI tools, see Section 6: Kernaro AI Hub includes a read-only MCP server, and AI Power Tools for Sparx EA can generate a Power BI model from your EA data, backed by a reporting database that refreshes on the schedule you set.

ArchiMate, without question, for enterprise architecture work. ArchiMate is the industry standard EA modeling language, it is framework-neutral (works with TOGAF, FEAF, or independent EA practice), and it is directly supported in Sparx EA with a mature MDG profile. An architect who can model confidently in ArchiMate: business layer processes and actors, application layer components and services, technology layer nodes and infrastructure: covers the vast majority of enterprise architecture use cases. UML fluency (specifically Class, Sequence, and State Machine) adds significant value for data architecture and system design work.

TOGAF (The Open Group Architecture Framework) is the most widely adopted EA methodology globally. It defines the Architecture Development Method (ADM): a phased approach to producing architecture (Preliminary, Architecture Vision, Business Architecture, Information Systems Architecture, Technology Architecture, Opportunities and Solutions, Migration Planning, Implementation Governance, Architecture Change Management). Sparx EA includes a TOGAF ADM MDG profile that provides TOGAF-specific diagram types, element stereotypes, and the ADM phase framework. Sparx Services uses TOGAF as the default EA methodology.

No: TOGAF certification is not required to use Sparx EA’s TOGAF profile. The certification shows understanding of the TOGAF specification; it does not grant access to the tooling. However, architects implementing TOGAF-governed architecture programs benefit significantly from understanding the ADM framework, content metamodel, and governance mechanisms. Sparx Services recommends TOGAF Foundation (Level 1) as a baseline for EA architects working in TOGAF environments, and TOGAF Architect (Level 2) for lead architects.

BIAN (Banking Industry Architecture Network) is a non-profit standards body that publishes a service landscape for banking: a canonical taxonomy of banking business capabilities and services. BIAN is used in banking enterprise architecture as a reference model for capability mapping, application landscape analysis, and banking platform design. Sparx EA supports BIAN through an MDG profile that implements BIAN’s service domain taxonomy as stereotype elements. Sparx Services has a dedicated BIAN insight article at /insights/insight-38-banking-bian/ for architects working in financial services EA.

TM Forum is a global industry association for communications service providers (telcos) that publishes architecture standards including the Business Process Framework (eTOM), Information Framework (SID), Application Framework (TAM), and the Open API Framework. TM Forum standards are the reference architecture for telecommunications companies and increasingly for utilities and other infrastructure sectors. Sparx EA can model TM Forum framework components through custom MDG profiles. Sparx Services has experience implementing TM Forum-aligned EA in telecommunications and utility contexts.

FEAF (Federal Enterprise Architecture Framework) is the US federal government’s EA framework, managed by the US Office of Management and Budget. It organizes architecture around six sub-architectures (Performance, Business, Data, Applications, Infrastructure, Security) and is aligned to the federal budget and performance management process. TOGAF is a commercial EA methodology for any organization; FEAF is specifically structured for US federal agency governance requirements. Sparx EA can implement FEAF through its MDG framework: in practice, US federal EA practices often combine FEAF structure with ArchiMate notation.

TOGAF provides the methodology (ADM phases, deliverables, governance); ArchiMate provides the modeling language (notation, element types, relationship semantics). They are designed to complement each other: TOGAF ADM outputs are most naturally expressed in ArchiMate notation. The Open Group publishes guidance on using ArchiMate with TOGAF. In Sparx EA, both the TOGAF MDG profile and the ArchiMate MDG profile are typically active simultaneously: TOGAF for the ADM framework structure and ArchiMate for the modeling language.

Sparx EA does not certify compliance with DO-178C or EN 50128: those standards certify products and processes, not tools. However, Sparx EA provides the requirements management, traceability, and modeling capabilities needed to support DO-178C and EN 50128 development processes: requirements hierarchy with stereotyped levels (stakeholder/system/software), traceability matrices, SysML design modeling, and evidence linking. Sparx Services has implemented certification-evidence repositories in Sparx EA for aerospace and rail programs.

UPDM (Unified Profile for DoDAF and MODAF) is the OMG standard that harmonizes the US DoDAF framework and the UK MODAF framework into a single UML/SysML profile. It is the foundation for NAFv4 support in Sparx EA. For defense architecture architects working on UK MoD programs, NATO programs, or joint US-UK programs, UPDM/NAFv4 is the required framework profile. Sparx EA’s UPDM implementation supports both DoDAF and NAFv4 viewpoint structures.

Yes. Data mesh and data fabric architectures involve components: domains, data products, data contracts, governance planes, infrastructure platforms: that can be modeled in Sparx EA using custom MDG stereotypes. ArchiMate provides a useful starting point (data objects, application services, technology components), extended with data mesh-specific stereotypes (DataDomain, DataProduct, DataContract) added through a custom MDG profile. Requirements elements can model data mesh governance principles. Sparx Services can develop data architecture MDG profiles for organizations implementing data mesh.

Yes: Sparx EA’s architecture description concepts align with ISO/IEC/IEEE 42010:2011, the international standard for architecture description. ISO 42010 defines architecture viewpoints, views, model kinds, stakeholder concerns, and correspondence rules. NAFv4, in particular, is formally aligned to ISO 42010. Sparx EA supports the ISO 42010 concepts of viewpoints (MDG diagram types), views (diagrams), and stakeholder concerns (requirements and motivation elements) throughout its modeling framework.

MDG (Model Driven Generation) Technology is Sparx EA’s metamodel governance mechanism. It is the system by which custom stereotypes, tagged value schemas, relationship constraints, diagram templates, and toolboxes are defined and enforced. An MDG profile extends the base UML or ArchiMate metamodel with organization- or framework-specific element types. When you activate the ArchiMate MDG profile in Sparx EA, you are loading a set of stereotype definitions that allow Sparx EA to recognize and enforce ArchiMate element types.

In Sparx EA terminology, an MDG Technology is the container: the deployable package that an architect activates in Sparx EA. An MDG Profile is the UML profile (the stereotype definitions and tagged value schemas) contained within an MDG Technology. A single MDG Technology may contain one or more profiles, plus toolboxes, diagram types, and code templates. When architects say “the ArchiMate MDG” they typically mean the MDG Technology that contains the ArchiMate profile and its associated toolboxes.

Custom MDG profiles are created within Sparx EA itself using the Profile Helper (built into the MDG Technology editor) or by directly editing the profile’s XML. The process is: create a UML profile package, define stereotypes as UML Class elements with the «stereotype» stereotype, add tagged value definitions as attributes on the stereotype class, define relationship constraints as connector tags, then use the MDG Technology wizard to package the profile into a deployable .xml technology file. Sparx Systems provides MDG Technology creation documentation and the built-in Profile Helper tool to guide this process.

MDG governance is the primary determinant of AI query quality. Kernaro AI Hub’s read-only MCP server exposes the repository to AI tools through an MDG Technology that translates the physical Sparx schema into a GraphQL layer, so it works from elements, their stereotypes, their tagged values, and their relationships. AI Power Tools for Sparx EA works on the live model directly, and the same rule applies. If elements lack stereotypes, tagged values are sparsely or inconsistently populated, or relationships are unconstrained, the AI has ambiguous, incomplete data to reason over. A query like “which applications support capability X?” requires applications to have the ApplicationComponent stereotype, capabilities to have the BusinessCapability stereotype, and a realization relationship between them: all of which MDG governance defines and enforces.

The minimum governed tagged value set for enterprise elements is: Owner (person or team responsible), Status (Active/Retiring/Proposed/Archived), and Description (plain-language explanation of what the element is). For applications, add: Lifecycle (Strategic/Tolerate/Eliminate/Migrate), Vendor, and Version. For capabilities, add: Maturity (Initial/Developing/Defined/Managed/Optimizing) and Investment Direction (Invest/Maintain/Harvest/Divest). These tagged values are the foundation for meaningful Power BI dashboards, Copilot queries, and governance reporting.

Yes. MDG Technology files are XML documents (.xml) and can be stored in Git, SVN, or any version control system. The deployment mechanism: delivering an updated MDG profile to team members: can be handled through Sparx EA’s MDG Technology Manager, which supports loading profiles from a shared network path or URL. When the profile at the shared URL is updated, team members loading Sparx EA pick up the updated profile automatically. This enables centralized MDG governance with controlled version releases.

A tagged value enumeration is a tagged value defined in an MDG profile with a restricted set of allowed values: a dropdown list. For example, a Lifecycle tagged value with enumerated values Strategic, Tolerate, Eliminate, Migrate prevents architects from entering free text (“strategic app”, “going to be retired”, “keep this one”) and enforces a governed vocabulary. Enumerations are essential for any tagged value that will be used for filtering, reporting, or AI queries: they guarantee consistency that free-text fields cannot provide.

Relationship constraints in MDG profiles define which relationship types are valid between which element stereotypes. For example, constraining that a Serving relationship from ApplicationService to BusinessProcess is valid, but a Serving relationship from BusinessActor to TechnologyComponent is not. Without these constraints, architects create technically legal but semantically meaningless connections that produce incorrect results in impact analysis, traceability matrices, and AI queries. Relationship constraint enforcement is the highest-maturity MDG governance mechanism.

The MDG toolbox is the panel of draggable element types available in a Sparx EA diagram. Each MDG Technology can define toolbox pages that appear when the corresponding diagram type is active: showing only the element types appropriate for that viewpoint. A well-configured toolbox reduces modeling errors (architects cannot accidentally drop a business-layer element into a technology-layer diagram if the toolbox doesn’t include it) and speeds up modeling (architects find the right element type immediately rather than hunting through menus).

The Sparx EA automation interface (the COM API exposed to VBScript, C#, Java scripts and add-ins) can programmatically create, read, update, and delete elements: including reading and writing MDG-governed stereotypes and tagged values. This enables automated MDG quality checks (scripts that scan the repository for elements missing required tagged values), batch metadata updates (applying a new tagged value to all elements of a given stereotype), and integration workflows (synchronizing tagged values between Sparx EA and external systems). MDG governance and the automation interface together enable repository quality at scale.

Sparx EA core has no native MCP server. Kernaro AI Hub, a Sparx Systems product, includes one: a read-only MCP (Model Context Protocol) server, deployed on a server for enterprise-wide access. It needs an MDG Technology defined for the repository, which translates the physical Sparx schema into the GraphQL layer the server exposes. Because it is read-only, connected assistants can query the repository but not change it. A second MCP server exists alongside it: AI Power Tools for Sparx EA, a free local server with full read/write (see Q56). AI tools for Sparx EA compares every option.

MCP (Model Context Protocol) is an open standard: developed by Anthropic in 2024 and rapidly adopted as an industry standard: that provides a uniform way for AI language models to connect to external data sources and tools. Sparx EA core has no native MCP server. Two exist alongside it: the read-only server included in Kernaro AI Hub, and AI Power Tools for Sparx EA, a free local MCP server from NovoCircle with full read/write, for Claude and GitHub Copilot. Any MCP-compatible client can connect to a server, within that server’s scope.

Kernaro Assist (Sparx Systems, May 2026) is an add-in inside Enterprise Architect. Kernaro AI Hub (Sparx Systems, January 2026) is a web layer over the repository with a read-only MCP server for MCP-compatible assistants. Both Kernaro products are bring-your-own LLM: your organization supplies the keys and pays the provider for usage. Claude (Claude Desktop chat and Claude Code in the Claude desktop app) works with the repository through AI Power Tools for Sparx EA, using its Claude Desktop extension and plugin, and GitHub Copilot works through its VS Code extension with the same skills. Microsoft 365 Copilot can answer questions from EA data read-only (see Q54). Sparx Systems has also added AI to Prolaborate; check Sparx’s product pages for what it includes. The AI tools for Sparx EA page sets the options side by side.

Read-only. Microsoft 365 Copilot answers from a published Power BI semantic model built from your EA data, as of the model’s last refresh, and each person sees only what their own Power BI access allows. We can build that model on a reporting database for you. If your organization has Kernaro AI Hub, the Kernaro Connector for Power BI is the preferred route to Power BI, and Copilot can also reach the read-only API of Kernaro AI Hub through Copilot Studio or a Microsoft 365 connector. AI Power Tools has no live connection to Microsoft 365 Copilot, and users need Microsoft 365 Copilot licenses.

The questions that work best are those with clear answers in a well-governed repository: “Which applications support the customer onboarding capability?”; “What is the lifecycle status of all applications in the retail banking domain?”; “Which technology components are approaching end of life?”; “What applications would be affected if we decommissioned the legacy CRM?”; “Which capabilities have no applications supporting them?”. Questions requiring judgment: “Should we replace Application X?”: are outside the AI’s scope, but it can surface the factual context that informs the judgment.

Kernaro AI Hub’s MCP server is read-only and deployed on a server for enterprise-wide access; it needs an MDG Technology for its GraphQL translation layer, and it is suited to cross-tool questions with central control. AI Power Tools for Sparx EA is a free local MCP server from NovoCircle on the architect’s Windows machine with EA open, with full read/write. It runs under the architect’s EA login, with no central audit layer of its own. For Claude, a plugin adds a skills library; GitHub Copilot gets the MCP server through a VS Code extension, and VS Code loads the same skills.

It depends on the route. Kernaro AI Hub’s MCP server is read-only, and Microsoft 365 Copilot reaches EA data read-only. AI Power Tools for Sparx EA has full read/write, so an assistant connected to it can make the changes the architect’s own EA login could make. That is the point of the tool and also a governance decision: automation checks completeness, people own correctness, so review what an AI changes before it becomes part of the architecture. Decide per route who may connect, and which models and teams get write access.

Yes. Claude and GitHub Copilot connect through AI Power Tools for Sparx EA, and Kernaro is bring-your-own LLM: the customer supplies keys for Azure OpenAI, OpenAI, Anthropic Claude or an enterprise endpoint. Kernaro AI Hub’s MCP server is an open standard, so MCP-compatible assistants can connect to it for read-only queries. Power BI is one reporting route, not a requirement; see AI tools for Sparx EA for the options.

The AI returns incomplete, unreliable, or misleading responses. If an architect asks Copilot “which applications support customer onboarding?” and the repository has no governed application-to-capability relationships: because the MDG profile was never enforced: the AI either returns nothing (no relevant relationships found) or returns a guess based on element names alone. This is not a Copilot limitation; it is a repository quality limitation. The AI cannot invent relationships that are not in the data. Governance remediation is the only fix.

Yes: and this is a governance consideration for any AI deployment against the repository, not an inherent flaw in the technology. Access should be restricted to users with appropriate permissions, using the same access controls applied to the Sparx EA repository itself. Kernaro AI Hub is deployed on a server with SSO and centralized permissions; AI Power Tools for Sparx EA runs on the architect’s machine under that architect’s own EA login, with no central audit layer of its own; Microsoft 365 Copilot should only reach EA data for users authorized to see it. Access governance is part of choosing the route in Configure the Solution.

Kernaro is the name Sparx Systems uses for its AI products for Sparx EA: Kernaro AI Hub (January 2026), a web layer over the repository with Model Chat, impact analysis, integrations, a report builder and a read-only MCP server, and Kernaro Assist (May 2026), an add-in inside Enterprise Architect. Both are bring-your-own LLM. Because both launched in 2026, any track record is measured in months, not years.

Kernaro AI Hub is a web layer over the Sparx EA repository, running on your infrastructure or on Sparx’s managed cloud platform. It provides Model Chat (natural language queries against the repository), impact analysis, integrations with Jira, Confluence, Azure DevOps and SharePoint, a Word and Excel report builder, a diagram builder, Intelligent Flow automation, and a read-only MCP server for enterprise-wide access. Its answers are bounded by the quality of the repository’s MDG governance.

Kernaro Assist is an add-in inside Enterprise Architect. Architects can ask questions in natural language: “what does this application connect to?”, “which requirements does this component satisfy?”, “suggest a name for this element based on surrounding context”: and work with model content where they already model. It covers Model Chat, natural language modeling, model analysis, validation and event-driven agents. The Basic license is read-only, with no agents and no central audit trail. Read and write access and agents come with the Advanced license, and SSO, shared agents and the audit trail need Kernaro AI Hub.

Kernaro AI Hub is a web application: a server deployment on your infrastructure (or Sparx’s managed cloud platform) with SSO, and LLM keys, because Kernaro is bring-your-own LLM and you pay the provider for usage. Its MCP server needs an MDG Technology defined for the repository, and the answers are only as good as the governance behind it: governed stereotypes and tagged values on key element types. Hub is licensed from Sparx Systems. Check Sparx’s current documentation for exact infrastructure requirements; Configure the Solution is where Sparx Services helps get the repository and its MDG ready.

Kernaro AI Hub is a purpose-built layer over the repository: Model Chat, impact analysis, cross-tool integrations, report building, and central control with governed, audited access. Microsoft 365 Copilot is a general-purpose assistant that answers questions from EA data read-only, from a published Power BI semantic model built from your EA data or, with Hub, through the read-only API of Kernaro AI Hub via Copilot Studio or a Microsoft 365 connector. There is no live AI Power Tools connection. They serve different audiences: Hub for analysts and architects answering cross-tool questions, Microsoft 365 Copilot for people whose everyday AI is already Teams, Word and Outlook.

Yes, as a completeness check. AI Power Tools for Sparx EA includes skills for model hygiene and validation that look for patterns of existing relationships and flag elements that appear to be missing expected ones. For example, if every BusinessCapability element has at least one ApplicationComponent realizing it except for five, those five are flagged as probable gaps. Automation checks completeness; people own correctness, so validating each suggestion still requires architect review. See AI Power Tools for Sparx EA for the skills library.

No. AI tools, Kernaro included, take on the routine, time-consuming aspects of architecture work: drafting, completeness checking, report generation, repository quality checking. They do not make architecture decisions, evaluate strategic trade-offs, engage stakeholders, or exercise the judgment that makes architecture valuable to an organization. They are productivity tooling for architects, not a replacement for architectural expertise. The organizations that get the most from them are those with strong EA practices that want to scale their output.

Each tool publishes its own requirements, and they change quickly because all of them launched in 2026, so check the current documentation before you plan. Kernaro Assist is an add-in inside Enterprise Architect on the architect’s desktop; Kernaro AI Hub is a web application you deploy. AI Power Tools for Sparx EA is Windows only and needs EA open on the same machine, and the GitHub Copilot route uses VS Code 1.99 or newer in Agent mode. Sparx Services checks compatibility as part of Configure the Solution.

Kernaro AI Hub and Kernaro Assist are Sparx Systems products, licensed through Sparx Systems. Kernaro Assist has Basic and Advanced licenses. Advanced adds agents, MCP servers, Python and document tools, and Advanced connected to Kernaro AI Hub adds SSO, roles, named seats, shared agents and an audit trail. Kernaro is bring-your-own LLM, so you also pay your chosen provider for usage. AI Power Tools for Sparx EA is free, with nothing to buy or activate; it is published by NovoCircle, and the Claude or GitHub Copilot plan you use with it is separate. Commercial terms are a conversation with Sparx Systems.

It depends on the tool. Kernaro Assist creates, modifies and validates model content in natural language inside EA on the Advanced license. The Basic license is read-only. In Kernaro AI Hub, Model Chat and reports read the repository, and Intelligent Flow automations can write to it where configured. AI Power Tools for Sparx EA has full read/write. In every case, people own correctness: review what an AI changes.

An Architecture Review Board (ARB) is the governance forum that evaluates proposed technology or architecture changes against architecture principles, standards, and roadmaps. It provides a structured mechanism for maintaining architecture coherence across projects. Sparx EA supports ARB processes through requirements modeling (principles as requirement elements), review artifacts (standard review package templates), and the project-to-architecture alignment view in Power BI (showing which projects are touching which architecture components). ARB processes are described in Sparx Services’ dedicated ARB insight article at /insights/insight-44-architecture-review-board/.

An EA Center of Excellence is the organizational unit responsible for the EA practice: maintaining the EA repository, governing MDG profiles, helping ARBs, developing architecture capabilities, and producing EA deliverables for strategic programs. The CoE provides the consistency, expertise, and governance mechanisms that prevent individual project decisions from fragmenting the overall architecture. In large organizations, the EA CoE typically has 5-15 architects supported by Sparx Services for specialist engagements.

EA value measurement is notoriously difficult because EA’s primary value is what it prevents (bad decisions, unplanned rework, duplicate capability investment) rather than what it produces. Practical metrics include: architecture debt reduction (tracked through application lifecycle profiles), project architecture compliance rates (proportion of projects reviewed by ARB that met principles), decision speed improvement (time to answer standard architecture questions before vs. after AI-assisted querying), and cost avoidance estimates (projects where architecture review prevented a planned duplicate investment).

The most effective approach is making the repository answer the questions stakeholders are already asking: and doing so faster and more accurately than the alternative. A CIO who sees a Power BI dashboard answering “what is our application lifecycle profile?” stops asking architects for quarterly reports. A program manager who gets accurate impact analysis from an AI assistant they already use stops emailing the EA team for dependency lists. Getting there asks the architect to decide which questions stakeholders really ask and what the answers must hold up to, while AI builds the dashboards and keeps them current. Stakeholder engagement is primarily a product design problem: make the repository outputs valuable to the people who need them, in the formats they already use.

Architecture debt is the accumulation of technically suboptimal decisions made for tactical reasons: legacy systems retained beyond their useful life, point-to-point integrations instead of an integration platform, duplicate capabilities supporting the same business function. Sparx EA supports architecture debt management through lifecycle status tagging on applications (Strategic/Tolerate/Eliminate/Migrate), capability-to-application coverage analysis, and the visualization of end-of-life applications in Power BI. The ARB process is the governance mechanism that prevents new debt accumulation.

In project-based organizations (capital programs, defense acquisition, infrastructure development), EA primarily serves the program: architecture is produced for program decision gates and certification milestones, with a repository that tracks the program’s evolving design. In steady-state operations (banking, telco, utilities), EA primarily serves continuous portfolio governance: the repository reflects the current-state operating environment and evolves as the organization changes. Sparx EA supports both modes; the repository structure and governance cadence differ significantly between them.

Architecture principles are most effectively modeled as Requirement elements (using the Principle stereotype) in a governed principles package. Each principle has: a Name, a Statement (the principle itself), a Rationale (why this principle), and Implications (what it means for architecture decisions). Principles link to the architecture elements they govern (via ArchiMate Association or a custom Governed-By relationship). In Power BI, principle compliance can be tracked by linking projects to the principles they affect and recording compliance status. This makes principles visible and actionable rather than documentary.

The EA operating model defines how the EA function operates: how architects engage with projects, how the ARB works, what deliverables the EA practice produces, how the repository is maintained, and how EA value is communicated to executive stakeholders. Sparx EA is the tool that implements the operating model: but the operating model must be designed before the tool is configured. A common mistake is configuring Sparx EA before deciding how EA will operate, resulting in a repository structure that does not match the EA team’s actual working patterns.

Repository staleness from non-updating architects is a governance and incentive problem, not a tool problem. The most effective approaches are: making it easy to update (governed MDG profiles with structured forms are faster to fill in than free-text documents); making the value of updates visible (Power BI dashboards that architects see are more compelling than reports nobody reads); and integrating updates into existing workflows (EA updates as a project gate rather than a separate task). Architecture data quality metrics (percentage of elements with required tagged values populated) can be made visible to team leads as a performance indicator.

A mature EA practice in 2026 maintains a governed Sparx EA repository with consistent MDG profiles, an active ARB that reviews all significant technology decisions, a reporting layer in Power BI that executives and program managers read without asking an architect, AI tooling that does modeling work and answers natural language questions from the model (Kernaro AI Hub’s read-only MCP server, or AI Power Tools for Sparx EA), and an ongoing program continually improving repository coverage and quality. The EA team spends the majority of its time on strategic analysis and stakeholder engagement: not report production: because the AI and BI tooling handles the routine information distribution.

Paralysis to a Plan is Sparx Services’ starting engagement for organizations that need to understand where they are before deciding where to go. It produces: a capability map (what the organization needs to do), an application landscape (what it currently has), a technology risk assessment, and a gap analysis with prioritized recommendations. It also assesses Sparx EA repository maturity if an existing repository is in place. It is the right starting point for organizations new to formal EA, or for those resetting an existing EA practice.

Sparx Services does not sell the tools; it helps architects and architecture teams get the job done and make the move from manual work to AI-Augmented Architecture. For reporting, we can help you build a reporting database on your repository and get the result into Power BI, Microsoft 365 Copilot, Microsoft Fabric or your data warehouse. If you have Kernaro AI Hub, we can help you use its Power BI connector instead. We can teach your architects to do the work on your own repository, or build and update the model for you. The work covers repository and MDG readiness, route selection and training the team to direct the tools. It requires a reasonably well-governed repository; poor MDG governance requires building the practice foundation first. See Reporting and Power BI, We build and update your architecture model for you, and AI tools for Sparx EA.

Configure the Solution maximizes the value of an existing EA repository and integration deployment. Workstreams include: expanding MDG profile coverage to additional domains, adding new Power BI dashboards for emerging governance needs, deepening Copilot or AI integration for specific stakeholder workflows, applying Zachman or other classification overlays, and training and capability development for the EA team. It is the right approach for organizations that have a working EA practice and integration layer but want to extend and deepen their investment.

Configure the Solution establishes or reconfigures the Sparx EA repository and MDG governance foundation. It is the right approach when an organization needs a new, governed repository (new EA program), a specific framework configuration (NAFv4 for a defense program, BIAN for a banking program), or MDG remediation before AI integration. It includes package structure design, MDG profile configuration, diagram templates, toolbox configuration, and architect training. It is the governance foundation that the AI and BI tooling builds on.

Enable the Team builds the capability of the client’s internal architecture team: structured training in ArchiMate, TOGAF, MDG governance, and Sparx EA tooling, combined with hands-on coaching on the organization’s specific repository and use cases. It is designed for organizations that have the tooling in place but want to accelerate their team’s ability to use it well. Enable the Team can run as a standalone engagement or as a component within Configure the Solution.

Sparx Services offers ongoing advisory and platform support for organizations running production Sparx EA deployments. It provides expert advisory access for complex technical questions, MDG profile development and review, performance monitoring and optimization, Pro Cloud Server administration support, and regular repository health reviews. It is the right fit for organizations with mission-critical EA deployments that need expert backup for their internal team.

Start with Paralysis to a Plan when the organization does not have a clear picture of its current architecture state, does not have a governed EA repository, or is resetting an EA practice that has lost direction. Go straight to Configure the Solution when the organization already has a clear scope for the EA program (a specific framework to implement, a defined domain to model), has existing architecture knowledge, and needs the governed Sparx EA foundation established quickly. Sparx Services will recommend the right starting point after an initial scoping conversation.

Yes: this is the standard engagement model. Sparx Services engagements are designed to augment and upskill an existing EA team, not to replace it. The internal EA team provides domain knowledge, stakeholder relationships, and ongoing ownership; Sparx Services provides Sparx EA expertise, MDG governance experience, and AI integration capability. After a Sparx Services engagement, the internal team should be more capable of maintaining and extending the work than before the engagement started.

No. Sparx Services is a Sparx EA specialist. All engagements are centered on Sparx Enterprise Architect: its modeling, repository governance, framework configuration, and AI/BI integration. Sparx Services does not implement MEGA, Ardoq, Bizzdesign, LeanIX, or other EA tools. This specialist focus is a deliberate positioning: Sparx Services advocates Sparx EA because it is, in our assessment, the most capable and cost-effective EA platform for the use cases we address.

Sparx Services engagement pricing is based on scope and complexity, not time-and-materials. Each engagement is scoped to produce a fixed-price proposal. The initial scoping conversation is complimentary. Contact Sparx Services via the contact form at /contact/ to begin a scoping discussion.

Start with an honest assessment rather than an immediate cleanup attempt. Common symptoms of a repository in poor condition: duplicate elements across packages, inconsistent stereotypes or no stereotypes, elements that exist only on diagrams (not in the package hierarchy), free-text tagged values where enumerations should be, and no clear package structure. The assessment determines whether incremental remediation is feasible or whether a governed rebuild of key domains is more cost-effective. Sparx Services offers a repository assessment as part of Paralysis to a Plan: do not attempt large-scale cleanup without a clear plan.

The fix is MDG governance, applied consistently going forward and remediated retroactively for strategic content. The practical approach: first, establish the MDG profile you want (stereotypes, tagged values, relationship constraints) for the key element types; second, identify which packages and elements are strategically important enough to remediate; third, run a remediation sprint to apply the governed stereotypes and tagged values to the priority content; fourth, train all architects on the new standard and enforce it through peer review. Do not attempt to fix the whole repository at once: prioritize the content that AI and reporting tools will query.

This is almost always a maintenance cadence problem. The repository was accurate when it was built, but has not been updated as the organization changed. Common causes: architects update during project phases but not after go-live; the repository reflects the target state of a completed project, not the as-built state; applications have been decommissioned or changed without EA notification. The fix involves both a maintenance process (EA updates as part of project closeout; regular portfolio reviews) and tooling (Power BI dashboards that surface data currency, making staleness visible to stakeholders).

MDG profile inconsistency across domains is a governance design problem. Each domain team has created its own stereotypes, leading to four versions of “ApplicationComponent” with different tagged value schemas. Standardization requires: first, an inventory of all current stereotypes and tagged value schemas by domain; second, a governance decision on the canonical set (which one becomes the standard, or what new standard is designed from scratch); third, a migration plan for converting non-standard elements to the canonical stereotype; fourth, a deployment mechanism that ensures all architects are loading the same MDG Technology file. This is Configure the Solution scope.

Almost certainly an MDG governance problem. Checklist: are strategic elements (applications, capabilities, technology components) typed with consistent stereotypes? Are the cross-layer relationships (capability→application, application→technology) explicitly modeled using the correct relationship types? Are key tagged values (lifecycle, maturity, owner) populated on the elements the queries are about? If any of these are missing, the AI has nothing useful to surface. Run a small test: model one fully governed capability with five governed applications and test the AI query on that subset. If it works for the governed subset, the problem is breadth of governance, not tool configuration.

Common PCS performance issues and their causes: slow diagram loading (excessive binary attachments, unindexed linked documents), slow model tree navigation (deep package hierarchies, large element counts without server-side filtering), slow search results (missing full-text indexes, large number of unmanaged notes), and slow API responses (server resource constraints, unoptimized queries). Start with Sparx Systems’ published PCS performance tuning guide. Sparx Services provides PCS performance assessment through ongoing platform support.

This is a training and culture problem as much as a tooling problem. The behavior happens because diagram-first creation is faster and more intuitive for architects new to Sparx EA. Solutions: configure MDG toolboxes so they encourage package creation before diagram creation; create diagram templates that open against a pre-existing package (not an empty space); train architects explicitly on the single-element-multiple-diagrams pattern; run periodic repository health checks using the orphaned elements report. Diagram-only elements that appear in no package are identifiable and can be moved by a repository administrator.

Unifying fragmented EA practices requires agreement on the target operating model before any tooling changes. The tooling follows the governance, not the other way. Necessary decisions: one EA methodology (typically TOGAF as the default unless there is a specific reason otherwise), one modeling language (ArchiMate for enterprise layer, SysML for systems engineering where applicable), one MDG profile standard, and one repository (or a clearly governed multi-repository architecture with defined exchange standards). A Paralysis to a Plan engagement that spans all three teams and produces a unified target operating model is the right starting point.

The most common causes of an underused EA repository are: lack of stakeholder-facing outputs (the repository produces internal artifacts but not the dashboards and reports that make it valuable to non-architects); missing governance process (no ARB, no project engagement model, no reason for project teams to interact with the EA practice); MDG governance that was set up but not maintained (the repository became inconsistent and unreliable); and leadership sponsorship that peaked at launch and was not sustained. The right intervention depends on which of these is the primary cause: a Paralysis to a Plan engagement can diagnose it.

Pick one of these three, depending on where you are: If you have no EA repository, start a Sparx EA trial and model your top 20 applications and 10 capabilities with ArchiMate: even a small, governed starting set is better than nothing. If you have a repository but it is not governing MDG consistently, audit the five most-queried element types (typically applications and capabilities), define the tagged value schema for each, and apply it to 50 priority elements. If you have a governed repository but no external visibility, pick a route for stakeholders from AI tools for Sparx EA, for example Kernaro AI Hub with the Kernaro Connector for Power BI, or the reporting database from AI Power Tools for Sparx EA, and put your application lifecycle view and capability map in front of them.