ArchiMate models are organized into three core layers: business, application, and technology. In plain terms, what does each layer represent, and how do they typically connect to each other in a single architecture model?
answer
- business-app-tech stack
- layers = provider to layer above
- serving relationship crosses layers
- abstraction not org chart
basics
~20 sBusiness layer = what the company does for customers (processes, services). Application layer = the software that supports those processes. Technology layer = the infrastructure (servers, networks) that runs the software. Higher layers use services from the layer below.
solid answer
~30 sArchiMate's core has three layers stacked by abstraction: Business (actors, processes, services delivered to customers/stakeholders), Application (software components, application services, and data objects that automate business processes), and Technology (infrastructure - nodes, devices, networks, system software - that runs the applications). Each layer is a service provider to the layer above: technology services support application components, application services support business processes. This layering lets you trace a customer-facing business service down to the exact servers that host it, which is the core value of the framework - end-to-end traceability across abstraction levels.
go deeper
Can name the three layers and give one example element from each (e.g. business process, application component, technology node) without needing to know exact relationship names.
Explains that each layer is a service consumer of the layer below via the 'serving' relationship and can sketch a simple three-layer trace for a real system they've worked on.
Uses the layering to reason about change impact - given a proposed infrastructure change, walks the model layers to identify affected business services, and can spot when a diagram's cross-layer links are missing or wrong.
Sets modeling-depth policy for the organization - decides which layers/granularity are worth maintaining given team capacity, and designs governance so the model doesn't silently drift out of sync with reality.
## The organizing idea ArchiMate's central organizing idea is a **three-layer stack**, each layer describing the enterprise at a different level of abstraction, with a consistent pattern of behavior, active structure, and passive structure repeated inside each layer. ## The Business layer The Business layer sits at the top and describes the enterprise as it appears to customers, partners, and other external stakeholders: - **business actors and roles** (who does the work) - **business processes and functions** (what gets done) - **business services** (the value delivered, e.g. 'process a claim') - **business objects** (the information handled, e.g. 'claim') - **business interfaces/collaborations** (how actors interact) This layer is technology-agnostic - a claims-handling business service exists whether it is fulfilled by a clerk with a paper form or a fully automated system. ## The Application layer The Application layer sits in the middle and describes the software landscape that automates business processes: - **application components** (deployable software units) - **application services** (what a component offers, e.g. 'validate policy number') - **application functions/interactions** - **data objects** (the software-level representation of business objects) Application services are consumed by business processes, which is modeled with a `serving` relationship - the application layer exists to serve the business layer, not the other way around. ## The Technology layer The Technology layer sits at the bottom and describes the infrastructure that runs the software: nodes, devices, system software, networks, and technology services (e.g. 'provide compute', 'provide messaging'). Application components are assigned to technology nodes and use technology services, again via `serving` and `assignment` relationships. ## Why the stack exists Before ArchiMate, organizations typically had separate, disconnected artifacts: - business process maps (e.g. BPMN diagrams owned by business analysts) - software architecture diagrams (owned by application architects, often UML) - infrastructure diagrams (owned by ops/infra teams, often Visio network diagrams) These lived in different tools, different notations, and different teams' heads, so nobody could answer 'if this server goes down, which customer-facing services are affected?' without a manual, error-prone investigation. ArchiMate's layering with a shared relationship vocabulary (serving, realization, assignment, access, triggering, flow) makes that traceability a queryable model property rather than tribal knowledge. ## The trade-off The trade-off is **modeling overhead versus traceability value**. Maintaining a layered model that stays accurate requires discipline: someone must keep the business-to-application-to-technology chain updated whenever any layer changes, which is real ongoing cost. - Teams that adopt ArchiMate but only model one layer (commonly, only technology, because it's the easiest to inventory from CMDB data) get a nice-looking diagram with none of the cross-layer traceability that justified the investment - they end up with an expensive technology inventory tool. - Conversely, teams that try to model at very fine granularity in all three layers for a large enterprise create a model that is enormous, quickly stale, and nobody trusts, because updating it requires cross-team coordination that never quite happens. ## Failure modes A failure mode that shows up repeatedly in production enterprise-architecture practice: architects draw all three layers on one big diagram to look complete, but the arrows between layers are missing or drawn incorrectly (e.g. business process 'assigned to' application component instead of 'served by' an application service), so the diagram looks impressive in a slide deck but cannot actually answer impact-analysis questions - clicking through the relationships in the modeling tool dead-ends. Another common failure is **layer confusion**: putting a role like 'Claims Adjuster' in the application layer because 'that's the user of the app', when roles belong in the business layer and only the software they operate belongs in application. ## Where the layering pays off A concrete real-world usage: a bank doing an infrastructure migration (e.g. moving from on-premises data centers to a cloud provider) uses the layered model to run impact analysis: 1. starting from the technology nodes being decommissioned, 2. tracing `assignment` relationships up to the application components hosted on them, 3. then `serving` relationships up to the business services those components support, 4. producing an accurate list of which customer-facing capabilities (e.g. 'online mortgage application') are at risk during the cutover window, without anyone having to manually cross-reference three separate spreadsheets.
- If a business process depends on an application component that is being decommissioned, which ArchiMate relationship would you traverse to find that dependency in the model?You'd trace the 'serving' relationship from the application service (realized by that component) up to the business process, and the 'realization' relationship from the component to the service it provides. In practice you follow component -> realizes -> application service -> serves -> business process, which is exactly the chain impact-analysis queries in ArchiMate tooling walk.
- Why might a team model only the technology layer and call it 'enterprise architecture'?Technology inventories are the easiest to populate because CMDBs and asset-management tools already hold server, network, and software-version data, so it's low-effort compared to interviewing business stakeholders for process and service definitions. The result is a detailed infrastructure map with no link to business value, so it can't answer 'what does the business lose if this fails' - which is the question executive stakeholders actually ask.
- How does the application layer's 'application service' element differ from an 'application component'?A component is the deployable software unit (e.g. a microservice or a legacy monolith module) - it's a piece of structure. A service is the externally visible behavior that component offers to consumers, decoupled from implementation, so the business process depends on 'validate policy number' as a capability rather than on a specific component, letting you swap the underlying component without touching the business-layer model.
Think of a restaurant: the business layer is the menu and the dining experience customers pay for, the application layer is the kitchen recipes and prep workflow that produce the dishes, and the technology layer is the ovens, fridges, and gas lines the kitchen runs on - each layer serves the one above it.
saying these in an interview costs you the question
- Puts organizational roles or people directly in the application layer
- Draws layers with no serving/realization arrows between them, just visual stacking
- Treats the technology layer inventory alone as a complete enterprise architecture
- Cannot explain which relationship connects a business service to the application service that realizes it