System elements	System description Model types	Operational system Real world instances
Structural elements	Roles	Actors
Behavioral elements	Events	Occurrences
Behavioral elements	Behaviors	Performances

Architecture frameworks and modelling languages are used to describe and design business systems.

These systems are specifiable at many levels of abstraction from high-level views down to the bottom level of atomic actions that individual actors can be asked to perform.

And they can be specified from different viewpoints, as this table illustrates.

Activity system	Behavioral view	Structural view
External view	Events	Interface
Internal view	Actions	Actors/Roles

A system’s interface encapsulates actors (humans and mechanical components); these structural elements must be addressable.

External events or service requests prompt the internal actors to perform actions (operations or processes); these behavioral elements run over time.

The four-view table above is attractively simple, but open to interpretation and debate, and it can be confusing.

This paper discusses four dimensions of architecture description; each can be confusing in its own right, and worse, they are entangled with each other.

The relationships between components, interfaces and services

TOGAF divides the architecture of an enterprise into actors.

The actors are called building blocks (perhaps because they encompass human actors and technology components).

Each building block can perform one or more behaviors, on its own or in cooperation with other building blocks.

Building blocks come in several shapes and sizes: functions, roles, organization units, human actors and application/technology components.

Building blocks are defined in the manner of components that interoperate by requesting and providing services.

Each building block is definable by the service portfolio (an aggregate of discrete, singular, services) it offers to others.

A service is a repeatable activity that (if successful) ends in a desired outcome.

A service ends with a result/output/product of value to the service requester or receiver.

A service is a logical contract that encapsulates whatever process(es) are need to deliver the value required.

ArchiMate’s definitions appear to say an interface offers one service.

“A business interface exposes the functionality of a business service to other business roles”

“An application interface exposes an application service to the environment.”.

But read on, and you’ll find one interface can aggregate many services.

“A business interface may be assigned to one or more business services, which means that these services are exposed by the interface.”

“An application interface is the (logical) channel through which the services of a component can be accessed.”

Further: “The same application service may be exposed through different interfaces.” Ah, N-to-N then!

TOGAF and ArchiMate both define a service as a discrete unit of behavior

Both presume one component can offer many services through an interface.

And many examples out there do conform to those definitions.

Why not all? Perhaps because UML and others use the word service as a synonym for interface, and operation for service.

To edit paraphrase what UML says in sections 7.3.24 & 25.

“An interface is a kind of component type that represents a declaration of a set of coherent public features and obligations.

An interface specifies a contract; any instance of a component that realizes the interface must fulfill that contract.

Since interfaces are specifications, they are not instantiable, and are implemented by instance of instantiable component types.

Note that a given component may implement more than one interface and that an interface may be implemented by a number of different components.”

The set of interfaces implemented by the component are its provided interfaces and signify the set of services the component offers to its clients.

The component will have an implementation for each of operations defined by the interface.”

The term service is now widely used to label anything and everything - an interface, a process, an application component, a“system software” node.

People draw a message broker box associated 1-to-1 with a “messaging service” box, which is to say nothing of architectural significance

They speak of one address component offering one “address service”, when they really mean the component offers a service portfolio..

They even speak of components as services (e.g. speak of small applications as micro services).

In natural language, people use same word for a singular behavior and an aggregate structure of behaviors.

The term “process” is used to mean a single procedure or a whole application (in Windows Task Manager).

And the term “service” is used mean one discrete operation, or a multi-service portfolio.

Natural language is not controlled enough for people wanting to describe things unambiguously.

A professional modeller does not use the same word for many concepts, or several words for one concept.

And a professional modelling language discourages people from using graphical symbols a loosely as words.

The structure/behavior dimension (1)

System theory draws a distinction between structural and behavioral views of a system (as does UML p 694).

A dynamic or behavioral view of a system shows a behavior (of a role or interacting roles) over time; the actions and interactions within a behavior run from start to end.

A static or structural view shows a system’s structure irrespective of time; it shows relationships between roles, and may relate named behaviors to roles.

Why do people sometimes struggle with the structure/behavior distinction?

Because behaviors have structures; and structures have behaviors.

A process is a structure of actions in a time sequence, yet is called a behavior here.

A role defines behaviors actors can be asked to perform, yet is called a structure here.

How people use words in natural language is very loose.

Natural language can obscure the controlled language our profession needs to define the dimensions of architecture.

A controlled vocabulary has to pin the meanings of terms (like structure and behavior) to even more general concepts.

Structures in space versus behaviors over time

In short: actors occupy space; actions take time.

UML divides its views of a system between structure and behavior diagrams.

UML structure diagrams show element types (classes, roles, components) whose instances are addressable, implying they occupy a position in space.

All actors, all active components (and all passive structures/data elements) must be locatable in space.

UML behavior diagrams show element types (use cases, interactions, etc) whose instances run from start to end over time.

All actions (performed by actors, acting on passive structures/data) are triggered by events and run from start to end over time.

Structural and behavioral aggregation

An aggregate structure takes up more space than any of the smaller structures aggregated into the structure.

Given that a human actor or software component occupies space, a coarser-grained aggregation of actors or components needs more space.

An aggregate behavior lasts longer than any of the shorter behaviors aggregated into the behavior.

Given that a process performance occupies time; a coarse-grained process must last longer than each of its process steps.

But note, there are two kinds of behavior aggregation – behavioral and structural.

Connecting process steps in sequence creates a longer behavior element.

Grouping process steps by some other cohesion criterion and assigning them to a role or function creates a structure element.

Q) Are you just pointing out that these terms are used in multiple ways?

A) More than that; I am saying ArchiMate has a peculiar view of the structure/behavior distinction.

The names of structures and behaviors

ArchiMate says: “These three aspects – active structure, behavior, and passive structure – have been inspired by natural language,

where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).”

Natural language is loose; nouns and verbs are imperfect indicators of a structure/behavior distinction.

And you can’t rely on a thing’s name to tell you whether it is structural or behavioral.

The term “function” is especially ambiguous.

Functionality = behavior in the broad sense. Functioning = active in the run-time sense. So what is a “function”?

In natural language, the function of a thing often means its purpose.

In UML, a function is a behavior; runs over time from receiving input to producing output, but without access to system state.

In TOGAF, a function is a structure, a node in a logical functional/capability decomposition structure; it does not run over time.

It can be defined as an aggregate of related business actions (internal view) or portfolio of services offered (external view).

The logic behind the system elements you find in UML, ArchiMate and TOGAF

A start-to-end behavior has a structure. An active structure can be seen as an aggregate of performable behaviors. Confusing?

Understanding the behavior/structure distinction helps in understanding TOGAF, even if the authors are not conscious of the logic behind what they write (e.g. page 333 and chapter 37).

A behavior element (a service or process) flows over time from start to end, and terminates by delivering a result of value.

TOGAF assumes behaviors are performed by interoperating “building blocks” in response to triggering events, messages or invocations.

Structural elements can be divided between logical types which aggregate behavior specifications, and physical instances which actually perform those behaviors.

TOGAF calls these building blocks (BBs) and further divides the types between logical ABBs and identifiable hireable/buyable/buildable SBBs.

The physical instances could be called "operational building blocks"; however, TOGAF is not designed to address the grey sections of the table below.

It allows the naming of individual human actors and organisation units, but does not expect an architect to identify software classes, objects or component instances.

Structural element types		Structural element instances
Logical architecture building blocks (ABBs)	Physical solution building blocks (SBBs)	Physical instances in deployed systems (which occupy space and respond when asked to peform behaviors)
A UML class is a logical specification of the behaviors (operations, methods) one or more physical objects can perform.	E.g. A class coded in Java or C#	An object is instantiated or deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.
A component interface is a logical specification of the behaviors (services, uses cases) one or more physical components can perform.	E.g. A named CRM package or DBMS	A component instance is deployed in the software system of interest, along with physical resources it needs, so it can respond to requests.
A role is a logical specification of the behaviors (services, duties) one or more physical human actors can perform.	Named actors	A human actor is employed or deployed in the business system of interest, along with the rewards and physical resources it needs, so it can respond to requests
A business function is a logical specification of the behaviors (services, processes) one or more physical organisation units can perform.	Named organisation units	An organisation unit is instantiated in the business system of interest, along with the budget and physical resources it needs, so it can respond to requests.

TOGAF allows the naming of individual human actors and organisation units, but does not expect an architect to name software objects or component instances.

ArchiMate curiously classifies functions alongside processes, as though functions are event-triggered behaviors.

ArchiMate has some peculiarities that make alignment with TOGAF difficult. For further analysis, see footnote 1.

The external/internal dimension (2)

A system is a bounded collection of actors performing actions; it is separated from its external environment by an interface.

Consider the holding of board meetings as a system.

An invitation list defines a group of actors - a structure of actors in different roles, who follow the agenda and interact in the board room.

A meeting agenda defines a time-bound sequence of actions - a behavior in which actors playing different roles interact.

Inside the boardroom, the actors study inputs, interact, reach conclusions and define goals and actions

Those outside see only inputs (briefs they may help to prepare) and outputs (goals and actions) they must respond to.

Why do people find the external/internal distinction confusing?

Because systems are composed and decomposed, formally and informally.

So, what is external to a smaller system/component can be internal to a bigger system/component.

Still, at every level of granularity, the external view is a specification of behaviors that encapsulates internal actors/components that perform behaviors.

Arguably, roles and functions are more like external interface/type definitions than they are like internal actors and components.

E.g. TOGAF aggregates required service types into service portfolios.

Each portfolio is specification of behaviors that actors or components inside the system are expected to perform.

TOGAF	Behavioral view	Structural view
External view	Service	Service portfolios
Internal view	Processes	Actors, Organization Units & Components

Service portfolios are assigned to logical roles, functions and components (this is a business principle as much as software principle.)

The TOGAF view is perhaps better expressed as in the table below.

TOGAF	Behavioral view	Structural view
External view	Services	Logical Roles, Functions & Components
Internal view	Processes	Physical Actors, Organization Units & Components

ArchiMate classifies elements differently; it positions functions as internal behaviors alongside processes.

ArchiMate	Behavioral view	Structural view
External view	Services	Interfaces
Internal view	Processes & Functions	Actors, Roles & Components

ArchiMate says: “A business process is defined as a behavior element that groups behavior based on an ordering of actions.”

As you’d expect, the actions in a process are ordered in a time sequence; this differentiates a process from a function.

WSDL is an interface definition language, but confusingly calls an interface a web service.

Each web service is a service portfolio, an aggregate of discretely-requestable services that WSDL calls operations.

A web service holds the addresses of component instances that realize the operations.

WSDL	Behavioral view	Structural view
External view	WS Operations	Web Services
Internal view		Component instances addressed

Another source of confusion is that the external/internal distinction is relatable to either or both of the next two distinctions.

The type/instance dimension (3)

An instance is a particular thing that realizes or embodies the properties in a type (found in a description or model).

Why do people find this distinction confusing? Because it is! It is very hard to get your head around it.

Board meeting is a type: it describes instances of which there may be many; it describes properties they all share.

A board meeting is an instance: it is an occurrence of the type; it has many unique properties not described in the general type.

“The ArchiMate language intentionally does not support a difference between types and instances.”

Except that does!

In ArchiMate, the actor symbol represents what might be called a singleton type, which can be identified using an individual instance name.

You can label the actor symbol with a role/type name (say CEO) and/or an actor/instance identity (say CEO Joe Soap).

The types in the meta models of modelling languages are generic system description types (such as role and process).

The types in user models (such as student and application) may be seen either as specializations of the more generic types, or as instances of their use.

Run-time instances are things (such as individual students and applications-in-progress) that embody types in operational systems.

The table below is a translation of ArchiMate Figure 1.

Level		Model at different levels		Examples
1	A general theory	ArchiMate's generic meta model	Generic entity types	Behavior element	Active structure element
2	Enterprise architecture	ArchiMate's meta model	Specializations or instances of level 1 types	Business process	Business role or actor
3	Domain-specific models	ArchiMate user's model	Specializations or instances of level 2 types	Sale process	Marketing director
4	Operational systems	ArchiMate user's business systems	Instantiation of level 3 types	Particular sales	Henry Miller

The equivalent in TOGAF could be this.

Level		Models at different levels		Examples
1	EA principles	TOGAF's generic meta model	Generic entity types	Service	Logical component	Physical component
2	Enterprise architecture	TOGAF's meta model	Specializations or instances of level 1 types	Business service	Function	Organization unit
3	Business-specific models	TOGAF user's model	Specializations or instances of level 2 types	Brokered sale	Sales	Sales department
4	Operational systems	TOGAF user's business systems	Instantiation of level 3 types	Particular sales		Sales people

TOGAF distinguishes roles from individual actors, and business functions from individual organization units.

TOGAF	Behavioral view	Structural view
Types	Processes	Roles & Functions
Instances	Performances	Actors & Organization Units

In TOGAF: requirements <specify> service portfolios <are assigned to> logical architecture building blocks.

Logical architecture building blocks <are specialized or realized by> physical solution building blocks <which are realized or instantiated by> deployed solutions.

Phase	Level	Elements	Required behavior to built structure Types to instances
A, RM	Requirements	Required Services & Scenarios	Behavioral types
B,C,D	Logical building blocks	More required Services & Processes Roles, Functions & Logical Components (service portfolios)	Behavioral types Structural types (aggregate behaviors)
E,F,G	Physical building blocks	Actors, Organization Units & Physical Components	Specializations of structural types Instance names
G,H	Deployed solutions		Instances of types

Curiously (see footnote 1 for more)

Instances of structure elements are usually called physical, and are sometimes named in models.

Instances of behavior elements are usually called logical, and are well-nigh never named in models.

The UML standard takes care to distinguish types from instances using different words.

Yet it still manages to blur structural types and instances by equating actor with role.

ArchiMate doesn’t officially draw a type/instance distinction.

Nevertheless, at least some of the types in a system description must be instantiated as actors in an operational system.

And some ArchiMate sentences mean different things depending on whether the words apply to types or instances.

The logical/physical dimension (4)

Why do people find the logical/physical distinction confusing? Because there are countless interpretations of it.

A classic four-level idealisation hierarchy is: conceptual <abstracts from> logical <abstracts from> physical <abstracts from> real.

The terms conceptual, logical and physical are often used to label three increasingly elaborate specifications of things to be deployed.

But there are many different interpretations of what each level means and is used for.

In network engineering, logical/physical means software/hardware.

In database design, logical/physical means normalised for integrity/structured for performance.

Enterprise data architects have their own domain-specific interpretations.

Here is a reasonably conventional way of distinguishing conceptual, logical and physical, much as in TOGAF.

Idealisation hierarchy	Notes
Conceptual model	Specifies business processes and/or data in a computing-independent way. It need not be related to any particular computer, application or database, but may be reversed engineered from or related to them.
Logical components	Abstract roles, functions, application and technology components (envisaged or observed). Components are encapsulated and defined by a service portfolio (and sometimes a data model) along with non-functional requirements. They are not explicitly related to any vendor or technology product choice, but may be reversed engineered from or related to specific products
Physical components	What is hired, bought or built to realize the logical specification; may be vendor or technology-specific. Named actors, organization units, data/application/technology component types and instances. Their specifications include actual non-functional attributes, costs, configuration and deployment requirements.
Deployed solutions	The actors and components of the operational system, configured and deployed to perform actions as specified above.

In TOGAF (and in TOG more widely) logical primarily means vendor/technology neutral specification of components by service portfolios.

Logical roles are realized by physical actors; logical components are realized by more physical components.

A logical business function/capability decomposition structure is realized by a physical organization structure.

A “functional organization structure” is an organization structure that matches a logical functional/capability decomposition.

You might think of a business capability as a purely logical function, or as the one or more organization units that realize the function.

ArchiMate doesn’t explicitly draw a logical/physical distinction.

Likely because it does draw behavior/structure and external/internal distinctions, both of which can be interpreted as logical/physical.

And it (sadly) ducks drawing a type/instance distinction, which is also interpretable as logical/physical.

Entanglement of dimensions in practical methodologies

TOGAF is centered on dividing a system into components (structures) defined by the services (behaviors) they provide.

It doesn’t feature the term “interface”, but does specify logical building blocks by defining their "service portfolios”.

Outside of the business domain, TOGAF does not expect architects to detail internal processes.

Its core architecture description elements can be classified using three dimensions as shown below.

TOGAF	Behaviors	Structures
External	Business Services IS Services Platform Services	(Service Portfolios)
Internal	Business Processes	Business Functions, Roles Logical Application Components Logical Technology Components	Logical Building Blocks
Internal		Organisation Units, Actors Physical Application Components Physical Technology Components	Physical Building Blocks

ArchiMate elements can be classified in a similar way; read “TOGAF and ArchiMate harmonisation” for more.

TOGAF starts with analysis of the business/human context, so there is a business to technology sequence (left to right below).

In each architecture domain, it starts by defining required services in the requirements specification.

It then proceeds by defining structural building blocks, first at logical level and then at a physical level (top to bottom below).

This table arranges these two sequences in a way that that shows correspondences between concepts in different architecture domains.

TOGAF level	Business domain	Information systems domain		Technology domain
Requirements	Event, Business Service, Product	Info/Data Entity	Appl/IS Service	Technology Service
Logical building blocks etc.	Function, Role, Process	Log Info Component	Log App Component	Log Tech Component
Physical building blocks	Organization Unit, actor	Phys Info Component	Phys App Component	Phys Tech Component

The business to technology sequence is one of several sequential threads; others include baseline to target and generic to specific.

This paper suggests sequences from 1) required behavior to built structure, 2) external to internal, 3) types to instances and 4) logical to physical.

TOGAF’s architecture development method can be seen as interweaving all these sequences.

The table below squashes several dimensions into a two-dimensional table, but the dimensions cannot be perfectly aligned.

Phase	Level	Elements	External to internal	Required behavior to built structure Types to instances	Logical to physical
A, RM	Requirements	Required Services & Scenarios	External view	Behavioral types	Conceptual?
B,C,D	Logical building blocks	More required Services & Processes Roles, Functions & Logical Components (service portfolios)	External view Internal view	Behavioral types Structural types (aggregate behaviors)	Conceptual? Logical
E,F,G	Physical building blocks	Actors, Organization Units & Physical Components	Internal view	Specializations of structural types Instance names	Physical
G,H	Deployed solutions			Instances of types	Real

It doesn’t seem right to say required services and scenarios are conceptual, since they have physical qualities and may deliver physical products.

The logical/physical distinction drawn in TOGAF is mostly intended to encourage vendor-neutral specification of business and IT systems.

This is one of more than 200 papers at http://avancier.website.

Footnotes

Footnote 1: On type and instance

This footnote grew so large, and so dominated by questions about ArchiMate, it has been removed from here into a paper in on its own.

“Things the next ArchiMate standard might address”.

Most notably, this paper expands on the discussion of types and instances.

It also explains discrepancies between ArchiMate’s graphical meta models and its Relationship Table appendix.

And why it is meaningless to think of a collaboration as an instance, but OK to think of it as an N-way association relationship.

Footnote 2: The difference between “Proper Domain Models and "Concept Graphs”

Domain models (including those in international standards and books) are often drawn using UML class diagram notations.
Those class diagrams often feature class hierarchies, and show association cardinalities that imply questionable 1-1 associations.

But in human affairs (rather than in mathematics) the passage of time undermines class hierarchies

And cardinality constraints on relationships need to account for the full life span of persistent entity instances.

Software designers often model objects that live only a short time in memory (perhaps reflecting data in a small view of a larger database).

Their code may be built around an aggregate entity (say an on-line shopping basket) that lives for only seconds or minutes.

They may be careless about the specifying the cardinality on association relationships, because it has no impact on their implemented software.

The passage of time undermines class hierarchies in models of persistent business entities.

E.g. you may start out by classifying every person as either a man or a woman.

But over time, sex changes turn these “types” into “states” of a person.

Within a system generation - one object may change from one type to another.

Between system generations - a type/class hierarchy is often revised – implying persistent entities must be re-classified.

The result is that specialization relationships are less common in models of long-lived entities in business domain models.

To specify the cardinality of associations requires some life history analysis.

Associations between types in a model at level N should be labelled to specify how instances at level N+1 are related.

The rules constraining association relationships between entity types in model apply to instances of those entities.

Business database designers understand this well, because it has an impact on the birth and death of persistent entities.

E.g. a mandatory 1-N association between entity types A and B implies start-of-life constraint on the existence of instances of type B (A must exist).

It may also imply an end-of-life constraint on instances of type A (all Bs must have died already).

Other modellers think of object instances at a moment in time, they don’t think how time turns 1-to-1 associations into 1 to N, or N-to-N.
They aren’t taught how to analyse association cardinalities, and don’t worry about them.

They may not even realize cardinalities apply to objects/instances rather than classes/types.

So they are careless in drawing domain models; they

· draw composites in place of aggregates, and aggregates in place of associations

· draw 1-to-1 associations in place of 1-to-N, and 1-to-N in place of N-to-N

· draw an N-to-N association that hides a link entity important to the domain.

· draw one association relationship between two entities where there are two or more different associations

· completely omit some important associations.

The trouble is that the resulting domain model is not a true reflection of the real-world business domain.

Safer, call it a cartoon, or an informal "concept graph", and leave the cardinality of associations unspecified.