ArchiMate Active Structure vs Passive Structure vs Behavior:

⏱ 24 min read

I have seen architecture reviews that should have wrapped in five minutes drift into forty-minute arguments over a single diagram.

One team insists CRM is “the process.” Another places customer data in the same kind of box as an application component. A third draws APIs, services, processes, records, and events as though they are all just interchangeable architecture nouns. Then governance gets bogged down debating notation while the actual questions sit there unanswered: who owns the control, what changed, where is the evidence, and what breaks if we move this integration point?

In telecom, and especially in regulated telecom, that is not a harmless modeling quirk.

If you cannot separate the thing that performs, the thing that happens, and the thing being handled, you will eventually create trouble for yourself. Sometimes it shows up as a porting incident nobody can trace cleanly. Sometimes it appears in an audit of customer identity verification. Sometimes it comes out in a resilience review asking which node actually hosts a regulated function, or in a lawful intercept discussion where evidence is required and the repository contains only vague boxes with optimistic labels.

I have watched repositories lose credibility this way. People stop trusting them for decisions. Delivery teams start treating them as wallpaper. Governance boards end up arguing over shape semantics because the models no longer expose responsibility or risk clearly enough to argue about anything more useful.

So this article is not about passing an ArchiMate notation exam. It is about building a practical mental model you can use under delivery pressure, in architecture boards, in audit conversations, and in that awkward middle ground where all three collide. ArchiMate training

The short version is this:

• Active structure = the thing that does
• Behavior = what it does
• Passive structure = the thing that is used, produced, moved, or changed

That sounds almost too simple. Good. In my experience, it should.

And yet teams still get this wrong all the time.

Take a basic telecom example:

• the billing platform team or billing application component is active structure
• the rating transaction or calculate charge function is behavior
• the call detail record is passive structure

That distinction matters because different questions attach to each one.

If I ask who is accountable, I am asking about active structure. If I ask what action is controlled or triggered, I am asking about behavior. If I ask what data must be retained for seven years, or what payload crossed an organizational boundary, I am asking about passive structure.

A lot of the confusion starts with naming. Systems get named after activities. Data products blur into services. “Customer onboarding” might refer to a business process, a digital journey, a squad, a microservice domain, or a reporting dashboard depending on who is speaking and, frankly, how tired everyone is. Service names are especially slippery because people use “service” to mean business offering, application API, platform team, or SaaS product in the same meeting.

Still, there is a useful first-pass test.

If the noun sounds like a team, system, role, node, or interface, it is often active structure.

If it sounds like an action, operation, process, function, or event, it is probably behavior.

If it sounds like a record, dataset, document, message, state, or business object, it is usually passive structure.

Usually, not always. Relationships decide the real meaning.

Start with the actor before the action

This is the first move I recommend in real modeling work, and it is one of the few habits that consistently improves the quality of architecture views.

Before drawing the process, identify who or what performs it.

That sounds obvious. It is not how many teams actually work. They start from a swimlane workshop, capture twenty-two process steps, and only later realize nobody can say which application component actually owns “validate porting exception” or which team is accountable for “confirm identity.” The model turns into process theater.

In practice, especially in enterprise architecture, starting with performers stabilizes the picture. Sparx EA guide

Take customer onboarding for mobile postpaid. Before drawing flow, identify the active structure:

• Sales agent as business role
• Customer identity verification service component or KYC component
• Order capture application component
• Credit decision engine
• Provisioning platform

Now the behavior has anchors. “SIM activation” is not a floating action in the air. It is behavior performed by a specific application component or collaboration. “Credit check” is not just a box with an arrow. It is behavior executed by a credit decision engine, perhaps exposed through a service.

When that performer cannot be identified, one of two things is usually happening. Either the model is too abstract to support real decisions, or your organization has an accountability gap that the model is politely hiding.

That is not a notation problem. That is exactly the kind of thing architecture is supposed to surface.

Active structure: the performers, owners, and containers

Active structure in ArchiMate is the set of elements that can perform behavior. ArchiMate modeling guide

In plain language, these are the actors, roles, applications, nodes, devices, interfaces, and collaborations that do things, expose things, host things, or are otherwise operationally responsible for action.

Across layers, that includes elements like:

• Business actor, business role, business collaboration
• Application component, application collaboration, application interface
• Node, device, system software, technology interface

In telecom, these become immediately familiar:

• Retail Sales Role
• Order Management Application Component
• Mediation Platform Node
• API Gateway Interface

What matters is not memorizing the catalog. What matters is using active structure to show accountability and control points.

That is where regulated firms get real value.

If separation of duties matters, model roles.

If controls depend on system boundaries, model application components.

If resilience, hosting jurisdiction, or operational ownership matters, model nodes.

One mistake I see constantly is treating architecture active structure as a prettified organization chart. It is not. HR reporting lines are not the point. “Director of Operations” is rarely useful in an enterprise architecture view unless it connects to an actual operating role or control boundary.

The opposite mistake is treating active structure as a deployment inventory. That is not much better. Not every Kubernetes node pool or VM cluster belongs in an enterprise view. Sometimes it does, especially in residency or resilience discussions. Often it does not.

Use the level that supports a decision.

Another recurring bad habit: modeling customer database as active structure when the real concern is the customer data object. Sometimes the database engine or managed service is relevant as active structure, especially for hosting, resilience, or access control. But often the architectural conversation is really about the information asset, system of record, or duplication problem. Teams pick the infrastructure-shaped box because it feels concrete, then accidentally hide the thing that matters.

And yes, “platform” is probably the most abused label in most repositories.

A box called Activation Platform tells me almost nothing. Is it an application component? A technology platform? A team? A vendor service? A collection of functions? A domain? If the word platform hides different owners, control points, or behaviors, decompose it.

A scenario we will keep using: number port-in and mobile service activation

Let me ground this in one scenario so the distinctions accumulate instead of resetting every section.

Use case: number port-in and mobile service activation.

It is ideal because it cuts across channels, operations, partner integration, customer data, IAM, notifications, network provisioning, and regulation. You get identity checks, order capture, donor network communication, provisioning, billing, and records retention in one coherent story.

Core elements:

Business actors / roles

• Customer
• Retail agent
• Porting operations team

Application components

• CRM
• Order management
• KYC service
• Provisioning engine
• Billing system
• Notification service

Technology

• Integration platform
• Network provisioning node
• Kafka event backbone
• IAM service

Passive structure

• Customer profile
• Porting request
• SIM status record
• Activation event
• Billing account
• Consent record

Behavior

• Validate identity
• Capture order
• Submit port request
• Activate service
• Generate welcome notification

We will keep revisiting this because it is much easier to see the differences when the business context stays constant.

Behavior: where diagrams often become misleading

Behavior is the dynamic part of the model: processes, functions, interactions, services, and events.

It answers one question above all others: what happens?

In ArchiMate terms, behavior includes internal actions like functions and processes, externally visible offerings like services, and time-based triggers or state changes like events. Even when drawn in a static diagram, behavior is about dynamics.

That distinction matters a lot in architecture reviews.

A business process might be handle number porting request.

An application function might be calculate tariff eligibility.

An application service might be customer identity verification service.

A technology process/function might be replicate configuration to network node.

An event might be SIM activated.

If active structure tells me who or what performs, behavior tells me what they do.

The common failure mode is a diagram full of application components and interfaces with arrows but no real behavior. It looks technical. It feels architecture-ish. It tells me almost nothing. I cannot see sequence, trigger, or outcome. I cannot tell whether an API is an externally offered service, an internal function call, or just a network path.

The other failure mode is the reverse: every API call becomes its own behavior element and the diagram loses all business narrative. Now the reader cannot see the activation journey because they are drowning in orchestration detail.

This is where judgment matters.

If the model cannot explain triggers, sequence, or outcomes, behavior is underspecified.

If it looks like a box catalog with arrows, behavior is probably missing.

If every call and topic is shown in the first enterprise view, you have probably overdone it.

One point I feel strongly about, partly because it comes up so often in integration reviews: teams often use application components where they should show application services. When you are talking about what another domain or channel consumes, service is usually the right concept. When you are talking about the system boundary that realizes that service, component is the right concept.

That distinction becomes especially important in cloud-heavy and event-driven environments. A Kafka topic is not the same thing as the application component publishing to it. An IAM token validation function is not the same thing as the IAM platform. An API gateway is not the same thing as the customer eligibility service exposed through it.

Passive structure: easily ignored, often the most important

Passive structure is what behavior acts upon or produces.

This includes business objects, data objects, artifacts, messages, documents, state records, event payloads, generated reports, and files. In practice, it is the information and thing-ness of the architecture.

And in regulated telecom, passive structure is usually more important than teams first assume.

Because this is where governance really bites:

• customer data governance
• retention obligations
• privacy and consent controls
• billing evidence
• fraud case data
• network event records
• inter-operator transaction records
• complaints evidence
• audit trails

Examples:

• Business object: service contract
• Data object: subscriber record, usage event, call detail record, fraud case
• Artifact: deployment package, generated compliance report, configuration file

The line between business object and data object does not need to become a philosophical crisis. In practical terms, business object often reflects the business meaning, while data object reflects information handled by applications. In many repositories, teams blur them or move between them across viewpoints. That is acceptable if the viewpoint is clear and the relationships make sense.

What is not acceptable is omitting passive structure entirely because “data belongs to the data architecture team.”

That is one of the most expensive mistakes I see.

If your model shows identity verification behavior but not the identity data or consent record it acts on, it is incomplete. If your porting architecture shows integration components but not the porting request object or status evidence, it will not survive serious governance. If your activation model has a Kafka topic but no event payload or resulting state record, then observability, retention, and replay discussions get muddled very quickly.

Passive structure also exposes architecture debt. Duplicate subscriber master records. Unclear system of record. Event payloads treated as canonical models without governance. “Temporary” replication stores that quietly become permanent truth sources. In my experience, you often do not see the debt until you model the information explicitly.

Bad modeling example #1

I have seen customer profile modeled as a behavior because it appeared on a customer journey map.

That is a category error. The profile is not something that happens. It is an information object used and updated by behavior. The journey step might be review customer profile or update customer profile. Those are behaviors. The profile itself is passive structure.

Bad modeling example #2

Another classic: treating activation event and activation record as if they are the same thing.

They are related, but they are not identical. The event is behavior or behavioral trigger context. The record is passive structure, often retained as evidence. If you collapse them casually, audit and troubleshooting conversations get painful very quickly.

The table that usually clears this up faster than another lecture

One note matters here: in ArchiMate, naming conventions help, but relationships decide the real meaning. A thing called “Validation Service” could be sloppily used as a component name. A box called “Porting Engine” might really be an application function in disguise. You have to look at how the element behaves in the model.

Walkthrough: modeling the activation scenario without making a mess

Here is a practical sequence.

Step 2: identify the primary business behavior

Start with the top-level behavior: customer onboarding and number porting process.

Do not start by drawing twenty microservices. Stay with the business outcome first.

Step 3: map active structure to each part

Now assign performers:

• Retail agent handles customer interaction
• KYC component validates identity
• Order management component coordinates fulfillment
• Provisioning engine activates network service
• Billing component creates billing structures
• Notification service component issues communications
• IAM platform enforces access and service-to-service trust
• Kafka platform carries asynchronous events between domains where that pattern is actually used

Already the model becomes useful. You can ask ownership questions. You can attach controls. You can discuss sourcing. You can assess blast radius.

Step 4: identify passive structure touched at each step

Now add the things acted upon:

• Customer identity data
• Consent record
• Porting request
• Provisioning order
• SIM status
• Billing account
• Notification content
• Activation event payload
• Audit log entry

This is where many diagrams become uncomfortable for teams, because hidden duplication suddenly becomes visible. CRM may store a customer profile. Order management may cache parts of it. Billing may maintain its own customer account representation. The model forces the system-of-record conversation.

Good. It should.

Step 5: separate internal behavior from exposed services

This distinction is worth making explicitly.

• Internal application function: tariff eligibility calculation
• Exposed application service: order submission service
• Exposed application service: identity verification service
• Internal orchestration behavior: coordinate activation workflow

The consumer sees the service. The owning component performs the internal function. Keeping those separate helps with API management, sourcing decisions, and resilience analysis.

Step 6: add triggering events and outcomes

Events matter because telecom operations are full of asynchronous transitions:

• Identity verified
• Donor network approval received
• SIM activated
• Billing account created
• Welcome notification sent

In cloud-native environments, these are often emitted onto Kafka or another event backbone. That does not make Kafka the behavior. Kafka is part of the technology structure enabling event transport. The event itself remains behavior-related context, and the payload or retained event record is passive structure.

Step 7: refine only where decisions depend on the distinction

Do not explode the model into every API resource, schema, and database table unless the purpose of the view genuinely requires it.

A good resulting view should make four things obvious:

• who performs what
• what data changes hands
• where controls apply
• what events trigger downstream impact

That is enough for most architecture governance discussions.

Here is a simple sketch.

It is not fancy. It is readable. In governance work, that matters more than people sometimes admit. TOGAF roadmap template

The mistakes I see most often in architecture repositories

Let me be blunt. Most repository problems are not tool problems. They are modeling discipline problems.

1. Turning every box into an application component

This happens constantly in transformation programs.

“Order.” “Activation.” “Billing.” “Consent.” “Fraud.” Everything becomes a box that looks like a system, even when some are capabilities, some are processes, and some are information objects.

Why it happens: components feel concrete.

Damage: false system boundaries, confused ownership, bad roadmaps. ArchiMate in TOGAF

Fix: force teams to classify each major noun as performer, behavior, or object before drawing the view.

2. Mixing service, function, and component in one label

Examples like Provisioning Service Platform are architectural mush.

Why it happens: people try to keep everyone happy in one label.

Damage: impossible to tell whether the box is a system, offering, or internal function.

Fix: separate them. Use one element for the component, another for the service if externally consumed, and another for function/process if internal behavior matters.

3. Omitting passive structure

Still very common.

Why it happens: teams think data modeling is somebody else’s job.

Damage: no traceability, no evidence chain, weak compliance views, hidden duplication.

Fix: every governed view should include the key data or business objects that decisions depend on.

4. Modeling events as data only, or data as events only

Activation event versus activation record. Same family, different purpose.

Why it happens: event-driven architecture jargon encourages sloppy shorthand.

Damage: confusion in retention, replay, observability, and audit.

Fix: model event occurrence and persisted record separately when it matters.

5. Using business process symbols to model application orchestration

I see this a lot when teams are overly BPMN-influenced.

Why it happens: business process notation is familiar.

Damage: application responsibilities get hidden behind business semantics.

Fix: use application behavior when it is application behavior. A workflow engine is not a customer-facing business process just because it has steps.

6. Producing notation-pure views that hide responsibility boundaries

This one is almost worse because it looks professional.

Why it happens: architects optimize for notation correctness.

Damage: governance cannot answer real risk questions.

Fix: design views around decisions. If a control owner or system boundary is material, make it visible.

7. Over-modeling technology structure too early

A full Kubernetes and cloud service decomposition in an enterprise operating view is usually a mistake.

Why it happens: technical teams like concrete detail.

Damage: signal gets buried, business stakeholders disengage.

Fix: only bring technology structure into the view when resilience, residency, IAM, performance, or control concerns require it.

I am opinionated here because I have seen too many repositories die from false precision.

Where regulation changes the modeling choices

In a lightly regulated context, some fuzziness is survivable. In telecom, less so.

Regulatory pressure changes what your model must make explicit:

• lawful intercept obligations
• customer identity verification and fraud controls
• critical service availability
• retention and deletion requirements
• complaint handling and evidence
• inter-operator processes
• data residency
• access management and privileged operations

When those pressures are present, the active/passive/behavior distinction stops being optional hygiene and becomes core architecture control.

• Active structure identifies the accountable owner or control point
• Behavior identifies the controlled activity
• Passive structure identifies the regulated information asset, evidence object, or retained state

Take a porting complaint investigation.

The regulator, internal audit, or customer care escalation may need to know:

• which application component submitted the request
• what process handled an exception
• which records prove timing, consent, and status changes
• which organization boundary was crossed
• what IAM policy governed access
• whether asynchronous processing introduced delay or loss

If your model collapses services into components and records into generic “data,” that investigation becomes painful.

A lot of audit findings are really architecture clarity failures wearing a compliance costume.

Service is behavior, not the box behind it

This one is persistent enough to deserve its own section.

Teams will draw CRM service or Billing service and use the phrase as if it means the same thing as the underlying system. It does not.

A service is behavior. Specifically, externally visible behavior offered to a consumer.

A component or interface is active structure that exposes or realizes that behavior.

For example: Number Portability Validation Service

That service may be exposed through an API layer. It may be realized by order management, partner integration components, maybe even a rules engine. The service is what the consumer gets. The components are what perform and support it.

Why this matters:

• Reuse discussions: reusable service does not imply reusable component
• Sourcing decisions: outsource service provision, keep orchestration in-house
• API management: productized API is not the same thing as the backing system
• Resilience design: service availability may depend on several components
• Accountability: service owner and platform owner may differ

A naming rule that helps, though it is not foolproof:

• components tend to be nouns
• services read like what a consumer receives
• functions and processes read like internal action

But again, names help less than relationships.

Choosing abstraction without producing mush

This is the chief architect’s daily headache.

Executives need clarity. Delivery teams need specificity. Repositories need consistency. If you model everything at once, nobody can use it. If you model too vaguely, nobody can trust it.

The approach I have found workable is to use three practical levels.

Level 1: business-operating view

Show the activation journey, major actors, major systems, key services, and critical information objects. Leave out microservice internals, Kafka topic taxonomies, and detailed deployment unless there is a regulatory or risk reason.

This is the executive and governance board view.

Level 2: application cooperation view

Show how CRM, order management, KYC, billing, provisioning, IAM, notification, and integration components cooperate. Include exposed services and major events. Add Kafka where asynchronous collaboration is decision-relevant. Add API gateway and IAM where boundary control matters.

This is where domain architects and solution leads work.

Level 3: control and data traceability view

Show the regulated data objects, evidence records, event/record distinction, systems of record, retention points, IAM enforcement, logging, and operational control boundaries. Include cloud regions or nodes if residency or resilience matters.

This is for compliance architecture, audit readiness, and risk review.

The trap at one extreme is wallpaper architecture: vague boxes called Experience, Core, Data, Integration. Everyone nods and nobody learns anything.

The trap at the other extreme is diagram as source code: every Lambda, pod, schema, and topic in one hopeless picture.

The best review question is simple: what decision should this view support?

If nobody can answer that, the abstraction level is wrong.

A worked mini-example: lawful intercept request handling

This use case is sensitive, which is exactly why it is useful.

If your distinctions are weak here, they are weak everywhere.

Active structure

• Lawful intercept operations role
• Compliance case management component
• Network mediation component
• Secure evidence repository node
• IAM and privileged access control services/components

Behavior

• Validate warrant
• Authorize interception
• Configure mediation
• Collect records
• Produce compliance evidence
• Revoke interception

Passive structure

• Warrant record
• Target identifier set
• Interception configuration data
• Evidence package
• Audit log
• Access approval record

If these categories are mixed, bad things happen fast.

Security controls get attached to the wrong thing. Retention obligations are applied inconsistently. Accountability blurs between the case management team and the mediation platform team. Auditors ask where evidence is produced and retained, and the model answers with a box called “LI Platform.”

That is not enough.

Here is a compact sketch.

In regulated industry work, this level of clarity is not excessive. It is the minimum needed to talk sensibly.

The modeling rules I would actually put into a standard

Not twenty pages of theory. Just rules people can use.

• Every major behavior in a governed view must be assigned to active structure.
• Every regulated or decision-critical data object must appear explicitly as passive structure.
• Externally consumed services must be separated from internal functions.
• Event and record must not be collapsed into one element unless the viewpoint explicitly allows it.
• “Platform” labels must be decomposed when they hide distinct accountability or control boundaries.
• Each view must state intended audience and decision purpose.
• IAM enforcement points should be shown where access control is material to the decision.
• Kafka topics, event streams, or API gateways should appear only when interaction style changes the architecture decision.
• System-of-record assumptions should be explicit whenever customer, billing, consent, or compliance data is involved.

Repository hygiene matters too:

• controlled naming
• relationship standards
• examples and anti-examples
• review gates that check clarity, not just syntax

Standards should be strict enough to produce consistency and loose enough that people still use them. If your standard requires six layers of purity before a team can model a porting process, they will bypass it and draw in PowerPoint.

And honestly, they will not be entirely wrong.

How to review a diagram in five minutes

This is the survival checklist I use in governance boards.

1. Can I tell who performs the behavior?
2. Can I tell what information is acted upon or produced?
3. Are services distinguished from components?
4. Are events visible where they matter?
5. Does the model expose accountability and control points?
6. Is anything named in a way that hides whether it is structure, behavior, or data?

Then the telecom-specific checks:

• Where is customer consent represented?
• Where is the system of record implied?
• What proves the activity happened?
• Which integration point crosses organizational boundaries?
• Where does IAM enforce identity, privilege, or service trust?
• If Kafka is present, what event matters and what record persists?

If a model fails those questions, it is not ready for governance no matter how pretty it is.

Conclusion: model for decisions, not for notation exams

Here is the core distinction again, because it really is the anchor:

• Active structure performs
• Behavior happens
• Passive structure is used or changed

That is the whole game.

The value of ArchiMate is not that it gives us more boxes to draw. It gives us a way to make responsibility, action, and information explicit enough for real enterprise decisions. In telecom, that means better impact analysis, cleaner compliance traceability, less confusion between systems and services, and more honest governance conversations.

I have learned, sometimes the hard way, that the most dangerous architecture models are not the obviously bad ones. They are the polished ones that blur performer, action, and data just enough to pass a meeting and fail later under scrutiny.

If a reviewer cannot tell who did what to which information, the model is not finished.

FAQ

Is an API active structure or behavior?

Usually the application service exposed via the API is behavior. The application interface or gateway exposing it is active structure. People collapse them together all the time.

Is a database passive structure or active structure?

Depends on what you mean. The data is passive structure. The database engine/service can be active structure if hosting, operations, or control boundaries matter.

How do events relate to passive structure?

The event itself belongs with behavior. The event payload, retained event log, or resulting state record is passive structure.

When should I model a service versus a function?

Use a service when the behavior is externally offered to a consumer. Use a function for internal behavior performed by a component.

Can one concept appear differently in different viewpoints?

Yes, with care. A business object may be shown as a data object in a more application-centric view. But do not let viewpoint flexibility become an excuse for inconsistency.

How much ArchiMate detail is enough for architecture governance?

Enough to support the decision at hand. In practice, that usually means performer, key behavior, key information objects, and material control boundaries. More than that only when the decision needs it.

Frequently Asked Questions

What is enterprise architecture?

Enterprise architecture aligns strategy, business processes, applications, and technology. Using frameworks like TOGAF and languages like ArchiMate, it provides a structured view of how the enterprise operates and must change.

How does ArchiMate support enterprise architecture?

ArchiMate connects strategy, business operations, applications, and technology in one coherent model. It enables traceability from strategic goals through capabilities and application services to technology infrastructure.

What tools support enterprise architecture modeling?

The main tools are Sparx Enterprise Architect (ArchiMate, UML, BPMN, SysML), Archi (free, ArchiMate-only), and BiZZdesign. Sparx EA is the most feature-rich, supporting concurrent repositories, automation, and Jira integration.