Motivation layer¶
Before a single business process, application, or server is drawn, an EA practice has to be able to answer why. ArchiMate gives that "why" its own layer — Motivation — with a small, precise vocabulary for the stakeholders, pressures, judgements, aims, and rules that justify every later box. It is the layer that keeps architecture honest: every capability, service, and node you model downstream should trace back to something up here, or it has no business existing.
This page walks the Motivation elements one by one, each shown applied to Cadence Cycles and its omnichannel push, then assembles them into a single Motivation view.
What the Motivation layer captures
- Who the architecture is for — stakeholders and their concerns.
- What is pushing change — drivers and the assessments that analyse them.
- What "better" means — goals and the measurable outcomes that prove them.
- The rules and the asks — principles, requirements, and the constraints that bound the solution.
These aren't decoration. In the TOGAF ADM they are the raw material of the Preliminary phase (principles), Phase A (vision, stakeholders, goals), and Requirements Management (running throughout).
Stakeholders and drivers — the pressure¶
A stakeholder is the role of an individual, team, or organisation that has an interest in the architecture's outcome. Stakeholders are why anyone cares; their concerns (cost, growth, risk, experience) are what the architecture must speak to. For Cadence Cycles the cast is small but has real tension in it: the Board and CFO want margin and growth; the VP Retail owns a store estate under pressure; the VP Ecommerce is chartered to grow a young online channel; the Head of Ops lives with the inventory mess; and the Customer — modelled explicitly, because omnichannel is ultimately their convenience — is a stakeholder too.
A driver is a condition, internal or external, that motivates the organisation to change. Drivers are the forces, stated neutrally — not problems to solve yet, just facts that create pressure. Cadence has three: declining store foot-traffic, online competition from direct-to-consumer brands, and margin pressure. A driver on its own doesn't tell you what to do; it tells you where to look.
Assessments — the analysis¶
An assessment is the result of analysing one or more drivers — the architect's SWOT-style judgement about what a driver means for this organisation. This is the step teams skip, and it is where architecture earns its keep: the same driver can lead two companies to opposite conclusions. Cadence records two findings. "Stores strong on fitting/service, weak online" turns the foot-traffic and competition drivers into a nuanced position — the stores are an asset, not a liability, if the online experience catches up. "No single view of inventory" names the internal weakness behind the margin pressure: you cannot sell or fulfil efficiently across channels if no system knows what stock exists where.
Goals and outcomes — the ends¶
A goal is a high-level statement of intent or desired end state — qualitative and directional. An outcome is the tangible, measurable end result that signals a goal is being met. The distinction matters: goals set direction, outcomes let you know you have arrived. Cadence's assessments motivate three goals — grow D2C online revenue to 30%, unify inventory, and improve customer lifetime value — and one outcome that ties them together: omnichannel customers spend more. If that outcome shows up in the numbers, the CLV goal is real; if it doesn't, the strategy is a slogan.
Principles, requirements, and constraints — the rules and the asks¶
- A principle is a qualitative, enduring rule that any solution should honour — normative guidance that outlives a single project. Cadence adopts two: single source of truth for inventory and buy-anywhere / fulfil-anywhere. Principles don't say what to build; they say what good looks like so that a hundred later decisions don't have to be re-argued.
- A requirement is a statement of need the architecture must satisfy — the concrete "must" that a solution is checked against. Cadence's principles and goals crystallise into three: real-time inventory visibility, online order → store fulfilment (BOPIS), and a unified customer profile.
- A constraint is a requirement that restricts the solution space — a boundary rather than a need. Cadence sets one that shapes the whole programme: ERP replacement is out of scope this cycle. That single constraint is why the later architecture layers a new inventory service over the incumbent ERP rather than ripping it out.
The Cadence Cycles motivation model¶
Put the elements together and the "why" becomes a traceable chain rather than a slide of bullet points. Read this view left to right: stakeholders sit behind the drivers that concern them; assessments analyse those drivers; the findings influence goals; requirements (shaped by principles, bounded by the constraint) realise those goals; and an outcome evidences one of them.
The Cadence Cycles Motivation view — an authentic Archi export. Purple is the Motivation layer; the small glyph top-right names the element type (steering-wheel = driver, magnifier = assessment, target = goal/outcome). Plain lines are associations (a stakeholder's concern, an assessment of a driver); dashed arrows marked +/− are influence relationships (an assessment pushes a goal; a principle strengthens, a constraint weighs against, a requirement); dashed hollow-triangle arrows marked realises are realisation (a requirement, or the outcome, realises a goal).
The three relationship types are the grammar of the Motivation layer, and each says something different:
| Relationship | Notation | Reads as | Example here |
|---|---|---|---|
| Association | plain line | "is concerned with / analyses" | Board — Margin pressure; assessment — driver |
| Influence | dashed arrow, +/− |
"affects (positively/negatively)" | No single view of inventory + Unify inventory; ERP out of scope − Real-time inventory visibility |
| Realisation | dashed hollow-triangle arrow | "makes true / satisfies" | Real-time inventory visibility realises Unify inventory |
Influence is weighted on purpose
ArchiMate's influence relationship can carry a sign (and even a strength). Modelling ERP replacement out of scope as a negative influence on real-time inventory visibility captures something a plain arrow can't: the constraint doesn't forbid the requirement, it makes it harder — you must achieve real-time visibility without touching the ERP. That nuance is exactly the kind of decision the architecture then has to design around.
So what — which decision this drives
The Motivation model is the contract for everything downstream. Those three requirements — real-time inventory, BOPIS, unified customer profile — are what the Strategy capabilities must be able to satisfy and what the Business, Application, and Technology layers must ultimately implement. Because the links are explicit, you can later ask the model a hard governance question — "which stakeholder concern does this new service actually serve, and which requirement does it realise?" — and get an answer instead of an opinion. Anything that can't trace back up to this layer is a candidate to cut.
Where to go next¶
- Strategy — turn these goals and requirements into capabilities, the resources behind them, and the courses of action that configure them: the section's marquee capability map.
- TOGAF & the ADM — where the Motivation elements land in the method: principles in Preliminary, stakeholders and goals in Phase A, requirements in Requirements Management.