EOModeller EOModeller
Sign in Get started
Notations

ArchiMate, all seven layers, all first-class.

EOModeller ships ArchiMate 3.1 with every layer of the standard implemented as a first-class concern — not as flavours of generic boxes, not as a stereotype profile on top of UML, not as half-built "core layers plus deferrals". The Business, Application, Technology, Motivation, Strategy, Physical, and Implementation & Migration layers are each fully represented with their canonical elements, visuals, and relationship semantics.

For exact element-by-element coverage see the notation conformance page. What follows is the practising-architect view: what the support looks like in real work, where it's strong, and where the v1.0 boundary falls.

The seven layers

Each layer renders with the colour family the spec assigns (yellow Business, blue Application, green Technology, purple Motivation, etc.) and supports the full set of standard ArchiMate element shapes. Element coverage is spec-verified against the ArchiMate 3.1 standard.

Business (13 elements)
Actor, Role, Collaboration, Interface, Process, Function, Interaction, Event, Service, Object, Contract, Representation, Product. The actor and role surface is where most enterprise work starts; EOModeller handles the actor → role assignment cleanly.
Application (9 elements)
Component, Collaboration, Interface, Function, Interaction, Process, Event, Service, Data Object. Application Components are the workhorses of architecture diagrams; their used-by-Business-Service / realises-Business-Function patterns are core to layered architecture.
Technology (13 elements)
Node, Device, System Software, Collaboration, Interface, Path, Communication Network, Function, Process, Interaction, Event, Service, Artifact. Together with the cloud profile packs (AWS, Azure shipped at v1.0), the Technology layer is where most modern infrastructure modelling lives.
Motivation (10 elements)
Stakeholder, Driver, Assessment, Goal, Outcome, Principle, Requirement, Constraint, Meaning, Value. Most architectural discussions that go badly are missing the Motivation layer — the conversation moves to "what we're building" before settling "what for". EOModeller's Motivation support is complete, including the harder elements like Principle and Meaning that other tools drop.
Strategy (4 elements)
Resource, Capability, Course of Action, Value Stream. The Strategy layer is small but load-bearing for transformation programmes: Course of Action and Value Stream are how the architect frames an enterprise's intent.
Physical (4 elements)
Equipment, Facility, Distribution Network, Material. Often overlooked; absolutely necessary when the architecture touches things like data centres, manufacturing lines, or physical-product flows.
Implementation & Migration (5 elements)
Work Package, Deliverable, Implementation Event, Plateau, Gap. These are where the architecture meets the project plan; the Plateau / Gap pair is how the architect describes intermediate states and what remains to reach the target architecture.

Relationships

All eleven ArchiMate relationship types render correctly with the canonical visual treatment:

  • Composition — filled diamond at the whole end.
  • Aggregation — open diamond at the whole end.
  • Assignment — solid line with filled dots at both ends.
  • Realization — dashed line with open triangle at the realising end.
  • Used by — solid line with open triangle at the using end.
  • Access — dashed line with open arrowhead; direction signals read / write / read-write.
  • Influence — dashed line with plus/minus labels.
  • Triggering — solid line with filled arrowhead.
  • Flow — dashed line with filled arrowhead.
  • Specialisation — solid line with open triangle.
  • Association — plain solid line.

Relationship validity (which relationships are permitted between which elements) is enforced per the ArchiMate 3.1 specification. An assignment from a Goal to an Application Component is rejected; a realisation from an Application Component to a Business Service is accepted. The validation rule library covers the canonical relationship matrix.

Viewpoints

ArchiMate 3.1 defines about two dozen standard viewpoints — filtered, audience-oriented views over the model. EOModeller supports the viewpoint vocabulary as a property on the diagram; named viewpoints in the standard (Application Cooperation, Information Structure, Strategy, Goal Realisation, Stakeholder, etc.) appear in the diagram metadata and filter the toolbox to the elements the viewpoint allows.

Custom viewpoints are supported as user-named entries in the same surface — the architect's organisation often has its own viewpoint definitions, and EOModeller doesn't force the standard ones to be the only options.

Layered architecture work

The pattern most enterprise architects use ArchiMate for — Business Service supported by Application Service supported by Technology Service, with Motivation flowing down through Goals to Requirements — is the workflow EOModeller is designed around. Cross-layer relationships work because the metamodel underneath is unified; references survive across diagrams; the same Application Component on a Cooperation diagram is the same Application Component on an Application Usage diagram, not a copy that has to be re-authored.

This is the thing most diagramming tools get wrong — they treat the same element as a fresh shape on every new diagram, and the architecture becomes a folder of similar-looking artefacts that don't actually share semantics. EOModeller's three-layer element model (identity, representation, instance) means an element you place on a second diagram is the element from the first.

Working alongside UML

Real architecture diagrams mix notations. An Application Component might be detailed as a UML Component on a follow-up diagram with attribute and operation compartments; an ArchiMate Business Process might link out to a UML Activity diagram for the implementation detail; an ArchiMate Goal might trace through to a UML Use Case that delivers it.

EOModeller handles this directly: an ArchiMate element and a UML element can sit on the same diagram, relate to each other, and round-trip through the model store. The UML page covers the UML side; the conformance page lists what's first-class versus deferred.

Cloud profiles on top of Technology

AWS and Azure ship at v1.0 as first-class profile packs (about 1,000 stereotype definitions combined). They render with the official cloud-provider icons inside Technology-layer containers and follow the canonical cloud containment hierarchy (Region, Availability Zone, VPC / VNet, Subnet, Resource Group).

The cloud profiles use the same stereotype machinery that handles user-authored profiles, so an architect who needs stereotypes EOModeller doesn't ship can add them in the Stereotype editor on the Property Panel. Kubernetes, Apache Stack, CNCF Common, Open Source Databases, and GCP are all planned as post-launch profile packs.

ArchiMate Exchange Format (export)

The Open Group's ArchiMate Exchange File Format is the notation's native interchange format. EOModeller doesn't ship ArchiMate Exchange export at v1.0 — XMI export is the v1.0 interchange path and covers the UML portion of mixed models. ArchiMate Exchange export is a post-launch addition; if it's a launch blocker for the way you work, tell us.

What's strong about EOModeller's ArchiMate support

All seven layers, not just the core three
Many tools treat Motivation, Strategy, Physical, and Implementation & Migration as second-class or profile-pack-style additions. EOModeller treats them as first-class peers of Business / Application / Technology. The visual treatment, the toolbox, the relationship validation — all uniform across the seven layers.
Relationship validity enforced
Other tools let you draw any relationship between any pair of elements; the architect discovers at review time that half the relationships violate the specification. EOModeller validates relationship validity against the ArchiMate 3.1 matrix at draw time, with formality-zone-gated severity: informal sketches are permissive, formal diagrams enforce.
The metamodel underneath is shared with UML
An ArchiMate element and a UML element are different classifiers in the same metamodel substrate. Cross-notation references work; same element on multiple diagrams stays one element; element identity persists across notation switches.
Standard and custom viewpoints, both first-class
ArchiMate's standard viewpoints are pre-loaded. Custom viewpoints from your organisation's framework are equally supported — you don't have to choose between the standard ones and the ones your team actually uses.

References