ArchiMate Layers as Executable Architecture:
From Motivation to Running Process
Enterprise architecture models are documentation artefacts. Slides, Archi exports, PDF reports. They describe the enterprise accurately and cannot be executed. The gap between an ArchiMate diagram and a running process gets bridged by hand, imperfectly, over months. By the time the process is live the diagram is stale, and everyone quietly stops trusting it.
That staleness is not a discipline problem. It is a structural one: the model and the running system are two artefacts with no mechanical relationship, so nothing forces them to agree. Priostack closes that gap by making them the same artefact. Every ArchiMate 4.0 layer - Motivation, Strategy, Business, Application, Technology, Implementation and Migration - carries both its structural metadata and a compilation to executable semantics. The model you open in Archi is the model the engine runs.
This article walks through what each layer compiles to and why, using a loan origination domain as the running example. The reference model is a valid Archi 4.x file you can open alongside it.
Contents
- The six layers and what each one answers
- The dependency rule: why the model depends on nothing
- Motivation: intent with operational semantics
- Strategy: plans as ordered nets
- Business: the vocabulary everything else references
- Application: components, interfaces and UI models
- The IFML bridge: from a screen to a started process
- Technology: infrastructure in the same language
- Migration: roadmaps you can simulate
- The vertical spine, end to end
- Data objects and the structural audit trail
1. The six layers and what each one answers
ArchiMate organises an enterprise into layers, each answering a different question. Priostack keeps that structure exactly as the standard defines it and adds one thing: each element type knows how to compile itself into executable semantics when execution is needed.
One registry holds all six. An architecture team maintains it; the process engine, the integration layer and the UI layer all read from it. There is no export step, no synchronisation job, and no second copy of the truth.
2. The dependency rule: why the model depends on nothing
One architectural rule governs everything else: the enterprise model depends on nothing. It does not know about the process engine, the integration layer, or the UI compiler. They all know about it. The dependency graph is acyclic and flows one way.
The consequence is worth stating plainly, because it is what makes the model trustworthy rather than decorative: you can load, validate and test an enterprise model in complete isolation. No engine, no message bus, no database. The model is a fact base about the business, and a fact base that needs a running system in order to be checked is not a fact base.
The binding between layers is by identifier, not by type dependency. A process references a business service by its ID; an integration endpoint references the same ID; a UI action references a process by ID. Strings, not imports. That is what lets each layer be versioned, replaced and tested on its own, and it is the reason a change to how something executes never forces a change to what the business says it is.
3. Motivation: intent with operational semantics
The Motivation layer is the unusual one. It deals in intent rather than structure, which is exactly why it is normally the layer that never executes: a Goal is not a thing that runs. Priostack gives each motivation element a specific operational meaning, so intent stops being commentary attached to the model and becomes part of what the model does.
| Element | Compiles to | Operational meaning |
|---|---|---|
| Driver | An entry point | A stimulus the enterprise responds to. Regulatory pressure or customer expectation becomes something that can be switched on, and everything conditioned on it becomes enabled. |
| Goal | A pair of terminal states, achieved and violated, with a deadline | "Approve 90% of clean applications within 48 hours" resolves per instance against the actual elapsed time. The goal measures itself. |
| Constraint | An inhibitor | While the constraint is unsatisfied, the transitions it guards cannot fire. Not "will not" - cannot. |
| Principle | A guard condition in FEEL | A statement like "no loan exceeds 500 000" attaches to the transitions it governs and is evaluated before each firing. |
The Constraint case is the one worth dwelling on, because it is a different kind of guarantee from the one most compliance tooling offers. "Identity verification is mandatory before underwriting" is normally a rule: a check somewhere in application code, which holds as long as every code path remembers to call it. As an inhibitor it is structural. The underwriting transition has no enabled firing while the verification state is unmarked, so there is no code path that skips it, because there is no path at all. The difference between a rule and a structural impossibility is the difference between a policy and a guarantee, and it is the entire reason the compliance story here is worth telling.
Goals are the counterpart on the measurement side. A goal with a deadline resolves to achieved or violated for every single instance, which means the question "are we meeting our stated objective?" is answered continuously from execution rather than assembled quarterly from a spreadsheet. That is also what makes strategy drift detectable: a goal the organisation committed to and executions that keep landing on the violated side is a measurable gap between what was intended and what is happening.
4. Strategy: plans as ordered nets
The Strategy layer sits between the why and the what. Given our goals and constraints, which capabilities must we exercise, and in what order?
A Course of Action is an ordered list of capabilities, and it compiles to exactly that: a linear net where each transition dispatches one capability to whichever business service realises it. A Value Stream is the same shape with named stages, which is the more useful of the two in practice because the stage boundaries are real anchors. When the "Credit Assessment" stage completes, that completion is a state the rest of the system can react to - an integration endpoint fires, a metric increments, a downstream stage becomes enabled - without anybody wiring an event by hand.
5. Business: the vocabulary everything else references
The Business layer is the centre of gravity. It holds the domain concepts, the roles that act, the capabilities the enterprise has, the services it offers, and the processes and events that organise work. Everything above points down into it and everything below points up into it.
Business Object: one definition of a domain concept
A Business Object defines what a loan application is, structurally, without holding any runtime state. Process data schemas reference it by URI rather than redefining it. That single indirection is what stops the classic drift where the architecture model says a loan application has one shape, the BPMN process assumes another, and the integration layer translates between two definitions that were supposed to be the same definition.
Business Service: the anchor for integration
A Business Service is the named capability the enterprise exposes. Integration endpoints reference services by that identity rather than by hostname, which means the topology is expressed in business vocabulary: "the fraud service consumes from this channel" rather than "10.0.3.14 consumes from this channel". Infrastructure moves; the business service does not.
This is also what makes a class of governance question answerable by reading the model. Which services have no endpoint? Which endpoints serve no declared service? Which capability is claimed by the strategy layer and realised by nothing? Those are gaps between layers, and once both sides are in one model they are queries rather than audits.
Business Event: something happened
Events correspond to messages on subscription channels. A business event is where the model stops describing structure and starts describing time, and it is the natural join between the enterprise model and the integration topology described in the companion article.
6. Application: components, interfaces and UI models
The Application layer holds the software that realises business services. Each Application Component is a deployable unit exposing and consuming Application Interfaces.
The design decision worth explaining is that a component may expose several interfaces, and each interface independently backs either a UI surface described in IFML or a machine endpoint. The tempting alternative is one interface per component, which is simpler right up until the first component that has both a screen and an API - which is most of them. Keeping them separate means the loan portal's web form and the loan portal's REST interface are two interfaces of one component, correctly, rather than two components that pretend not to be related.
An interface backed by an endpoint carries the binding to the integration layer. When the component's entry state receives a message - a loan submission - the engine resolves that endpoint and routes the message through the declared pipeline. No glue code sits in between.
7. The IFML bridge: from a screen to a started process
IFML, the OMG's Interaction Flow Modeling Language, describes UI behaviour: view containers, view components, events and the flows between them. In Priostack an application interface can carry an IFML model, and that model compiles to an executable net in the same way every other layer does.
This is the layer most people are surprised by, so it is worth being precise about what it means. The UI is not generated from the model and then handed over to be maintained separately. The model is the running UI logic: which container is active, which action is available, what happens when it fires. A screen is a state, a click is a transition, and a form submission is a transition whose firing starts a business process.
How a click becomes a process instance
An IFML action carries a backend reference: a short string of
the form protocol:identifier. When the action's transition fires,
the engine splits the reference and dispatches accordingly.
| Reference | Dispatches to | Example |
|---|---|---|
bpmn:<id> | Start a BPMN process instance | bpmn:loan_approval |
cmmn:<id> | Open a CMMN case | cmmn:fraud_investigation |
dmn:<id> | Evaluate a decision, return the result inline | dmn:credit_policy |
direct:<h> | Invoke a registered handler | direct:notify_user |
The UI net and the process net then run concurrently, and the interesting detail is what the UI waits for. The token representing the user does not advance to the confirmation screen when the click is handled; it advances when the process instance has actually been created. The screen cannot say "submitted" unless something was submitted. That is the kind of correctness that is tedious to maintain by hand in a front end and free when both sides are states in a net.
bpmn:loan_approval is the entire contract between the UI model
and the process model. Redesign the screens without touching the process;
reorganise the process without touching the screens. The two evolve on their
own schedules, which is how they evolve in real organisations anyway - the
front end team and the process owners are rarely the same people, and rarely
ship on the same day.
8. Technology: infrastructure in the same language
The Technology layer describes infrastructure using the same structural vocabulary as everything above it: nodes, technology services, interfaces and processes, each compiling to a fragment that models how messages enter and leave.
A technology interface is the natural declaration point for an integration endpoint: the inbound interface becomes the entry state, the outbound interface the exit. The chain from business vocabulary down to a wire is then a single readable path.
Modelling infrastructure in the same language as strategy sounds like over-engineering until the first time somebody asks which business goals are affected by decommissioning a node. In two disconnected tools that question takes a week. In one model it is a traversal.
9. Migration: roadmaps you can simulate
The Migration layer models the transition between architecture states. In most EA tools it is purely documentary - a Gantt chart bolted to the side of a model that has no notion of time.
A Plateau is a named architecture state: As-Is, To-Be, and whatever intermediate states you commit to. A Work Package is the work that moves you from one to the next, and it compiles to a timed transition with a completion state. Which means a transformation roadmap is a net, and a net can be simulated.
10. The vertical spine, end to end
ArchiMate defines realisation relationships between layers: business realises motivation, application realises business, technology realises application. Priostack expresses those as identifier references and traces them at compilation time to assemble the complete execution net.
Read the diagram twice: once downwards as realisation, and once upwards as justification. Downwards it says how intent becomes infrastructure. Upwards it answers the question every architecture review actually asks and rarely gets a straight answer to - why does this node exist? - by walking the same references in reverse until it reaches a driver.
11. Data objects and the structural audit trail
A Data Object in the Application layer represents a data entity managed by software. It is the structural counterpart of the live data items that flow through execution, and the link between them is the same URI indirection used everywhere else.
Each live data item carries its own execution history: the trajectory through geometric memory described in the first article of this series. Every time the engine advances a step, the item records where that step landed. The full history travels with the data.
Why this matters for compliance
In banking, insurance and healthcare, every state transition has to be auditable. The conventional approach writes audit events to a separate table from application code - which means the audit trail is only as complete as the code paths that remember to write to it, and a bug in the writing path is invisible precisely when it matters.
Here the audit trail is structural. It is produced by the engine as a consequence of execution, carried in the data item itself, and linked back to the business concept that defined it. There is no separate writing path, so there is no separate writing path to bypass. That is the same argument as the Constraint inhibitor in section 3, applied to evidence rather than to control: the guarantee comes from the shape of the system rather than from everyone remembering the rule.
One honest limit, carried over from the first article: the memory that holds those trajectories has a finite configured capacity, and when it is full a step executes normally but leaves no trace. Business execution is unaffected; the record is not. Any deployment relying on this for compliance has to monitor the health of that memory as a first-class signal.
Conclusion
The gap between an architecture model and a running system exists because they are two artefacts with nothing forcing them to agree. Four decisions close it:
- One type per ArchiMate concept, each compiling to executable semantics. The model is the specification execution is built from, not a description of it written afterwards.
- A strictly one-way dependency graph. The enterprise model depends on nothing and everything depends on it; layers bind by identifier rather than by type. That is what makes the model independently testable and independently versionable.
- IFML as the bridge between interface and process. A UI model compiles to a net whose transitions start processes, open cases or evaluate decisions through a backend reference string - the only coupling between the two, so each side evolves on its own schedule.
- Structural guarantees rather than checked rules. A constraint that compiles to an inhibitor cannot be bypassed by a code path, because there is no path. An audit trail produced by the engine cannot be skipped by a handler that forgot to log.
Start with the agentic credit tutorial for the decision, process and case APIs behind the example, then read Geometric Memory and Process Trajectories for what execution history is actually measured against, and EIP Pipelines for the integration topology that carries messages between the layers.