Within each ArchiMate layer, elements are classified along three aspects: active structure, behavior, and passive structure. What does each aspect capture, and how would you classify 'application component', 'application function', and 'data object' using this framework?

## The 3x3 core framework ArchiMate's core is often visualized as a **3x3 grid**: three layers (business, application, technology) crossed with three structural aspects (active structure, behavior, passive structure). The layers were covered separately; this aspect dimension is orthogonal to them and repeats identically inside each layer, which is one of the language's more elegant design decisions because it means once you learn the pattern in one layer, you already know it in the other two. ## Active structure — the subjects **Active structure** elements are the 'subjects' of the model - the things capable of performing behavior: - in the **business layer** this is business actors (a person or organizational unit) and business roles (the responsibility an actor takes on) - in the **application layer** it's application components (deployable, executable software units, e.g. a 'Payments Service' microservice) and application collaborations - in the **technology layer** it's nodes, devices, and system software (e.g. a Kubernetes cluster or a database engine) Active structure elements are linked to the behavior they perform via an `assignment` relationship - a business role is assigned to a business process, an application component is assigned to an application function. ## Behavior — the verbs **Behavior** elements are the 'verbs' - what active structure elements actually do. This includes: - **processes** (ordered activity with a clear start/end, e.g. 'Handle Insurance Claim') - **functions** (grouped activity by required skill/resource, without inherent sequencing, e.g. 'Claims Validation') - **interactions** (collaborative behavior between two active structure elements) - **events** (something that happens instantaneously and can trigger behavior) - **services** (externally visible, meaningful behavior offered to an environment, e.g. 'Claim Validation Service') Services are the most important behavior element for cross-layer and cross-organization communication because they are deliberately implementation-agnostic - a consumer of a service doesn't need to know which component or which role realizes it. ## Passive structure — the objects **Passive structure** elements are the 'objects' - things behavior acts upon but which cannot themselves act: - **business layer**: business objects (e.g. 'Insurance Claim' as a concept) - **application layer**: data objects (the software representation, e.g. a 'Claim' record with fields) - **technology layer**: artifacts (deployable/storable pieces like a config file, a container image, or a database table) A data object never 'does' anything in the model - if you find yourself wanting to draw an arrow originating from a data object representing an action, that's a signal you've picked the wrong element type; you likely need a function or process instead, with an `access` relationship connecting it to the data object it reads or writes. ## Why the split exists Why this three-way split exists: many earlier and competing notations blur these categories - UML class diagrams, for instance, let a class have both data (attributes) and behavior (methods) in a single box, which is appropriate for object-oriented code but awkward for enterprise-level modeling where you often want to reason about behavior and the data it touches as separately governed concerns. Separating active structure, behavior, and passive structure lets ArchiMate express relationships like `assignment` (actor performs behavior), `access` (behavior reads/writes data, further qualified as read/write/read-write), and `realization` (a more concrete element implements a more abstract one) with precise, unambiguous semantics, which is what makes automated model analysis reliable. ## The trade-off The trade-off is that this rigor requires discipline in classification, and many practitioners new to ArchiMate misclassify elements, especially: - around **functions versus processes** (functions are non-sequential groupings by capability, processes are sequenced with clear triggers - conflating them makes traceability queries in tooling return incomplete or duplicate results) - around whether something is a **service versus a function** Getting this wrong doesn't break the diagram visually, but it silently degrades the model's analytical value: automated queries like 'what serves this business process' or 'what data does this function access' return wrong or incomplete answers precisely when they were needed for a real decision. ## A common failure mode A common failure mode in production enterprise-architecture practice: modelers under time pressure draw everything as a generic box with a label and skip picking the correct ArchiMate element type, which produces diagrams that look plausible to a human reader but cannot be reliably queried by tooling, and worse, mislead automated conformance checks such as a GDPR-driven audit tool walking access relationships from data objects tagged as containing personal data. ## Where the classification pays off A concrete real-world usage: a telecom operator building a data-lineage view for regulatory reporting models each data object (e.g. 'Customer Billing Record') and traces every `access` relationship from application functions across dozens of billing, CRM, and analytics systems, producing an accurate answer to 'which of our 40 systems touch billing PII' that would otherwise require weeks of manual system-owner interviews - this only works because access relationships were modeled with the correct read/write qualifier from the start.