Where did "instance" go?

[Rhys Lewis 2]

I've just upgraded to v15, and when I drag an element onto a diagram from the project browser I can only choose "Child" or "Link".  In the past there was also "Instance".  Child has some similarities to Instance, but all my objects are currently instances, so it would be a pain to swap over.

Is there still a way to do instances?

[KP]

That dialog provides different choices in different contexts, so what kind of element are you dragging from the Project Browser and what kind of diagram are you dropping it onto?

[Rhys Lewis 2]

It happens with a few things.  A situation I'm in a lot is creating a classifier as an Archimate 3 Technology element, such as TechnologyObject or ArchiMate_Node.  Then I will create an Archimate 3 Technology diagram and drag the Archimate_Node from the project browser to the diagram.

For example, I might create an ArchiMate_Node that is "Switch", then drag the switch onto a Archimate 3 Technology diagram, where I want it to be "Server Room: Switch", an instance of a switch that is the one in the server room.

One of the good things about Instances when you are doing Archimate 3 diagrams is that the raw elements (eg. ArchiMate_Node) don't show their elements (attributes, tags etc.) in a diagram, but an instance does.

[Modesto Vega]

I am not sure an Instance is the best/correct way of doing this.

A Switch element is at the logical level of abstraction (or above). A specific Switch, is  equipment, it can only be depicted in a physical diagram, it has a physical level of abstraction. Personally, I would hesitate to use an Instance relationship for this, if not using ArchiMate, and it is unlikely to be legal in ArchiMate 3, as KP noted.

If you must model at both the technology and physical levels, I would use a Device for the logical Switch, possibly a Node for the room, an Equipment element for the physical Switch and a permitted relationship between the the Device and Equipment (likely) to be some sort of generalisation/specialisation.

[Glassboy]

One of the good things about Instances when you are doing Archimate 3 diagrams is that the raw elements (eg. ArchiMate_Node) don't show their elements (attributes, tags etc.) in a diagram, but an instance does.

Instances are a UML concept.  They're not part of ArchiMate.

[Rhys Lewis 2]

The Archimate 3 specification anticipates the issue of specific instantiation, and implicitly delegates it to UML representations that sit outside the "Enterprise Architecture". (see below)

It really gets back to the problem of Theseus' ship.  The switch in the server room and the switch in the guard cabinet are both switches, but they are not the same switch.  We can speak of "switch" as well as "the" switch, and these are both valid speech acts in the business context.  Then when we upgrade the switch in the guard cabinet to PoE, it is still the instance of a switch that exists in that cabinet.  In this sense it shares an ontological continuity with the previous unpowered switch, but can no longer be considered to be the same physical object.  It is possible to place them side by side and observe that they are in fact different objects.

Which reminds me of my original question.  Where did the instance option in the dialog box go?

https://pubs.opengroup.org/architecture/archimate3-doc/chap03.html#_Toc489945972

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

[KP]

I believe the instance option has been explicitly removed for ArchiMate elements. Because ArchiMate doesn't model instances. Rhys' quote is spot on in that regard:

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

It is not modeled in the Enterprise Architecture, from which I infer that instances should be modeled outside of the ArchiMate model, for example on a UML Object diagram.

[Rhys Lewis 2]

Thanks - that explains it then.  I've experimented with some more combinations, and it appears that the diagram type makes no difference, but the Archimate elements have had the Instance option removed.

[Paolo F Cantoni]

I believe the instance option has been explicitly removed for ArchiMate elements. Because ArchiMate doesn't model instances. Rhys' quote is spot on in that regard:

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modelled in the Enterprise Architecture.

It is not modelled in the Enterprise Architecture, from which I infer that instances should be modelled outside of the ArchiMate model, for example on a UML Object diagram.

That's a bit unfortunate because ArchiMate 3 says in section 8.2.1 Business Actor:
A business actor may be assigned to one or more business roles. It can then perform the behaviour
to which these business roles are assigned. A business actor can be aggregated in a location. The
name of a business actor should preferably be a noun. Business actors may be specific
individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic;
e.g., “Customer” or “Supplier”.

What are “John Smith” and “ABC Corporation” other than specific instances of actors?
Additionally, as I've mentioned before, describing  “Customer” and “Supplier” as "generic" is conceptually invalid.

We've taken the view that ArchiMate is primarily about instances (yes, it doesn't make much distinction between classifiers and instances, because there are very few real Classifiers)  some instances are specific instance such as “John Smith” and “ABC Corporation” and others are placeholder instances such as “a Customer” and “a Supplier”.

Once we made the mental shift above, we were able to make models that we both rigorous and expressive of reality.

We believe (part of) the problem is that people misapply the metaphor of Class and (runtime) Object to ArchiMate models.

Just my AU$0.05.

Paolo

(Let's hear it for self-inconsistent standards! )

[Modesto Vega]

The Archimate 3 specification anticipates the issue of specific instantiation, and implicitly delegates it to UML representations that sit outside the "Enterprise Architecture". (see below)

It really gets back to the problem of Theseus' ship.  The switch in the server room and the switch in the guard cabinet are both switches, but they are not the same switch.  We can speak of "switch" as well as "the" switch, and these are both valid speech acts in the business context.  Then when we upgrade the switch in the guard cabinet to PoE, it is still the instance of a switch that exists in that cabinet.  In this sense it shares an ontological continuity with the previous unpowered switch, but can no longer be considered to be the same physical object.  It is possible to place them side by side and observe that they are in fact different objects.

Which reminds me of my original question.  Where did the instance option in the dialog box go?

https://pubs.opengroup.org/architecture/archimate3-doc/chap03.html#_Toc489945972

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

The Theseus' ship problem is about levels of abstraction,

• a Switch is a concept, it does not belong to the technology or physical views (though) with a somersault you may be able to squeeze it into the the logical view)
• a Switch in a guard house is a logical element, it belongs to the technology view
• the Switch in the guard house of Bishop Rock in the Isles of Scilly (assuming there is one) is physical equipment and belongs to the physical view

2 other points:

• please note the use of articles - i.e., a switch, a guard house, a switch in a guard house, the switch. It is very important, "The" denotes physicality.
• you cannot model the relationship between these 3 levels - i.e., conceptual, logical/technology, and physical - using an Instance relationships because they are not really instances of the same object. It is not correct to model abstraction using Instance relationships.

[Paolo F Cantoni]

[SNIP]
2 other points:

• Please note the use of articles - i.e., a switch, a guard house, a switch in a guard house, the switch. It is very important, "The" denotes physicality.
• you cannot model the relationship between these 3 levels - i.e., conceptual, logical/technology, and physical - using an Instance relationship because they are not really instances of the same object. It is not correct to model abstraction using Instance relationships.

Yes, we came to the same conclusion about placeholder instances. they should be preceded by the indefinite article.

Paolo

[Modesto Vega]

I think the answer to the original question is simple: Instances in this context are not permitted and Sparx 15 has gotten better at enforcing this.

I believe the instance option has been explicitly removed for ArchiMate elements. Because ArchiMate doesn't model instances. Rhys' quote is spot on in that regard:

The ArchiMate language intentionally does not support a difference between types and instances. At the Enterprise Architecture abstraction level, it is more common to model types and/or exemplars rather than instances. Similarly, a business process in the ArchiMate language does not describe an individual instance (i.e., one execution of that process). In most cases, a business object is therefore used to model an object type (cf. a UML class), of which several instances may exist within the organization. For instance, each execution of an insurance application process may result in a specific instance of the insurance policy business object, but that is not modeled in the Enterprise Architecture.

It is not modeled in the Enterprise Architecture, from which I infer that instances should be modeled outside of the ArchiMate model, for example on a UML Object diagram.

[SNIP]
We believe (part of) the problem is that people misapply the metaphor of Class and (runtime) Object to ArchiMate models.

The fact that ArchiMate does not differentiate between types and instances does not mean that

• It cannot handle types and instances
• It cannot handle the physical aspect, the Equipment View must be to handle the physical aspect of an implementation.

Instantiation is not about physical things, it is about soft(ware) things. You create an instance of a class which becomes a soft(ware) object and not a physical object. Classes are templates for soft(ware) objects.

A physical object, the laptop I am using to write this, is not an instantiation of a class (or abstract Kantian category). Instantiation cannot apply to physical objects. Physical objects (or whatever device is used to model them) are "of a type" and this can be represented through generalisations/specialisations.

You could even argue that using Classes for abstract/conceptual modelling, the bread and butter of enterprise architecture, is a potential misuse of the original concept of class. Classes were introduced to help with object oriented programming.

[Paolo F Cantoni]

[SNIP]
You could even argue that using Classes for abstract/conceptual modelling, the bread and butter of enterprise architecture is a potential misuse of the original concept of class. Classes were introduced to help with object-oriented programming.

Yes, Modesto,  That's the conclusion we've come to.  We don't use classes and (run-time) objects, we use instances and classifiers.

Paolo

[Rhys Lewis 2]

2 other points:

• please note the use of articles - i.e., a switch, a guard house, a switch in a guard house, the switch. It is very important, "The" denotes physicality.
• you cannot model the relationship between these 3 levels - i.e., conceptual, logical/technology, and physical - using an Instance relationships because they are not really instances of the same object. It is not correct to model abstraction using Instance relationships.

There is another reason why you cannot model this relationship.  It's because Sparx took it away!

If you stick with the "you can do anything" class diagram, when an object is an instance you can right click on it and choose Advanced | Instance Classifier, and go to the thing that it is an instance/specialization/etc. of.  However if an object is a child, then that is not available from the context menu any more.

So according to the https://www.philosophybasics.com/movements_pragmatism.html school, a thing is true if it works.  And it worked in the previous version.

I know someone is going to take the multiverse approach and say that you could use the relationship toolbox to see relationship, but I would argue it doesn't apply in this context (box), which is the problem.

[Glassboy]

It's Monday morning, I've just started my second coffee and I probably watched too much rugby over the weekend but there some basic ontological (not the computer science definition) issues with the discussion since I last participated.

It's clear that ArchiMate - as it so often does - uses the common English meaning;  instance (basically a thing) not the computer science meaning - a thing that can be created through instantiation.  One should never forget that ArchiMate is created by a committee of marketers who still fondly remember floppies and mainframes.

Also the example of switches, do they have the same set of Technology Functions.  Well no if only one of them has PoE.  Therefor they are not the same node/device.  Nor are they realized from the same node/device.  Might they both serve they same Technology Service, yes they might.

Does any of the discussion about switches using the definite or indefinite article belong in ArchiMate, No!  Could we model this as a [computer science] ontology using a UML class diagram, why yes we can.

Does Sparx Enterprise Architect offer us a hammer only?  Why no it doesn't.  Because every problem isn't a nail.