RV
Hi, this is a call for a change in how ARIS handles ArchiMate models, and also BPMN models regarding persistency in the database.
Below you can find a citation from the documentation, related to how ARIS handles UML models.
This is a crucial feature for UML, however I would like to argue that it is as crucial for ArchiMate, but (somewhat less so) also for BPMN.
Why? For UML the argumentation can be applied without changes to ArchiMate. ArchiMate is inspired by UML, and architects creating ArchiMate models usually have the same approach: you design your objects, and the views are created for the stakeholder communications, not to create your architecture. ArchiMate elements are not defined by the views they are in, as in UML they are completely independent from those views.
For BPMN this is less so, because Pools are the containers of a process, but a Pool must still be reusable across views/diagrams. This goes for black-box pools as well as white-box pools. This is about reusability of Actors (Participants). Reusability of Lanes (related to Roles) is also valid, however only in the context of one containing top-level pool: we want to reuse a lane from a parent level in any child level. There are additional semantics such as a flow element cannot be in another lane in a child-level process than in a parent-level (unless that lane is a sub-lane).
From the documentation site:
"There is a fundamental difference between the classic ARIS Method and UML that has major effects on how you use ARIS Architect/ARIS Designer and ARIS UML Designer.
In UML, the semantics of a model (not a diagram) are completely contained in its elements and their properties and relationships. Diagrams merely represent a graphical view of the model. If you were to delete all UML 2 diagrams in an ARIS database, the semantics of the UML model would be fully retained. In addition, many UML elements are not represented graphically in diagrams and appear there in text form at most within the graphical presentation of a superior element.
In ARIS Method, diagrams have a much greater significance. For some ARIS objects, the symbol by which they are represented graphically in a diagram actually determines their semantics. As a consequence, the diagrams in ARIS Method make a significant contribution to the semantics of the model. Conversely, objects and relationships that are not represented graphically in a diagram are irrelevant in ARIS Method.
During database reorganization all ARIS objects and ARIS relationships with no occurrence in a diagram are therefore deleted. By contrast, UML 2 elements are retained after database reorganization, as merely the fact that a UML element is not represented in any diagram does not reveal whether or not it is still required."
Additionally: if (and hopefully when) Pools are persistent, this needs to be for the connecting message flows as well, I mean I should be able to select a Pool and see all connecting message flow in all diagrams in ARIS. Forgive me if this is already the case, I have not yet seen this feature.
Hello Rob,
ideally you use ARIS models and objects also in a way, that you could remove all model diagrams and the logic would be retained. So reusing Task and event objects between multiple process (e. g. BPMN) models is a no-go. You would get ambiguities immediately because of additional predecessors and successors of a task that are not valid in the context of your process.
Small but important exception to this: The "assignment" mechanism of a model to an object usually is a structurally relevant information, where you would lose information, if you didn't have the model any more with the occurrences inside.
BPMN Pools: They are ARIS objects of type Participant. So yes, I would encourage you to reuse the Participant object from a white-box pool wherever necessary as black-box pool in other collaboration diagrams. You can support navigation by assigning the model to it, where you model it as white-box pool. Any message flows, that connect to the border of the pool show in the relationships tab of the properties window of the pool object. However message flows that cross the Pool border in your white-box model of the Pool do not, because they connect to the events and tasks inside the pool. You should consider introducing consistency checks (as "semantic checks") that check every message flow to be represented in both models participating in a collaboration. This is to avoid the scenario that you emit a message to a black box pool that is not handled in the other model, where the black-box pool is modelled as white-box.
Symbols and semantics: Indeed, it is common practice to use symbols to do a kind of "subclassing" of object types. Every ARIS object can have a "Default symbol" that is stored with the object's definition. This symbol will represent the object in the Explorer view of the ARIS database. It will be retained, even if the last occurrence of the object in any model is removed (until reorganization collects the object itself). This symbol also shows in matrix models by default. And it is used when pasting object definitions to a model canvas (provided the symbol is allowed in the respective model type). There are cases when the same object is shown in different models with different symbols. E. g. a role object is shown in a role library and org. chart with the role symbol and it may occur in an Enterprise BPMN Collaboration model as a Lane.
Lanes: Most of the time Lanes represent roles, sometimes also org. units or application system types are used as lanes. ARIS supports this in the model types "Enterprise BPMN collaboration diagram" and "Enterprise BPMN process diagram". I would discourage reusing flow elements in different process levels for the reasons I described above: You would become dependent on the process model diagram for the semantic of the process model.
Keep in mind that Lanes do not have any particular meaning for the process except for grouping tasks in the layout following a user-dependent convention (e. g. "performing role"). Change the convention and you could re-layout your process without changing it semantically. Particularly Lanes do not support layering. You can model Lanes inside Lanes, but usually this does not add much value, that you couldn't depict better in an org. chart (or other model). Also you probably do not want to mis-use the process model as an org. chart, introducing redundant information to such models in your process model. This can become an issue maintaining this structure.
EDIT: To make one thing clear. All ARIS objects and their connections exist as a definition, which carries the actual model information (attributes). Their depiction in diagrams ("models") is separate from that. Each object and connection may "occur" in one or many models. So every object and connection do have an identity and may be viewed ("it occurs") in many models - or not at all. There are ways to protect objects from being collected by the garbage collector (aka reorganization) although they may not have any occurrence in a model.
Think of Lanes as an occurrence of the object you want to group your flow objects by - e. g. a role. Then it is a natural thing to have the identical role object represented as a lane in another pool that uses the same role.
Thanks a lot for your extensive reply! Indeed, my intention never was to reuse flow elements, just the Pools, connected message flows, and Lanes. I totally agree that flow elements are process-scope. Keep in mind however that I am working with models on three levels: ArchiMate (more abstract and conceptual), and BPMN and UML (for the detailed more elaborated designs). The alignment between these models would be greatly improved when BPMN actors and roles can be directly linked to ArchiMate actors and roles. The top levels of a decomposed process also occur as ArchiMate process elements (as do the top levels gateways and triggering events btw, but that is maybe for another topic). Therefore for these elements to be persistent in the ARIS database is essential. You did not speak about persistency in your response? And also not on my request for ArchiMate elements to be treated similar to UML elements? (and the subset of BPMN elements discussed)
The archimate objects are all equal citizens to ARIS objects. They are just ARIS objects with Archimate symbols in the model views. Object definitions are persistent in the database. They reside in the group structure ("folder structure") of the ARIS database. When you look at your Archimate model, select an Archimate role and take a look at the "Type" property. It is "Role". It is the same object type as an ARIS role or a role lane in an Enterprise BPMN collaboration model. So you can use your Archimate role directly as a Lane in your BPMN model. The type of "Business actor" is mapped to the ARIS type Org. unit. This also can be used as a lane in Enterprise BPMN collaboration models. Archimate "Business Process" symbols are of ARIS object type "Participant", which (not incidentally) is the same type as the Pool symbol in Enterprise BPMN models. So you can directly use your Business Process objects in BPMN models as Pools. My 2 cents: Assign an Enterprise BPMN collaboration model to your Business Process and make an occurrence of this business process in the model. If you copy&paste the Business Process object from your Archimate model to the Collaboration model, it should be pasted directly as a Pool symbol. These are perfect examples, where the same (persistent) objects have got two different symbols in two different model types.
UML models and objects are a bit different: They also reside in the ARIS database in UML packages. They are managed by the UML designer client only, because UML behaves differently from how ARIS manages objects and connections beween objects. A UML connection involves no less than 5 UML objects. You can configure that certain UML objects shall be synchronized with ARIS objects, so they are kept in sync when you edit either of them.
