Model projects/meetings w ArchiMate

[Hurra]

Hello!

We are modelling with ArchiMate 3 and, right now, focus on the business/organizational layer. We will in a later stage reach the application/technology layers.

I was asked to include meetings in our model. I was told to model the meetings to be able to trace participants, meeting protocols, decisions etc. It got me thinking what element to use.

My first idea was Business Event, but a Business Event is instantaneous: it does not have duration (according the the ArchiMate specification).

The Business Process could be used. It accesses Business Objects, i.e. meeting protocols etc, and can have Business Roles/Actors assigned to it.

What about Business Interaction?

Is there any other element I don't think about? We have Implementation Events and Work Packages in other parts of our model.



I also thought about how I should model these meetings...

Should I do a generic model, like Meeting A always has output of Report A, and create instances for actual meetings/reports or only create instances? E.g Meeting 18-02-20 have output Report 18-02-20, with participants Business Actor A/B/C.



Perhaps there is another option in EA without elements, in project management?



I have my doubts about meetings...

Any thoughts?

Robert

[Glassboy]

Given your optimism why aren't you using a business collaboration :-)

[Paolo F Cantoni]

Given your optimism why aren't you using a business collaboration :-)

Indeed! The meeting is a business collaboration, the business interaction is what happens in the meeting!

See ArchiMate 3.0 8.2.3

Paolo

[Hurra]

Thank you for your replies.

I will use the business collab for meetings.

My plan is to create a business collab for each kind of meeting, like "Monthly x meeting", and create instances for each such meeting, "Monthly x Feb 18".

Incorrect but consistency is the way right? 


edit:

after some more thinking, and reading the ArchiMate specification, I wonder. Do I really need the Business Collaboration? The actual meeting is a Business Interaction, and to this element I connect Business Objects like protocols etc. Can't I skip the step with Collaboration and relate relevant actors/roles directly to the interaction, and not via the collaboration?

What we in the end are interested about are the documents/reports/decisions that the meeting produce, which is Business Objects related to the Business Interaction.

My thought process is that

Business Collaboration is an internal active structure element
Business Interaction is an internal behaviour element
Business Object is a passive structure element

and the passive structure element relates to the internal behaviour element, not the internal active structure element.

[Glassboy]

My plan is to create a business collab for each kind of meeting, like "Monthly x meeting", and create instances for each such meeting, "Monthly x Feb 18".

Archimate doesn't have instantiation.  You could create your archetype meeting and then use aggregation to the actual meetings.

[Paolo F Cantoni]

My plan is to create a business collab for each kind of meeting, like "Monthly x meeting", and create instances for each such meeting, "Monthly x Feb 18".

Archimate doesn't have instantiation.  You could create your archetype meeting and then use aggregation to the actual meetings.

Glassboy is right, of course...  See ArchiMate 3.0 3.6... "The ArchiMate language intentionally does not support a difference between types and instances."
Unfortunately, in real life, we deal with instances.  You can use Archimate to hold instances, many ArchiMate items are (in fact) "instances" .Specific Roles for example.  Each Monthly meeting is a specific instance of the Monthly meeting template.

My reading of the spec is that you can't do without the Business Collaboration.   However, you can link the business objects to whichever you believe they are directly connected to and then create a derived relationship to the other element.  See  5.6 Derivation Rules.

Paolo

[Hurra]

My plan is to create a business collab for each kind of meeting, like "Monthly x meeting", and create instances for each such meeting, "Monthly x Feb 18".

Archimate doesn't have instantiation.  You could create your archetype meeting and then use aggregation to the actual meetings.

Glassboy is right, of course...  See ArchiMate 3.0 3.6... "The ArchiMate language intentionally does not support a difference between types and instances."
Unfortunately, in real life, we deal with instances.  You can use Archimate to hold instances, many ArchiMate items are (in fact) "instances" .Specific Roles for example.  Each Monthly meeting is a specific instance of the Monthly meeting template.

My reading of the spec is that you can't do without the Business Collaboration.   However, you can link the business objects to whichever you believe they are directly connected to and then create a derived relationship to the other element.  See  5.6 Derivation Rules.

Paolo

What do you mean "can't do w/o the Business Collaboration"?

I was thinking something like this (I know it looks terrible but it's for discussion purposes only  ):
https://imgur.com/9hHLcSd

What you're saying is at the top I should add Business Collaboration between the Interactions and Actors/Roles? Why can't I related the Interactions directly to the Actors/Roles? If I "define" a Business Collaboration with Actor A, B and C, and we use the relation too see participants, and not all Actors/Roles of the Collaboration are present, this would represent false data..? However if I connect to Actor/Role directly I get more flexibility and freedom!

Oh, or are you saying that each "instance" of the interaction, lets say the Business Interaction feb 2018, has a "instance" of Business Collaboration related to it, Participants feb 2018?




I have another ArchiMate specific question regarding the Business Object, let me know if you think this deserves another thread.

The Business Object relate to a lot of other element with the "access" relation. However, to my understanding, this relationship is only allowed one way. From x -> Business object, but not the other way around. I can change the direction of the relation, but I think this is only a visual change? If I reverse the direction, I am not longer following the ArchiMate metamodel. Is this statement correct?

[Glassboy]

I was thinking something like this (I know it looks terrible but it's for discussion purposes only  ):
https://imgur.com/9hHLcSd

The aggregation looks to be the wrong way around.

I have another ArchiMate specific question regarding the Business Object, let me know if you think this deserves another thread.

[Paolo F Cantoni]

If you accept that the Collaboration IS the meeting and the Interaction is what happened in the meeting, then the Interaction without the Collaboration is essentially meaningless. The Collaboration provides the structural context for the interaction.

I agree with Glassboy that the Aggregation is the wrong way round.  In fact, I would question that the relationship between the "instance" of the meeting and its "type" (I'm using the terms a little loosely) is one of aggregation.  We created a new relationship "instanceOf" to describe that link.

The relationship between the meeting "type" and its "instances" is analogous, in my view, to the relationship between types and instances for what we, here, call "Rosterable Item".  A rosterable item is one where one can allocate a specific instance of a resource type to a specific timeslot.  We plan, schedule and roster and then have actuals.  We plan and schedule using resource types and roster using resource instances, actuals record the actual instances involved in the slot, the roster representing the forecast for the slot.  I believe the analogy works well.  You have resource type Monthly Meeting about X, which requires resource types of Chairperson, members of various types.  You plan on "5" meetings, say. You schedule them for the next 5 months.  Then you look for instances to roster against those types for those dates.

Thus, in order to model this correctly, you have to model the meeting type against the participant types and the business object types and then create relationships to the instances of all those types that represent the roster or actuals - depending on whether the date of the meeting is in the past or future.

While ArchiMate, as we said doesn't support the difference between types and instances, in section 8.2.2 Business roles, it does talk about the distinction between generic and specific business actors.  In my view, the term generic is not correct, but the term specific surely refers to an instance.  Elsewhere in the forum I have talked about the "generic" actually being a specification for a query that defines a placeholder into which a conforming specific instance can be substituted.  So we would have "forum participant" (the placeholder) and "RWHurra" the specific instance.

HTH,
Paolo

[Glassboy]

While ArchiMate, as we said doesn't support the difference between types and instances, in section 8.2.2 Business roles, it does talk about the distinction between generic and specific business actors.  In my view, the term generic is not correct, but the term specific surely refers to an instance.  Elsewhere in the forum I have talked about the "generic" actually being a specification for a query that defines a placeholder into which a conforming specific instance can be substituted.  So we would have "forum participant" (the placeholder) and "RWHurra" the specific instance.

Yeah I think unless you model archtypes (generic) elements, Archimate doesn't actually work very well.

[Paolo F Cantoni]

Yeah, I think unless you model archetypes (generic) elements, Archimate doesn't actually work very well.

I like the use of archetype - it's the pattern or model from which the instances are categorised.  In normal usage, we refer to the archetype through the instance. For example, we might assert that Glassboy is a typical Kiwi.  Kiwi is the archetype and Glassboy the instance.

This fits in with my view of the non-specific thing, being a queryable specification.  We can use the archetype (at whatever level of generalisation) to query the base type and determine if Glassboy is included in the set of persons who are Kiwis.  In our modelling, if the item (say an actor) has to be a Kiwi, we create an actor whose name is "a Kiwi" and, if required, link those (specific actors) persons who are Kiwis to that.

As I write, it occurs to me that one could describe the actor  "a Kiwi" as specifying "a (generic) Kiwi".  So I appear to have out-argued myself!  It is Friday!

Further, if we specify all the values of the properties of the item, then we have a specific item.  Where we allow at least one property to be "independent", we have a generic item.  The specified property values define the query to replace the placeholder generic with the confirming instance (where required).

Paolo

[Hurra]

I am trying to avoid adding custom elements/relationships and using standard ArchiMate.

I have modelled a small example based on your last comments. Let me know what you think.

https://imgur.com/Orul5RS

Relationship between elements
Collaboration -> Collaboration: composition
My argument is that if CWIX ESC dies, all "instances", i.e. CWIX ESC 2018/9... dies as well.

Actor/Role -> Collaboration: serving.
I have no argument, let me know why I shouldn't use this 

Collaboration -> Interaction: assignment
I see the collaboration as a kind of participant holder, therefore the actors/roles in the collaboration is assigned to the interaction.

Interaction -> Business Object: access
This sounds to me as the interaction read/use the business object. How do I point out that the interaction creates a business object?

Am I getting somewhere?

[Glassboy]

This fits in with my view of the non-specific thing, being a queryable specification.  We can use the archetype (at whatever level of generalisation) to query the base type and determine if Glassboy is included in the set of persons who are Kiwis.  In our modelling, if the item (say an actor) has to be a Kiwi, we create an actor whose name is "a Kiwi" and, if required, link those (specific actors) persons who are Kiwis to that.

Well I come at it from a slightly more prosaic perspective.  For example if you model an environment of servers for Microsoft Exchange it's thoroughly redundant and messy to attach technology interfaces and technology functions to every node.  It's necessary to have the information available, but counter productive to have it everywhere.

[Paolo F Cantoni]

This fits in with my view of the non-specific thing, being a queryable specification.  We can use the archetype (at whatever level of generalisation) to query the base type and determine if Glassboy is included in the set of persons who are Kiwis.  In our modelling, if the item (say an actor) has to be a Kiwi, we create an actor whose name is "a Kiwi" and, if required, link those (specific actors) persons who are Kiwis to that.

Well I come at it from a slightly more prosaic perspective.  For example if you model an environment of servers for Microsoft Exchange it's thoroughly redundant and messy to attach technology interfaces and technology functions to every node.  It's necessary to have the information available, but counter productive to have it everywhere.

Would that modelling application (programs) handled these properly...

Paolo

[Paolo F Cantoni]

I am trying to avoid adding custom elements/relationships and using standard ArchiMate.

I have modelled a small example based on your last comments. Let me know what you think.

https://imgur.com/Orul5RS

Relationship between elements
Collaboration -> Collaboration: composition
My argument is that if CWIX ESC dies, all "instances", i.e. CWIX ESC 2018/9... dies as well.

Actor/Role -> Collaboration: serving.
I have no argument, let me know why I shouldn't use this 

Collaboration -> Interaction: assignment
I see the collaboration as a kind of participant holder, therefore the actors/roles in the collaboration is assigned to the interaction.

Interaction -> Business Object: access
This sounds to me as the interaction read/use the business object. How do I point out that the interaction creates a business object?

Am I getting somewhere?

FWIW, destruction of the components is a consequence of Composition, not a rationale for it.  Destruction of the Classifier (Archetype) should cause the destruction of the instances, but that's because of the characteristics of the InstanceOf relationship.

Just my AU$0.05

Paolo