Things the next ArchiMate standard might
address
THIS OLD PAPER HAS
BEEN SUPERCEDED BY THIS
NEWER PAPER
THE REMANTS BELOW
ARE OUT OF DATE
Contents
The
relationships between components, interfaces and services
The
place of “function” in the behavior dimension
The
place of “function” and “role” in the internal dimension
The
need to distinguish type from instance
Recursive
abstraction of types from instances
Who
performs behavior? Instances or types?
What is a “temporary”
collaboration? A type or an instance?
ArchiMate
has some peculiarities that make alignment with TOGAF difficult.
It obscures the normal structure/behavior distinction - by positioning "business function" as a behaviour.
It obscures the external/internal and type/instance distinctions - by saying things like “roles perform behaviors".
It obscures the vital concept of a discretely requestable service – partly by associating an interface with a single service in some definitions.
Also by using the service (behaviour) symbol in examples where the interface (structure) symbol would be more accurate.
Surely clearer definition is possible, without making the standard any longer or more formal?
First, a few notes on cardinality rules.
Suppose a model says one team < is a group of> N players.
The model shows two concepts in a one-to-one association
In the world that is modelled, there can be many teams, and each one team is a grouping of N players.
The rules governing relationships between singular entity types in a model apply to entity instances in the world that is modelled.
ArchiMate
users have no cardinality symbol for specifying the number of instances at
either end of a relationship.
So, some use
the aggregation and composition relationships instead.
“The
aggregation relationship indicates that a concept groups a number of other concepts.”
Strictly speaking, it indicates that an instance of one concept type groups one
or more instances of the other concept
type.
The word "group" could can applied to any set, any one-to-N association (except a recursive one, if you believe the definition).
“In
contrast to the composition relationship, an object can be part of more than
one aggregation.”
So, aggregation allows one-to-N in both directions
(N-to-N), whereas composition is a uni-directional one-to-N association.
The component-to-interface association
A drift in
architectural practice (since the 1990s) has been towards decoupling interfaces
from components.
Which is to say, one
component <can realise all or part of> N interfaces, and one interface
<can be realised in full or in part by> N components.
ArchiMate says a
component is a composite of
interfaces, by which it means one interface belongs to one and one only
component.
If all interfaces
are component-bound; how to model a decoupled interface?
The interface-to-service association
TOGAF doesn't speak
much of interfaces, but does assume each component is encapsulated behind the
service portfolio it offers to clients.
So, one component’s
service portfolio is an aggregate of discrete, singular, services.
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 behaviour
Both presume one
component can offer many services through an interface.
And many examples
out there do conform to those definitions.
But some trained in
UML or VDML use the ArchiMate service symbol to represent an interface.
And some examples
show the service symbol being used to represent an application component or a “system software” node.
The term service is
now widely used to label anything and everything - an interface, a process or a
component.
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.
ArchiMate says: “The core language
consists of three main types of elements structure elements, behavior
elements, and passive structure elements (objects).
The active structure elements are the business actors, application components, and devices that display actual behavior.”
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.
UML says there are two fundamental premises regarding the nature of UML semantics:
“The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called “active” objects…
The
second is that behavioral semantics only deal with event-driven, or
discrete, behaviors.”
Does ArchiMate share
the same presumptions?
It doesn’t say so; but
it seems hard to deny that these presumptions do describe the reality of the
systems we model.
Our domain is event-driven systems in which actors (structures) act (behave) in response to messages (communication events) sent by other actors.
And designed systems in which receiving actors are supposed to respond to messages by performing purposefully-specified actions.
Structural and behavioral aggregation
In short: actors
occupy space; actions take time.
Remember, ArchiMate’s
aggregation relationship means an
instance of one concept type groups one
or more instances of another concept type.
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 behaviour 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 is misguided in this area.
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/behaviour
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; it 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 business
actions (internal view) or portfolio of services offered (external view).
The structure/behaviour distinction in UML
and ArchiMate
ArchiMate says:
An active structure
element is defined as an entity that is capable of performing behavior.
Actors and component instances perform (carry out,
execute) behaviors
Strictly, roles and interfaces do not; they group
(aggregate, consist of) behavior types that actors and
components can or should perform.
Organisation units perform (carry
out, execute) behaviors.
Strictly, business functions do not;
they group (aggregate, consist of) behavior types
that organization units can or should perform.
Clearly, roles group behaviours required of actors (along with whatever else matters to those actors).
Business functions group behaviours required of organisation units.
A business function (like marketing) is a node in
a logical structural model of a business.
So why does ArchiMate classify roles as structures,
but business functions as behaviors?
In UML, behaviors (activities, state machines and
interactions) are sequences of primitive actions.
A behavior is performed over time by one or more structural entities.
It describes how the states of objects, reflected in
their structural features, change over time.
ArchiMate says:
"A behavior element is defined as a unit of activity performed by one
or more active structure elements."
The “unit activity” cannot be a primitive action (as
in UML) it must be a larger aggregate.
Would you say a role
or business function is a unit of activity?
A role groups
activities performable by one or more human actors.
A function groups
of activities performable by one or more organization
unit actors.
So why does ArchiMate classify roles as structures,
but business functions as behaviors?
ArchiMate aggregates do not "consist of", they merely "group".
ArchiMate has a rule that structures don't aggregate
behaviors, which seems contrived.
An interface is a structure that groups services for
access by clients.
A role is a structure that
“has responsibilities”, which surely equates to “groups behaviors
required of actors in that role”.
From the bottom-up, a business function hierarchy
groups primitive actions into successively larger structural elements.
So why does ArchiMate classify interfaces and roles as
structures, but business functions as behaviors?
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
behaviour/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
(think service or process) flows over time from start to end, and terminates by
delivering a result of value.
TOGAF assumes
behaviours 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 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 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 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 instantiated in the business
system of interest, along with the budget and physical resources it needs, so
it can respond to requests. |
ArchiMate says: “Second, we make a distinction between an external view and an internal view on systems.
When looking at the behavioral aspect, these views reflect the principles of service orientation.”
Arguably, roles and functions are more like external interface/type definitions than they are like internal actors and components.
E.g. TOGAF proposes
defining required services and grouping them into services portfolios.
The service
portfolios are assigned to logical roles, functions and components (this is a
business principle as much as software principle.)
This view is
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.
ArchiMate says business actors and roles
“perform behaviors such as business processes or functions (capabilities)”.
Actors perform behaviors, but (strictly speaking)
roles merely group behavior types that actors can or should perform.
Actors perform processes, but do they perform
functions? Does UML say objects perform classes?
ArchiMate says: “At
the enterprise architecture abstraction level, it is more common to model types
rather than instances.”
An instance is
particular thing that realizes or embodies the properties in a type (found in a
description or model).
Why do people find the type/instance distinction confusing? Because it is! It is very hard to get your head around it.
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).
ArchiMate offers both
actor and role symbols. Similarly, both business function and
organization unit symbols.
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 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 UML standard takes care to
distinguish types from instances using different words.
It begins by distinguishing three base types, and instances
of them.
|
UML |
Structure |
Behavior |
|
|
Types |
Class |
Event |
Behavior |
|
Instances |
Instance, Object |
Occurrence |
Execution |
UML suggests it is well-nigh the rule in software design
to model types rather than instances.
“The distinction between objects and models of objects, for example, may appear subtle, but it is important.”
“Models do not contain objects [of classes], occurrences [of events], and executions [of behaviors], because those things are the subject of models.”
“Instances… the things that models represent at runtime… don’t appear in models directly (except very occasionally as detailed examples)”
E.g. a UML component is defined as a type rather than an instance, it:
“is a specialized class that has an external specification in the form of one or more provided and required interfaces”.
“represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.”
“defines its behavior in terms of provided and required interfaces.”
“serves as a type whose conformance is defined by these provided and required interfaces.”
ArchiMate says: “At
the enterprise architecture abstraction level, it is more common to model types
rather than instances.”
Arguably, modelling instances is perhaps more common at
the enterprise architecture level.
People draw boxes showing named actors, in named organization units, in named locations.
And want to ask questions of the kind: How many instances of type X are there are in a given location?
You might however take the view that is operational
configuration management, rather than enterprise architecture.
ArchiMate says: “The
model elements often represent classes of entities in the real world”
In general, it seems more accurate to say: “A model element shows a type and/or identifies an instance.”
ArchiMate says: “Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations.”
Hmm… what matters here is that a named organization unit is an individual instance.
The fact that the unit employs multiple resources is irrelevant to the uniqueness of the unit itself.
(And presumably a business actor could also be a machine, such as an electricity generator?)
The actor symbol represents what might be called a singleton type, which can be
identified using an instance’s name.
You can label the actor symbol with a
role/type name (say CEO) and/or an actor/instance identity (say
CEO Joe Soap).
ArchiMate offers both
actor and role symbols. Also, both business function and
organization unit symbols.
Locations can also show singleton types, when they are identified with addressable places.
Organization Unit X is divided between London and Paris offices.
The London location diagram contains a Unit X actor box, containing both Manager and Assistant actor boxes.
The Paris location diagram contains a Unit X actor box, containing only an Assistant actor box.
Suppose we choose to name the two Assistant boxes using individual human names.
Now, how to find which applications those two Assistants can use?
You may draw another view showing Assistant in a role box associated to applications that role can use.
In this
case, two views containing instance-named actor boxes are
supplemented by another view showing their shared role.
But this is not
a general solution to all questions arising from instance-named actor
boxes.
Also, note that those applications are types; the two assistants might use different application instances.
And now, how to find which roles are played in Organization Unit X?
Does an actor box really represent an
instance? The actor playing the role may be replaced by another over time.
That is why enterprise
architects are taught to use role rather than actor names, and business
function rather than organization unit names.
You might conclude role and actor should have all the
same relationships in a meta model, which they very
nearly do.
On the other hand, the fact that ArchiMate does
not distinguish role from actor in its definition of collaboration
raises questions (pursued below).
ArchiMate is on the way to some kind of
science, but doesn’t wholly make sense to me.
The
table below is a translation of ArchiMate Figure 1: “Metamodels at Different Levels
of Specificity”.
|
Level |
Metamodels at Different Levels of
Specificity |
Examples |
|||
|
1 |
A general system 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 |
|
3 |
Domain-specific models |
ArchiMate user's model |
Specializations or instances of level 2 types |
Sale process |
Marketing director |
|
4 |
Operational systems |
Operational systems |
Instantiation of level 3 types |
Particular sales |
Henry Miller |
ArchiMate says: “At the top we find the “most general” metamodel for system architectures…
The design of the ArchiMate language started from a set of relatively generic concepts (higher up in the pyramid).
These have been specialized towards application at different architectural layers, as explained below in the following sections.”
I have found
myself getting confused when flipping between ArchiMate levels 1, 2 and 3.
The relationships in
level 1 and 2 graphics are rightly drawn as associations
between concepts in the language.
But they are labelled
as though they are relationship in a level 3 user model; and that just doesn’t
seem proper!
(If I understand the “concepts and relationships” graphics associated with view points, I believe the following applies.
The specialisation relationships are between the concepts in the language - would not appear in models.
The rest (which might be considered association relationship varieties) are those that would appear in models.)
The
ArchiMate meta model graphics do look
reader-friendly (unlike the UML meta model graphics).
The level
1 graphic shows only 10 relationship types, which implies 30 when they are
specialized each of the three architecture domains.
Under the
level 2 graphics, there is text: “This figure
does not show all permitted A-B relationships”,
meaning it does not show all valid relationships in level 3 user models.
The text
could be instructively revised as: “These figures are only illustrative; they do not
show more than a thousand
permitted A-B relationships”.
ArchiMate
is silent about how to label a
relationship (in both directions) with reference to instances of the types.
These matters apply
to all relationship types that are subtypes of association (which is
most of them).
My beef
is theoretical; that the labels on association relationships ought to
follow proper domain modelling standards.
E.g. in
the level 1 graphic, there is a relationship labelled: "Service <used by> Active
structure element".
Properly
speaking, it is: "Service <sub types can be related in
a user's model by "used by" relationships to subtypes
of> Active structure element".
This
figure could also be annotated: “Beyond what
this figure shows, there are more than a
thousand permitted A-B relationships in the models you draw”.
Remember: the rules constraining association relationships between entity types in model apply to instances of those entities.
Associations between
types in a level N model should be labelled
to specify how instances at level N+1 are related.
|
The relationships in a level 3 user model |
specify relationships between |
instances in an operational system |
which are "real world" or
"run-time" things. |
|
The relationships in a level 2 meta model |
specify relationships between |
instances of concepts in a system description |
these
(user model boxes) are types. |
|
The relationships in a level 1 generic meta model |
specify relationships between |
instances of concepts in a general system theory |
these (abstract ideas)
are also types. |
Since
the instances related in the level 1 & 2 models are
the types in level 2 & 3 models, it seems improper to
draw relationships as though they are real world things.
What the relationship
annotations actually specify is only a tiny, tiny selection of the valid relationship types between types
in a level 3 model.
Most associations at
level 1 and 2 appear to say N-to-N associations are allowed at level 3, though
this is not explicit.
I am confident that
1 specific interface may be related to specific N services.
But the one
“composition” relationship means 1 interface is related to only 1 active
structure element, which is a curious constraint in such an abstract model.
The annotations at
level 1 refer to relationship types at level 3, which makes level 1 look
like a level 2 model.
Perhaps a true level
1 model would be even more abstract? Say, just actors <are associated
with> actions?
The relationships at
level 2 are associations between architecture domain-specific, but still
general, entity types.
E.g.
actors <can be assigned to> roles, and services <can be used by>
roles.
The relationships are
labelled with the names of relationship
types that may appear in a level 3 model.
But
only a tiny selection of the possible
inter-entity relationship types.
The Relationship
Table in appendix B allows for more than 1,000 valid relationship types.
It seems curious that
the thousand permitted A-B relationships do not include component
<realizes> interface.
ArchiMate’s general rules can lead to
counter-intuitive results.
The lack of
an explicit type/instance vocabulary in ArchiMate leads to ambiguities in the
text.
It doesn’t distinguish component types from instances, or interface definitions from interface instances.
It defines an interaction as having “two or more elements”, the meaning of which changes if the elements are roles/types or actors/instances.
And yet, there are hints in the text that the type/instance distinction is in the mind of an author.
And of course, there is the role/actor distinction.
UML says behaviors are performed by run-time objects, rather than by the types that define the behaviors those objects can perform.
“all behavior in a modeled system is ultimately caused by actions executed by so-called “active” objects…
ArchiMate says: An active structure
element is defined as an entity that is capable of performing behavior.
Actors perform behaviors, but (strictly speaking)
roles merely group behavior types that actors can or should perform.
In ArchiMate, the valid relationships to and from role and actor are very nearly identical.
Yet, arguably, roles are more like interface/type definitions than they are like individual actors.
ArchiMate says “An active structure element is …as an entity… capable of performing behavior.”
Is the author saying an active structure element is an instance rather than a type?
“The active structure elements are the business actors, application components, and devices that display actual behavior”
Is the author thinking behaviors are performed by instances of these - rather than by types like role and interface?
“A business role is defined as the responsibility for performing specific behavior, to which an actor can be assigned.”
Does this mean the responsibilities of a role are the specified behaviors?
Is the author thinking a role defines behavior(s) that actors are responsible for, but does not perform those behaviors?
Business system architects build system models that conform to usual presumptions about designed systems.
A system can be described in terms of roles, events and behaviours that are instantiated at run-time
The roles, events
and behaviours are designed to serve the purposes of the system owner(s).
The system behavior
is the result of actions performed by actors playing those designed roles.
Actors are
instantiated to perform actions in response to communication events sent by
actors inside or outside the system.
ArchiMate says: “A collaboration is a (temporary) grouping (or aggregation) of two or more structure elements.”
"Collaboration" is a puzzle to me.
It is certainly an N-way association relationship between roles, though the standard doesn’t make this clear.
(If that is an "aggregate" of roles, then the meaning of aggregate is very loose.)
UML represents a collaboration as a group of logical roles in a diagram, but excludes the parts of those roles irrelevant to the associated interaction type.
A collaboration need never be instantiated or maintained as a group of physical actors.
“A collaboration is a (temporary) grouping (or aggregation)
of two or more structure elements.”
“Temporary” implies a life span with a start and end.
Those “structure elements” could be roles or actors.
All types last as long as the model that contains them is unchanged.
A role is a type and must last as long as the system model.
An interaction type (a behavior type involving roles) must last as long.
A collaboration type (a structure type associating roles) must last as long.
An interaction instance lasts as long as the interaction type dictates.
But actors in it may come and go, or even be replaced.
To optimise for speed, actors may be instantiated before an interaction, and maintained for later interactions
To economise on space, actors might be instantiated or withdrawn during an interaction.
So it is difficult to say when a collaboration of actors is instantiated, if ever.
Does a footballer manager play the same 11 players in every match?
You might design a system to keep the N actors available for successive interactions the same type.
You’d have to think hard about when to instantiate the N actors, when to withdraw them, and whether an actor is allowed to do anything else.
After all, the same actors may be required for different kinds of interactions assigned to different collaborations.
Is a football team a collaboration between matches?
When actors are resting between interactions, or busy doing something else, does the collaboration still exist?
In general, managers replace players between matches, and even within one match.
The actors in a collaboration may come and go, and be replaced by other actors.
There is no need for all actors in one collaboration, or even one interaction, to be instantiated at the same time
So to define a collaboration instance as having a life span doesn’t generally make sense.
The notion of a collaboration as an “active structure element” is questionable.
A collaboration type associates
the N roles that are involved in one or more interaction types.
Arguably, the collaboration type is a more like N-way association relationship than it is like a component instance.
A Business
Collaboration <can compose> a Business Role.
Generally, a role is not part of one
and only one collaboration - which the composition relationship dictates.
But OK, in a specific level 3 model, a named role could possibly be part of one and only
one named collaboration
A Business
Collaboration <can aggregate> a Business Actor.
The business
domain chapter relates collaboration only to role, which feels more like
UML.
But
OK, the Business actor here must be the name
of an actor in a level 3 model, rather than a real actor at level 4.
Since
any actor in a model is a surrogate for role, a collaboration
between actors is still a concept, a type.
How
can a Business
Collaboration <specialize> a Business Role, yet not inherit all a Business role’s
relationships?
I don’t understand what the reverse
relationship means: a Business Role
<can specialize> a Business Collaboration.
Also, at first sight, this
two-way specialization appears to create an endless recursive loop of property
extension.
ArchiMate doesn’t (but perhaps
could) disallow two-way specialization relationships in a particular level 3
model.
If you want to say A is
exactly the same as B, then you can define A and B as
having the same properties.
It seems application
collaboration and application component share every relationship to and
from other things.
So,
why say Application Collaboration <specializes> Application Component, when it does not actually specialize it
Is an application
collaboration exactly the same as an aggregate application component or not?
If an
application collaboration be deployed as an application component
can be, why do we need application collaboration as a concept?
ArchiMate
doesn’t officially draw a type/instance distinction, but it does surface here
and there.
It distinguishes roles from individual actors (so people can name actors in models where there is only one actor in a role).
The
valid relationships to and from role and actor are almost identical, but not
exactly the same.
The
only difference is that a business collaboration
cannot be composed of or specialize a business actor.
OK,
this difference suggests collaboration is a type, like a role, rather than an instance, like an
actor.
Again…
At the type level, a collaboration
associates N roles involved in one or more interaction types.
Arguably, the collaboration type is a more like N-way association relationship than it is like a component instance.
This is one of more
than 200 papers at http://avancier.website.