ArchiMate 3.0 is the standard notation for enterprise architecture in Sparx EA. Most EA teams have ArchiMate models. Far fewer have well-governed ArchiMate implementations: where MDG Technology enforces element typing, every element has an assigned owner and rationale, and views are structured to answer the questions stakeholders actually ask. That gap is where practice maturity lives, and it is precisely the gap that determines whether your repository is useful for AI-assisted architecture analysis or just a well-formatted diagram collection.
Key Takeaways
ArchiMate’s layered structure is its defining characteristic: and its most commonly misunderstood aspect in practice. The layers are not just categories; they represent distinct concerns with defined relationship types between them. Getting the layer discipline right is the foundation of a governed ArchiMate implementation.
Goals, drivers, principles, requirements, and constraints. The Motivation layer answers “why”: why the organization is investing in change, what requirements drive architecture decisions, which principles constrain the solution space.
In practice, the Motivation layer is the least populated and the highest value for stakeholder conversations. An architecture practice that has populated Motivation elements: and linked them to the Strategy and Business layers: can answer questions that practices without Motivation documentation cannot: “which business driver justifies this application investment?” or “which architectural principle required this technology constraint?” These are exactly the questions executives ask, and they are exactly the questions that are hard to answer when motivation is implicit.
For AI readiness: Motivation elements linked to downstream artifacts are one of the highest-value data types in the repository. A Kernaro AI Hub query about which business goal a specific application component serves only works if the Motivation-to-Application realization chain exists in the repository.
Capability maps, value streams, and courses of action. The Strategy layer bridges the Motivation and Business layers: it translates organizational intent into the structural view of what capabilities the organization needs and how value flows across them.
Capability modeling at the Strategy layer is one of the most mature practices in enterprise architecture. A well-developed capability map with heat-mapping for investment priority, capability owners, and lifecycle status gives the architecture practice a durable reference that outlasts individual projects and organizational changes.
Business processes, business functions, business actors, roles, and business objects. The Business layer documents how the organization operates: the processes people follow, the roles they play, and the information they work with.
This is the layer where BPMN most commonly supplements ArchiMate. ArchiMate Business layer notation is appropriate for architectural-level process documentation; BPMN is the right choice when you need process flow detail, decision branching, and cross-organizational choreography. The two integrate via a cross-reference pattern covered below.
Application components, application services, application interfaces, and data objects. The Application layer is the most commonly populated layer in commercial EA practice: application portfolio documentation is often the starting point for EA practices, and it maps cleanly to ArchiMate Application layer concepts.
The discipline here is consistency: application components, services, and interfaces are distinct concepts, and treating them as interchangeable produces a repository that is difficult to query. An application component realizes application services; application services are consumed by business processes. That chain: Business process uses Application service realized by Application component: is the core traceability relationship that EA practices need to maintain, and the one most commonly collapsed into informal diagram notation.
Technology services, system software, nodes, and communication paths. The Technology layer documents the infrastructure that supports the Application layer: and it frequently has significant overlap with CMDB and infrastructure inventory data.
One of the highest-value integration patterns for EA practices: importing or connecting CMDB data to the Technology layer, so that architecture models reflect actual deployed infrastructure rather than a separate, manually maintained representation. EA GraphLink supports this integration pattern.
Physical infrastructure, equipment, distribution networks, and implementation events. This layer is less commonly used in commercial enterprise architecture and more common in defense, aerospace, and MBSE contexts. Implementation events: milestones, deliverables, and work packages: are used in Architecture Roadmap development.
MDG Technology is the mechanism in Sparx EA that enforces ArchiMate semantics at the repository level. Without a governed MDG Technology profile, ArchiMate in Sparx EA is essentially a drawing convention: architects use the elements they recognize, apply stereotypes they remember, and create relationships that look plausible. The result is a repository that may look like ArchiMate but does not behave like it.
A governed MDG Technology profile for ArchiMate does four things:
Element type enforcement. The toolbox presents only the element types defined in the profile. Architects cannot create a generic class and call it an application component: the element type is locked to the ArchiMate Application Component definition, with its defined properties and valid relationship types.
Tagged value requirements. MDG Technology definitions can mandate tagged values on element creation: owner, rationale, lifecycle status, review date, and any domain-specific attributes your practice needs. A repository where every Application Component has an assigned owner and a lifecycle status is a repository where “show me all application components in the retirement phase owned by Infrastructure” is a valid and answerable query.
Relationship validation. ArchiMate defines which relationship types are valid between which element types. MDG Technology profiles can enforce these constraints, preventing architects from creating ArchiMate relationships that violate the specification: relationships that are architecturally meaningless and that pollute query results.
Profile and template consistency. When new elements are created from a governed MDG profile, they inherit the correct structure. Teams working across multiple repositories or on-boarding new architects get consistent starting points rather than blank elements.
Why this matters for AI: EA GraphLink transforms the Sparx EA repository via the MDG Technology definition into AI-accessible data. It uses the MDG schema as the structure through which architecture data is exposed. A consistent, well-defined MDG produces rich, specific, queryable output. An informal model with inconsistent element typing produces ambiguous results that no AI tool: Kernaro AI Hub, MCP-connected LLMs, or any other integration: can reliably interpret. MDG quality is the upstream prerequisite for every AI integration Sparx Services deploys.
These are not beginner errors: they are patterns seen in EA practices of every maturity level, often because they were introduced early and never corrected.
Using Application Component where Technology Service is correct. Application Components are logical software units; Technology Services are infrastructure-level services (compute, storage, network, middleware). When infrastructure services are modeled as Application Components, the Application-to-Technology layer boundary collapses and the repository cannot accurately represent infrastructure dependencies. This produces incorrect impact analysis when infrastructure changes are assessed against application portfolios.
Mixing layers without explicit cross-layer relationships. ArchiMate’s cross-layer relationships: serving, realization, assignment: are what make the notation analytically useful. Placing elements from multiple layers on a single diagram without explicit cross-layer relationships produces a picture that communicates to the diagram reader but does not record the architectural meaning in the repository. The relationships are what make queries possible; diagrams without relationship traceability are dead ends for analysis.
Building diagrams without the underlying elements (diagram-first modeling). The most pervasive practice quality problem in Sparx EA. Architects create diagrams, place shapes, and connect them visually: but the repository elements behind those shapes are not consistently defined, tagged, or related at the model level. This produces a repository where diagrams look complete but queries return incomplete results. Every element that appears in a view should exist as a properly defined, tagged model element: not just a diagram shape.
Neglecting the Motivation layer: leaving “why” undocumented. Architecture practices that skip the Motivation layer produce repositories where the connection between business strategy and architecture decisions is implicit. When stakeholders ask why a decision was made, the answer is not in the repository. When architects leave and institutional knowledge walks out, the repository cannot reconstruct the reasoning. Motivation layer population is a discipline investment with a long payoff: it should be started early.
Over-reliance on the generic ArchiMate profile without MDG customization. Sparx EA ships with a standard ArchiMate MDG profile. For some practices, it is sufficient. For most practices with specific governance requirements: domain-specific tagged values, lifecycle management fields, integration attributes for EA GraphLink: the standard profile needs to be extended. Using the out-of-box profile without customization is not wrong; it is a ceiling on what your governance can enforce and what your AI integrations can query.
ArchiMate’s Business layer notation covers business processes at the architectural level: process flows that document significant organizational behaviors, not the step-by-step detail that a process owner or business analyst needs for analysis or improvement.
When that level of process detail is needed, BPMN is the right notation. Sparx EA supports both in the same repository, and the integration pattern is straightforward:
The value of maintaining the integration pattern: rather than treating BPMN and ArchiMate as separate models: is that process-level changes in the BPMN model can be traced to application service dependencies in the ArchiMate model. An impact analysis query about a proposed process change can surface application dependencies because the cross-reference is explicit.
See the BPMN in Sparx EA guide for the detailed integration pattern.
The difference between a well-governed ArchiMate implementation and an informal one becomes concrete when you connect AI tools to the repository.
A stakeholder asks Kernaro AI Hub: “What application components implement the Order Management capability?” In a well-governed repository, this query resolves cleanly: the Capability element exists in the Strategy layer, Application Components are linked to it via ArchiMate Realization relationships, and those relationships are typed correctly. The answer is a list of application components with their owners, lifecycle status, and relevant tagged values.
In an informal repository: where capabilities exist as labels on PowerPoint slides but not as typed ArchiMate elements, or where the Realization relationships exist in some diagrams but not in the model: the same query returns incomplete results, or nothing. The AI is not the bottleneck; the data structure is.
The same logic applies to every useful architecture query: impact analysis, technology currency assessment, capability gap identification, application rationalization. These are all pattern-matching operations over repository data. The pattern-matching is only as good as the data structure that MDG Technology governance creates.
Sparx Services’ Amplify service develops this governance capability: MDG customization for ArchiMate, modeling standards that architects can follow consistently, automated quality checks, and the integration work that connects a governed repository to EA GraphLink and Kernaro AI Hub.
What is ArchiMate and why use it in Sparx EA?
ArchiMate is an open standard notation for enterprise architecture, maintained by The Open Group. It provides a common language for describing and visualizing architecture across business, application, and technology domains. In Sparx EA, ArchiMate is the primary notation for EA practices because it is purpose-built for the types of relationships: between capabilities, processes, applications, and infrastructure: that enterprise architects need to document and analyze. UML handles software design well; ArchiMate handles enterprise-level structure and dependency better.
What is the difference between ArchiMate 3.0 and ArchiMate 2.1?
ArchiMate 3.0 added the Motivation, Strategy, and Physical/Implementation layers, which are absent in 2.1. It also introduced significant refinements to the Motivation layer concepts, added the Value Stream element, and aligned more closely with TOGAF terminology. Most active EA practices should be using ArchiMate 3.0; 2.1 models can be migrated, but the migration requires reviewing element mappings carefully. Sparx EA supports ArchiMate 3.0 natively.
Do I need the ArchiMate MDG profile to use ArchiMate in Sparx EA?
Technically, no: you can draw ArchiMate-style diagrams using any notation tool. In practice, yes. The ArchiMate MDG profile is what enforces element types, makes the correct toolbox available, and enables relationship validation. Without it, your team is applying ArchiMate naming conventions to generic elements, which produces a repository that looks like ArchiMate but does not behave like it for queries, reporting, or AI integration. Sparx EA ships with a standard ArchiMate MDG profile; most practices need to extend it with domain-specific tagged values and governance requirements.
What is the difference between Application Component and Technology Service in ArchiMate?
An Application Component is a modular, deployable, and replaceable part of a software system: it is a logical software unit. A Technology Service is a service provided by infrastructure: compute, storage, network, database engines, middleware platforms. Application Components use Technology Services; they are not the same concept. A common mistake is modeling database services, message queues, and cloud platform services as Application Components rather than Technology Services, which collapses the Application-Technology layer boundary and produces incorrect dependency analysis.
How do I enforce ArchiMate element typing in my team’s Sparx EA repository?
MDG Technology profiles are the enforcement mechanism. A well-configured MDG profile restricts the toolbox to the element types defined in the profile, applies tagged value requirements on element creation, and validates relationship types. Beyond MDG configuration, practices that enforce element typing also use: repository audit scripts that flag non-conformant elements, model review checkpoints in governance processes, and onboarding standards that define what correct element creation looks like. The Amplify service develops this governance stack: MDG customization plus process and tooling automation.
Can I combine ArchiMate with BPMN in the same Sparx EA repository?
Yes, and for most practices this is the right approach. ArchiMate and BPMN serve different levels of process documentation: ArchiMate for architectural-level process structure, BPMN for detailed process flows with decision logic and cross-system choreography. The integration pattern: cross-referencing BPMN processes and tasks to ArchiMate Business Processes and Application Services: maintains traceability between the detailed process model and the architecture model. Sparx EA supports both natively; the integration pattern requires deliberate package structure and cross-reference discipline.
What ArchiMate views should every practice have?
At minimum: a Capability Map (Strategy layer), an Application Portfolio view (Application layer with ownership and lifecycle status), a Technology Infrastructure view (Technology layer), and a Motivation overview linking strategic drivers to capability requirements. Practices with active change programs also need a Roadmap view (Physical/Implementation layer), and Architecture Landscape views that show current, transitional, and target states. The views that matter most are the ones that answer questions stakeholders actually ask: which means the view inventory should be driven by stakeholder use cases, not by ArchiMate layer completeness.
How does ArchiMate model quality affect Kernaro AI Hub responses?
Directly. Kernaro AI Hub queries are resolved against repository data exposed by EA GraphLink. The quality of the response depends on: whether the relevant elements exist as typed ArchiMate elements (not just diagram shapes), whether the relationships between them are typed correctly and recorded at the model level, and whether tagged values are populated consistently. A query that returns useful results in a governed repository returns nothing or incorrect results in an informal one: not because the AI is different, but because the data it is querying is structured differently. MDG governance quality is the primary lever for improving AI query reliability.
What is the relationship between ArchiMate and TOGAF?
TOGAF is a process framework: it defines what to do, when to do it, and what artifacts to produce during each ADM phase. ArchiMate is a notation standard: it defines how to express architecture in a consistent visual language. They are complementary. TOGAF’s Business Architecture phase (ADM Phase B) produces architecture documented in ArchiMate Business layer models. Technology Architecture (Phase D) produces ArchiMate Technology layer models. Most enterprise architecture practices combine TOGAF governance with ArchiMate notation; neither replaces the other. See the TOGAF in Sparx EA guide.
Is there a Sparx EA ArchiMate template I can start from?
Sparx EA ships with a standard ArchiMate 3.0 MDG profile and sample models. These are adequate starting points for learning ArchiMate in the tool. For a practice implementation: where you need domain-specific tagged values, governance enforcement, onboarding templates, and reporting configurations: the standard profile needs customization. Sparx Services develops these customized ArchiMate implementations as part of the Amplify service. The Discover assessment establishes what your current MDG profile covers and what gaps exist between it and your governance requirements.
Amplify ($45K–$160K) develops EA practice capability: MDG Technology customization for your ArchiMate implementation, modeling standards and governance automation, ArchiMate-BPMN integration patterns, and quality assurance tooling that makes governance sustainable rather than dependent on individual discipline.
Discover ($25K–$75K) includes an MDG readiness assessment: a structured evaluation of your current ArchiMate implementation against practice maturity benchmarks and AI integration requirements, with a clear gap analysis and prioritized recommendations.
Talk to a Sparx Services architect about where your organization is on the journey and what the next stage looks like.