Direct Answer
Sparx Enterprise Architect (Sparx EA) is the world’s most widely deployed enterprise architecture and modeling tool. It supports ArchiMate, SysML, UML, BPMN, TOGAF, DoDAF, NAFv4, and dozens of other frameworks in a single governed repository. This article answers 100 common questions asked by architects: from complete beginners to experienced architects dealing with AI integration, MDG governance, and large-scale repository challenges.
Questions are organized into 10 sections. Every answer is written from architect experience. Use the section headings to navigate to the questions most relevant to where you are.
Section 1: Getting Started
Q1. What is Sparx Enterprise Architect?
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.
Q2. How does Sparx EA compare to Microsoft Visio?
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.
Q3. What is the first thing to set up when starting with Sparx EA?
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.
Q4. What editions of Sparx EA are available?
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.
Q5. Can multiple architects work in the same Sparx EA repository simultaneously?
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.
Q6. What frameworks does Sparx EA support out of the box?
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.
Q7. How does Sparx EA handle requirements management?
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.
Q8. Does Sparx EA support version control?
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.
Q9. What is the Sparx EA Model Wizard and when should I use it?
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 customisations.
Q10. What are the most common early mistakes Sparx EA architects make?
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.
Section 2: Repository and Infrastructure
Q11. What database should I use for a Sparx EA repository?
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.
Q12. What is Sparx EA Pro Cloud Server (PCS)?
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, integration server capabilities, and the platform that EA GraphLink requires. 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.
Q13. What is WebEA and who should use it?
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.
Q14. How should I structure my Sparx EA repository for a large enterprise?
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.
Q15. How do I back up a Sparx EA repository?
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 artefact. 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.
Q16. How many elements can a Sparx EA repository hold?
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.
Q17. Should I host Sparx EA on-premises or in the cloud?
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.
Q18. What integration options does Sparx EA support?
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), EA GraphLink (the GraphQL API and MCP Server), and community/third-party connectors. The Integration Server is particularly valuable for synchronizing EA requirements and elements with Jira or Azure DevOps work items.
Q19. How do I manage access control in a shared Sparx EA repository?
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.
Q20. What causes Sparx EA repositories to become slow and how do I fix it?
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 Platform Support engagements.
Section 3: Modeling Languages
Q21. What is ArchiMate and when should I use it in Sparx EA?
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 artefacts. It is the default EA modeling language for most enterprise contexts.
Q22. What is BPMN and how does it differ from ArchiMate process modeling?
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.
Q23. What is SysML and when should I use it instead of UML?
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 signalling, 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.
Q24. Does Sparx EA support DMN (Decision Model and Notation)?
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.
Q25. Can I use ArchiMate and SysML in the same Sparx EA repository?
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.
Q26. What is the difference between UML Class diagrams and ArchiMate data modeling?
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.
Q27. How does Sparx EA handle UML state machines?
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 behavioural specification of that element. For safety-critical systems (rail interlocking logic, avionics mode management), state machines are first-class architecture artefacts used for certification evidence.
Q28. What is an ArchiMate viewpoint and how are they used in Sparx EA?
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.
Q29. Can Sparx EA import and export models in standard formats?
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. EA GraphLink provides real-time GraphQL access to the repository data for external tools and systems.
Q30. What modeling language should an EA architect learn first?
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. A 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.
Section 4: Frameworks and Standards
Q31. What is TOGAF and how does it work in Sparx EA?
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.
Q32. Is TOGAF certification necessary to use TOGAF in Sparx EA?
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.
Q33. What is BIAN and when does it apply?
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.
Q34. What is TM Forum and when does it apply?
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.
Q35. What is FEAF and how is it different from TOGAF?
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.
Q36. What is the relationship between TOGAF and ArchiMate?
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.
Q37. Does Sparx EA support safety-critical standards like DO-178C or EN 50128?
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.
Q38. What is UPDM and why does it matter for defense architecture?
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.
Q39. Can Sparx EA be used for data mesh or data fabric architecture?
Yes. Data mesh and data fabric architectures involve components: domains, data products, data contracts, governance planes, infrastructure platforms: that can be modelled 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.
Q40. Does Sparx EA support ISO 42010 (architecture description standard)?
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.
Section 5: MDG Technology
Q41. What is MDG Technology in Sparx EA?
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.
Q42. What is the difference between an MDG profile and an MDG technology?
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.
Q43. How do I create a custom MDG profile in Sparx EA?
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.
Q44. How does MDG governance affect AI query quality?
MDG governance is the primary determinant of AI query quality. EA GraphLink exposes the repository to AI tools by extracting elements, their stereotypes, their tagged values, and their relationships. 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 realisation relationship between them: all of which MDG governance defines and enforces.
Q45. What tagged values should every enterprise element have?
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/Optimising) and Investment Direction (Invest/Maintain/Harvest/Divest). These tagged values are the foundation for meaningful Power BI dashboards, Copilot queries, and governance reporting.
Q46. Can MDG profiles be version-controlled?
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.
Q47. What is a tagged value enumeration and why should I use them?
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.
Q48. How do relationship constraints in MDG improve repository quality?
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.
Q49. What is the MDG toolbox and how should I configure it?
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).
Q50. What is the relationship between MDG and the Sparx EA automation interface?
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.
Section 6: AI Integration
Q51. What is EA GraphLink?
EA GraphLink is a product from Sparx Systems that transforms the Sparx EA repository into a structured data source for external systems. It provides two interfaces: Interface A is a GraphQL API consumed by Power BI and other BI tools; Interface B is an MCP (Model Context Protocol) Server consumed by AI language model clients. EA GraphLink runs on Pro Cloud Server and requires a PCS deployment. Sparx Services implements EA GraphLink as part of Connect engagements.
Q52. What is the Model Context Protocol (MCP) and how does it relate to Sparx EA?
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. EA GraphLink implements MCP Server support, making the Sparx EA repository accessible to any MCP-compatible AI client. This means Microsoft Copilot, Claude Desktop, ChatGPT Enterprise, Azure OpenAI, Cursor, Kernaro AI Hub, and other MCP-compatible tools can query the EA repository using natural language.
Q53. Which AI tools can connect to Sparx EA via EA GraphLink?
Any AI client that supports MCP can connect to EA GraphLink’s MCP Server. Confirmed compatible tools include: Microsoft 365 Copilot (via M365 plugin framework), Kernaro AI Hub (purpose-built for Sparx EA), Kernaro Assist (conversational interface within Sparx EA), Claude Desktop (Anthropic), ChatGPT Enterprise with MCP plugin, Azure OpenAI with MCP integration, Cursor (for architecture-as-code workflows), and Microsoft Fabric (for agentic data pipelines). The ecosystem is expanding as MCP adoption grows across AI tooling.
Q54. How do I connect Microsoft Copilot to Sparx EA?
Microsoft Copilot connects to Sparx EA via EA GraphLink’s MCP Server, registered as a Microsoft 365 Copilot plugin. The integration requires: EA GraphLink deployed on Pro Cloud Server with MCP Server active, the MCP endpoint registered in the Microsoft 365 admin center or via a Teams app manifest, and Microsoft 365 Copilot licenses for the users who will use the integration. Sparx Services implements this configuration as part of a Connect engagement. Users in Teams or Outlook can then query the EA repository in natural language through Copilot.
Q55. What kinds of questions can I ask an AI tool connected to my Sparx EA repository?
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.
Q56. What is the difference between EA GraphLink Interface A and Interface B?
Interface A is a GraphQL API designed for structured data queries: Power BI queries this interface to populate dashboards, refresh semantic models, and provide executive reporting. It returns structured data (lists, hierarchies, property values). Interface B is an MCP Server designed for AI language model consumption: Copilot, Claude, Kernaro, and other AI tools query this interface using the MCP protocol. It returns contextual responses shaped for AI reasoning. One EA GraphLink deployment provides both interfaces simultaneously.
Q57. Does EA GraphLink modify the Sparx EA repository?
In standard read-only mode, no: EA GraphLink is a read interface. It does not write to the repository. AI tools connected via EA GraphLink’s MCP Server can query and read the repository but cannot modify it through the GraphLink interface. Modifications to the repository still happen through Sparx EA desktop, WebEA, or the automation interface. This is an important data governance point: connecting Copilot or other AI tools to EA GraphLink does not give them write access to the architecture.
Q58. Can EA GraphLink be used without Power BI?
Yes. EA GraphLink’s Interface A (GraphQL API) can be queried by any tool that supports HTTP and GraphQL: not just Power BI. Tableau, custom web applications, Salesforce dashboards, and Python scripts can all consume Interface A. Similarly, Interface B (MCP Server) is not restricted to Microsoft tools. EA GraphLink is tool-agnostic at the integration layer. Power BI is the most commonly used Interface A consumer because of its prevalence in enterprise environments, not because of a technical restriction.
Q59. What happens when AI queries a Sparx EA repository with poor MDG governance?
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.
Q60. Is there a risk that AI tools will expose sensitive repository content to unintended audiences?
Yes: and this is a governance consideration for the EA GraphLink deployment, not an inherent flaw in the technology. EA GraphLink access should be restricted to users with appropriate permissions using the same access controls applied to the Sparx EA repository itself. For Microsoft Copilot integration, the EA GraphLink plugin should only be available to users authorized to see the architecture content it exposes. Sparx Services includes access governance design as part of Connect engagement scoping.
Section 7: Kernaro Products
Q61. What is Kernaro and what do they make?
Kernaro is an independent software company focused on AI tooling purpose-built for Sparx EA. Kernaro’s primary products are Kernaro AI Hub (an AI-assisted architecture analysis platform that connects to Sparx EA via EA GraphLink) and Kernaro Assist (a conversational AI assistant interface within Sparx EA). Kernaro products are designed specifically for EA work: they understand EA concepts, ArchiMate constructs, and MDG-governed repository structures in ways that general-purpose AI tools do not.
Q62. What does Kernaro AI Hub do?
Kernaro AI Hub is an AI-assisted platform for EA analysis, review, and governance automation. Connected to a Sparx EA repository via EA GraphLink, AI Hub provides: automated element classification and recommendation, relationship gap detection (identifying missing relationships based on repository patterns), impact analysis for proposed changes, natural language queries against the repository, and architecture quality scoring. AI Hub operates on the governed repository data: the quality of its outputs is bounded by MDG governance quality.
Q63. What does Kernaro Assist do?
Kernaro Assist is a conversational AI interface embedded within the Sparx EA environment. 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 receive responses drawn from the live repository. Assist is designed for in-tool use during active architecture modeling, not for stakeholder-facing reporting. It reduces context-switching during modeling work and makes the repository’s own content accessible as a prompt.
Q64. What are the prerequisites for Kernaro AI Hub?
The minimum prerequisites for Kernaro AI Hub are: a Sparx EA repository with Pro Cloud Server, EA GraphLink deployed and configured, and a minimum level of MDG governance (governed stereotypes and tagged values on key element types). Kernaro AI Hub is licensed separately from Sparx EA and from EA GraphLink: it is a Kernaro product license. Sparx Services implements the EA GraphLink and MDG governance prerequisites as part of a Connect engagement and configures the Kernaro product integration.
Q65. What is the difference between Kernaro AI Hub and Microsoft Copilot connected to EA?
Kernaro AI Hub is a purpose-built EA intelligence platform: it understands EA-specific concepts (ArchiMate element types, MDG stereotypes, TOGAF content metamodel), provides EA-specialist analytics (relationship gap detection, architecture quality scoring), and is designed for architect-level use. Microsoft Copilot connected to EA is a general-purpose AI assistant that happens to have EA repository data available as a context source: useful for conversational queries by non-architect stakeholders. Both connect via EA GraphLink MCP; they serve different user audiences and use case depths.
Q66. Can Kernaro AI Hub detect missing relationships in my repository?
Yes: relationship gap detection is one of Kernaro AI Hub’s core capabilities. It analyzes the pattern of existing relationships in the repository (which element types are connected to which other element types, through which relationship types) and identifies elements that appear to be missing expected relationships based on those patterns. For example, if every BusinessCapability element in the repository has at least one ApplicationComponent realizing it except for five, AI Hub flags those five as probable gaps. Validation of the suggestion still requires architect review.
Q67. Does Kernaro replace the need for architects?
No. Kernaro products automate the routine, time-consuming aspects of architecture work: element classification, relationship gap scanning, 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. Kernaro is productivity tooling for architects, not a replacement for architectural expertise. The organizations that get the most from Kernaro products are those with strong EA practices that want to scale their output.
Q68. Is Kernaro compatible with all versions of Sparx EA?
Kernaro products require Sparx EA Pro Cloud Server and EA GraphLink. They are designed for current and recent versions of Sparx EA (v16+). Organizations running older Sparx EA versions may need to upgrade before Kernaro deployment. Sparx Services verifies version compatibility as part of Connect engagement scoping. Kernaro is an independent company and publishes its own compatibility matrix: Sparx Services works with both Sparx Systems and Kernaro to ensure the deployment configuration is supported.
Q69. What is the licensing model for Kernaro products?
Kernaro AI Hub and Kernaro Assist are licensed by Kernaro as standalone products. Licensing is based on the number of active users and the scale of the EA repository. Kernaro products are not bundled with Sparx EA or EA GraphLink: they are separate purchases. Sparx Services is familiar with Kernaro’s licensing model and can advise on appropriate license configuration during Connect engagement scoping. Contact Sparx Services for a discussion that covers both EA GraphLink and Kernaro licensing in the context of your specific deployment.
Q70. Can Kernaro write changes back to the Sparx EA repository?
Kernaro Assist can suggest and (with architect confirmation) apply changes to the repository: element properties, tagged values, and in some cases relationship creation: via the Sparx EA automation interface. This is supervised write access: the architect reviews Kernaro’s suggestion and approves it before any change is committed. Kernaro AI Hub operates in read-only mode for its analytical functions. No Kernaro product makes unsupervised autonomous changes to the EA repository.
Section 8: EA Practice
Q71. What is an Architecture Review Board (ARB) and how does Sparx EA support it?
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 artefacts (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/.
Q72. What is a Center of Excellence (CoE) in an EA context?
An EA Center of Excellence is the organisational 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.
Q73. How do you measure the value of enterprise architecture?
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 EA GraphLink), and cost avoidance estimates (projects where architecture review prevented a planned duplicate investment).
Q74. How do you get stakeholders to actually use the EA repository?
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 live 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 Copilot in Teams stops emailing the EA team for dependency lists. 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.
Q75. What is architecture debt and how do you manage it in Sparx EA?
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 visualisation of end-of-life applications in Power BI. The ARB process is the governance mechanism that prevents new debt accumulation.
Q76. How does EA practice differ in project-based organizations vs. steady-state operations?
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.
Q77. How should architecture principles be modelled in Sparx EA?
Architecture principles are most effectively modelled 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.
Q78. What is the EA operating model and how does it relate to Sparx EA?
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.
Q79. How do you handle architects who don’t update the repository?
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.
Q80. What does a mature EA practice look like in 2026?
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 Power BI-connected reporting layer accessible to executives and program managers, EA GraphLink enabling natural language queries via Copilot or equivalent AI tools, and an Amplify 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.
Section 9: Sparx Services Engagements
Q81. What is a Discover engagement?
A Discover engagement ($25K–$75K, 4–8 weeks) is Sparx Services’ starting engagement for organizations that need to understand where they are before deciding where to go. Discover 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. Discover 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.
Q82. What is a Connect engagement?
A Connect engagement ($50K–$185K+) deploys the EA GraphLink integration layer that connects the Sparx EA repository to external systems: Power BI, Microsoft Copilot, Microsoft Fabric, Kernaro, Salesforce Tableau, or other integrations. Connect is the engagement that makes the EA repository visible and queryable outside the EA team. It includes EA GraphLink deployment, semantic model configuration, Power BI dashboard development, and AI tool integration. Connect requires a reasonably well-governed repository; poor MDG governance requires a Deploy engagement first.
Q83. What is an Amplify engagement?
An Amplify engagement ($45K–$160K) maximises the value of an existing EA repository and integration deployment. Amplify 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. Amplify is the right engagement for organizations that have a working EA practice and integration layer but want to extend and deepen their investment.
Q84. What is a Deploy engagement?
A Deploy engagement ($30K–$130K) establishes or reconfigures the Sparx EA repository and MDG governance foundation. Deploy is the right engagement 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. Deploy includes package structure design, MDG profile configuration, diagram templates, toolbox configuration, and architect training. It is the governance foundation engagement that other engagements build on.
Q85. What does an Architect Development engagement cover?
An Architect Development engagement is focused on building the EA 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 effectively. Architect Development can be delivered as a standalone engagement or as a component within Amplify.
Q86. What does Platform Support involve?
Platform Support is Sparx Services’ ongoing advisory and support offering for organizations running production Sparx EA deployments. It provides: named expert advisory access for complex Sparx EA technical questions, MDG profile development and review, performance monitoring and optimisation, Pro Cloud Server administration support, and quarterly repository health reviews. Platform Support is priced on a retainer basis and is the right choice for organizations with mission-critical EA deployments that need expert backup for their internal team.
Q87. When should an organization start with Discover vs. going straight to Deploy?
Start with Discover 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 Deploy 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 engagement after an initial scoping conversation.
Q88. Can Sparx Services work with an existing EA team rather than replacing it?
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.
Q89. Does Sparx Services implement non-Sparx EA tools?
No. Sparx Services is a Sparx EA specialist. All engagements are centred 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.
Q90. How does Sparx Services price its engagements?
Sparx Services engagement pricing is based on scope and complexity, not time-and-materials. Published price ranges (Discover: $25K–$75K; Connect: $50K–$185K+; Amplify: $45K–$160K; Deploy: $30K–$130K) are the typical ranges for standard engagements. Specific scoping is required for each engagement 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.
Section 10: Common Problems
Q91. What do I do when my Sparx EA repository is a complete mess?
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 a Discover engagement: do not attempt large-scale cleanup without a clear plan.
Q92. My repository has been built by multiple architects with no consistent standards. How do I fix it?
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.
Q93. Stakeholders say the EA repository does not reflect reality. What is going wrong?
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 (EA GraphLink-powered dashboards that surface data currency, making staleness visible to stakeholders).
Q94. My MDG profiles are inconsistent across different domains. How do I standardize?
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. Standardisation 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 a Deploy engagement scope.
Q95. I cannot get meaningful AI queries against my repository. What is the problem?
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 modelled 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, EA GraphLink 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.
Q96. My Sparx EA Pro Cloud Server is slow. What should I investigate?
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 for EA GraphLink (server resource constraints, unoptimised GraphQL queries). Start with Sparx Systems’ published PCS performance tuning guide. Sparx Services provides PCS performance assessment under Platform Support.
Q97. Architects are creating elements directly on diagrams instead of in the package hierarchy. How do I stop this?
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.
Q98. My organization has three different EA teams using three different approaches. How do we unify?
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 Discover engagement that spans all three teams and produces a unified target operating model is the right starting point.
Q99. We invested in Sparx EA three years ago but the repository is barely used. What went wrong?
The most common causes of an underused EA repository are: lack of stakeholder-facing outputs (the repository produces internal artefacts 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 Discover engagement can diagnose it.
Q100. What should I do this week to improve my EA practice?
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, scope a Connect engagement: Power BI dashboards showing your application lifecycle and capability map will change your stakeholder conversations within 60 days of go-live.
Continue Reading
100 architect questions across Sparx EA’s breadth. For deeper treatment of specific topics:
- AI integration: AI Augmented Architecture: The Definitive Guide
- MDG governance: MDG Technology: Why Your AI Integration Quality Starts Here
- Microsoft ecosystem: Connecting Sparx EA to Power BI, Copilot and Fabric
- Architecture Review Board: Architecture Review Boards in Sparx EA
- Banking architecture: BIAN in Sparx EA
