Business, Application, Technology: Reading an ArchiMate Layered View

Most people look at a layered ArchiMate view the way they look at an org chart: business on top, technology on the bottom, and a vague sense that the top somehow explains the bottom. That's not wrong exactly, but it's not reading the view — it's glancing at it. Reading a layered view is a specific skill with specific rules, and most of the value in the picture sits in the handful of lines that cross between layers, not in the layers themselves.

This matters because the layered view is usually the first thing a stakeholder sees, and often the only thing they remember. A steering committee doesn't read your application inventory or your technology roadmap in detail. They see one slide with three bands and some boxes, and they draw conclusions from it — correct or not. If you can't read the view precisely yourself, you can't control what conclusion someone else draws from it.

What the three layers actually represent

ArchiMate's core layers — Business, Application, Technology — are not organizational boundaries, and they're not a stack in the sense a network engineer means "stack." They're three different levels of abstraction over what is, structurally, the same system.

• Business layer — what the organization does and offers: processes, services, actors, roles, business objects. Behavior and structure described in terms a non-technical stakeholder recognizes without translation.
• Application layer — the software that supports that behavior: application components, application services, data objects. Still fairly abstract — an application service like "Permit Issuance API" describes a capability, not a deployment.
• Technology layer — the infrastructure the application layer runs on: nodes, devices, system software, technology services, artifacts. Here the model finally touches something physical or virtual that a systems administrator would recognize on sight.

The stacking order — business above application above technology, in the standard notation — is a convention, not a hierarchy of importance and not a flow of control. Nothing in ArchiMate says business elements "manage" application elements the way a manager sits above a report on an org chart. What the vertical position actually encodes is level of abstraction: business layer elements describe what happens in terms a customer or case worker would recognize; technology layer elements describe what happens in terms a server would recognize. The same reality, described at three different altitudes.

The part that actually carries the information: crossing relationships

A layered view where nothing crosses a layer boundary isn't an architecture view — it's three separate diagrams that happen to share a canvas. The entire point of drawing business, application, and technology on one page is to show how they connect, and in ArchiMate that connection is made almost exclusively by two relationship types: serving and realization.

Serving: "I make this available to you"

A serving relationship says that one element makes its functionality available to another. It's drawn as a solid line with an open arrowhead, and the arrow points from the element doing the serving to the element being served. Crucially, serving very often points upward across layers: an application service serves a business process, a technology service serves an application component. The lower, more concrete layer is providing something the layer above consumes.

Realization: "I am the concrete form of that abstract thing"

A realization relationship says that a more concrete element implements or embodies a more abstract one. It's drawn as a dashed line with a hollow triangular arrowhead, again typically pointing from the concrete element to the abstract one it realizes: an application component realizes an application service, a business process realizes a business service, an artifact realizes a technology service.

Put those two together and a layered view tells a specific, readable story: a business process isn't realized by anything below it on its own — it's carried out by people and systems — but it can be served by an application service, which is itself realized by an application component, which is served by a technology service, which is realized by a piece of infrastructure. Follow that chain from bottom to top and you have gone from a physical server to a business outcome. Follow it top to bottom and you've answered "what actually runs this."

Notice what's missing from that description: nothing about data flowing downward, nothing about control passing from business to IT. The arrows in a layered view mostly point up, because serving and realization both describe provision — something lower or more concrete provides something to something higher or more abstract. That single fact trips up more newcomers than anything else in the notation, so it's worth its own section.

The misreadings that show up again and again

Misreading 1: assuming the arrow shows the direction of "flow"

Most people's prior experience with arrows in diagrams is control flow or data flow — a flowchart, a sequence diagram, a network diagram — where the arrow points where something is going. A serving relationship arrow does not mean that. "Application Service serves Business Process," drawn with the arrowhead on the business-process end, does not mean data flows from the application to the business, or that the application "controls" the process. It means the application service is available for the process to use. Mentally read every crossing arrow as "flow" and you will consistently get the direction of dependency backwards — and backwards in the direction that matters, because it changes who depends on whom.

Misreading 2: treating layers as ownership boundaries

It's tempting to read "business layer" as "the business team's stuff" and "technology layer" as "IT's stuff," with the line between them as an organizational handoff point. ArchiMate layers aren't org boundaries; they're abstraction levels of the same system. A business process and the technology node that ultimately runs it are two descriptions of the same underlying reality at different resolutions, not two things owned by two different departments that happen to be stacked on a page. Reading layers as org boundaries leads to a specific bad habit: treating a missing cross-layer relationship as "not our problem to draw" rather than as a real gap in the architecture.

Misreading 3: expecting a clean one-to-one stack

A newcomer's mental model is often one box per layer stacked directly on top of each other — one process, one service, one component, one server, four boxes in a vertical line. Real systems rarely look like that. One application service commonly serves several business processes. One business process commonly needs several application services working together. One application component is commonly deployed across several technology nodes for resilience, and one node commonly hosts several components. A layered view with a clean vertical stack for every element is either a toy example or a system that hasn't been modelled in enough detail yet to show its real fan-out.

Misreading 4: reading a gap in the picture as a gap in reality, or vice versa

If a business process has no line running down into the application layer, there are two very different explanations, and the view alone doesn't tell you which one is true. Either the process genuinely has no application support — it's done on paper, by phone, in someone's head — or the process does have application support, but whoever drew this particular view chose not to include it because it wasn't relevant to the point being made. A landscape view scoped to "customer-facing services" will legitimately omit half the application layer without that being a gap in the architecture — only a gap in this view. Confusing "not shown here" with "doesn't exist" is one of the most common and most consequential misreadings, and it's exactly the ambiguity a hand-drawn diagram can't resolve on its own — you have to know, or check, whether the underlying model actually has nothing there, or whether the view simply didn't ask for it.

Using the view to answer real questions

The reason this skill is worth building deliberately is that a layered view, read correctly, answers two questions that come up constantly in real architecture work — and answers them badly, or not at all, if read the way most newcomers read it.

"Does this business capability actually have technology support?"

Start at the business process or business service in question and trace downward through every serving and realization relationship attached to it. Three outcomes are possible, and they mean different things:

1. The chain reaches the technology layer cleanly. A business process is served by an application service, realized by a component, served in turn by a node. The capability is supported end to end, and you can name the server it depends on.
2. The chain stops at the application layer. There's a service and a component, but nothing in the technology layer serves that component. Either the deployment genuinely hasn't been modelled — a common gap when application inventories are maintained separately from infrastructure inventories — or, less comfortably, the component is running on infrastructure nobody documented, which is its own finding.
3. The chain doesn't leave the business layer at all. No application service serves the process. That's not a modelling oversight to shrug off — it's the honest answer to "is this capability automated," and it's often the most useful thing the view tells anyone. A "digital-first" strategy slide sitting next to a layered view showing three manual, unsupported processes is a conversation worth having before the slide goes to the steering committee.

This is where a model-native tool changes what the question costs to answer. In a hand-drawn diagram, tracing that chain means opening the right view, hoping every relevant relationship was drawn on it, and following lines by eye. In Mooodels, where business processes, application services, and technology nodes are elements in one model rather than shapes on independent pictures, the same question is a downstream traversal from a single element — and because the model has stable IDs rather than relying on shapes matching by label, the traversal is exhaustive with respect to whatever has actually been modelled, not with respect to whatever one particular view happened to include.

"What's the business justification for this piece of infrastructure?"

This is the same traversal run in reverse, and it's the question that comes up every time an infrastructure renewal, a cloud migration, or a cost review lands on someone's desk. Start at a technology node — a server, a database instance, a message queue — and trace upward: what does it serve, what does that realize, what business service or process sits at the top of the chain?

Three outcomes again, and they're the mirror image of the ones above:

• A clean upward chain to a named business process is the best possible answer to a budget reviewer asking "why do we still pay for this." You can point at the exact capability that breaks if the server is decommissioned.
• An upward chain that stops at the application layer — the node serves a component, but nothing traces that component further up — usually means the business-layer modelling hasn't caught up with the application inventory, not that the component is unjustified. Worth fixing, not worth panicking over.
• No upward chain at all is the finding infrastructure reviews exist to surface: a node with nothing above it in the model is either genuinely orphaned — a leftover from a decommissioned system that was never cleaned up — or it's running something real that was simply never modelled. Either way, it's the item that goes on the list before the next renewal decision, not after.

Put those two questions together and a layered view stops being a picture shown to a steering committee once and becomes a working diagnostic: coverage in one direction, justification in the other, both running over the same set of crossing relationships.

A worked example, end to end

Take a small permit-issuance case, described the way it would actually be modelled rather than the way it would be sketched on a whiteboard. The application layer holds two elements: PermitAPI, an application service exposing permit operations, and PermitApp, the component that realizes it. PermitApp also reads and writes a database, PermitDB, over JDBC. The technology layer holds the node PermitApp is deployed on, and the hosting platform that serves that node. Four elements and three crossing relationships, each one recorded as a separate, checkable fact rather than implied by how close two boxes happen to sit on a canvas — and the landscape view is simply a request to show all of them at once.

Layer that against a business layer with a process called "Issue Permit," served by PermitAPI, and the chain reads cleanly top to bottom: Issue Permit is served by PermitAPI, which is realized by PermitApp, which reads and writes PermitDB and is deployed on a node that is in turn served by the organization's standard hosting platform. Every hop is a real, separately checkable relationship, not an assumption bridging a gap in the picture.

Now suppose someone adds a second business process, "Appeal Permit Decision," to the model, but nobody gets around to modelling what application service supports it. Read naively, the layered view still looks fine — it has boxes in all three layers, arrows crossing between them, nothing visually wrong. Read correctly, with the specific question "does every business process have a downward chain to technology," the gap is immediately visible: one process has no application service serving it. That's not a drawing problem. That's either an undocumented manual process or a capability quietly running on a spreadsheet, and it's exactly the kind of finding a rule can check for automatically — every business process must be served, directly or transitively, by at least one application service — rather than relying on a reviewer to spot a missing line among dozens of others on a busy diagram.

The rest of the cross-layer vocabulary

Serving and realization carry most of the traceability story, but a layered view occasionally uses two more relationship types across layers, and confusing them with serving or realization is its own small misreading worth heading off.

Assignment is the one that most often gets mistaken for serving. "PermitApp is assigned to permit-prod-01" describes deployment — this component's runtime lives on this node — while "permit-prod-01 serves PermitApp" describes provision — the node makes its capacity available for the component to use. In practice both relationships often appear on the same pair of elements, and that's correct: a component is deployed on a node and the node serves it. Reading only one of the two can make a technology dependency look thinner than it is.

Reading fan-out: when one service supports many processes

The clean four-box chain used earlier — one process, one service, one component, one node — is the easy case. The harder, more common case is fan-out: a single application service sitting underneath several business processes at once, or a single node quietly hosting most of an organization's application layer. Reading fan-out correctly matters because it changes what a change to that one element actually costs.

Say PermitAPI, in the earlier example, doesn't just serve "Issue Permit." It also serves "Renew Permit" and "Appeal Permit Decision," because all three processes were built against the same API rather than three separate ones. Drawn on a single layered view, that's three arrows converging on one application-layer box from three business-layer boxes above it. Read at a glance, it looks like good reuse — one service, three capabilities supported, less to maintain. Read as an impact question — "what happens if PermitAPI has an incident, or needs a breaking change" — the same picture says something less comfortable: three business processes go down together, not one. Fan-out is simultaneously the strongest argument for consolidating application services and the strongest argument for treating the ones you do consolidate as more critical than their individual boxes suggest.

The same reading applies one layer down. A single node hosting a dozen application components is efficient until it's the node in an incident review, at which point the fan-out that looked like tidy infrastructure consolidation is the reason a hardware fault took out a dozen unrelated capabilities at once. Neither pattern is wrong on its own — consolidation is often the right call — but reading a layered view without noticing where the fan-out sits means missing exactly the information a resilience or change-impact conversation needs. In a hand-drawn view this means visually counting how many lines converge on a box, which stops being practical past a handful of elements; a model-native tool answers "how many business processes ultimately depend on this node" as a graph query with an exact count, regardless of how many hops separate them.

What a layered view leaves out, on purpose

A well-read layered view also tells you what it isn't claiming. It says nothing about timing — a serving relationship doesn't mean synchronous, real-time, or even automated; a business process can be "served" by an application that generates a nightly batch file someone acts on the next morning. It says nothing about volume, criticality, or cost — a technology node serving three sleepy internal tools and a node serving the organization's highest-traffic public service can look identical in a layered view unless someone has deliberately added that context through properties or a separate view. And it says nothing about sequencing between elements at the same layer — a layered view is not a process flow, and reading left-to-right positioning within a layer as "step one, step two" is another common misreading, distinct from the vertical ones above, because ArchiMate has dedicated notation for sequence (flow relationships, process diagrams) that a layered landscape view usually isn't drawn to show.

Knowing what the view doesn't claim is as much a part of reading it correctly as knowing what it does. A reviewer who treats the absence of a criticality marker as "this must be low priority," or the absence of a flow relationship as "these things happen simultaneously," is extrapolating past what the notation actually asserts.

Why the skill compounds

None of this replaces domain knowledge — you still need to know what "Issue Permit" involves and why the organization cares about it. What the skill of reading a layered view correctly does is stop you from either overtrusting or undertrusting the picture. Overtrusting it means assuming every relevant dependency is drawn, and missing the manual process or the undocumented server because the picture looked complete. Undertrusting it means falling back to asking people instead of checking the model, which is slower and less reliable than either extreme suggests, given how quickly people's memory of "what depends on what" goes stale.

It also changes how you build the view in the first place. Once you know that the crossing relationships are the payload and the layer bands are just scaffolding, you stop drawing layered views to look complete and start drawing them to answer a specific question — "show me every business process without downstream application support," or "show me every technology node with no upward path to a business service." Those aren't different diagrams in Mooodels; they're the same model, filtered differently, because the relationships that make the traceability story work are the same relationships the graph traversal uses to answer the question directly, without anyone needing to squint at a picture first.

The layered view earns its place as the default way ArchiMate presents an architecture because, read correctly, it answers the two questions every stakeholder eventually asks in one shape: does the business capability I care about actually work, and can I justify what I'm paying to run it. Everything else in the notation — the exact shape of the boxes, the icon inside them, the color coding a particular organization has adopted — is secondary to being able to follow a serving relationship and a realization relationship correctly, in the right direction, across all three layers, and to know the difference between a line that's missing because there's nothing there and a line that's missing because this particular view simply didn't ask for it.