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.
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 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.
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:That's a bit unfortunate because ArchiMate 3 says in section 8.2.1 Business Actor:QuoteThe 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.
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)The Theseus' ship problem is about levels of abstraction,
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#_Toc489945972QuoteThe 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.
[SNIP]Yes, we came to the same conclusion about placeholder instances. they should be preceded by the indefinite article.
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.
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:QuoteThe 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.
[SNIP]Yes, Modesto, That's the conclusion we've come to. We don't use classes and (run-time) objects, we use instances and classifiers.
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.
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.
Once upon a time there was a very accurate heliocentric astronomical prediction model that used the concepts of nested spheres and epicycles to predict the movement of celestial bodies. For centuries it was “true”, and it took centuries of observations to find it inaccurate.
So according to the https://www.philosophybasics.com/movements_pragmatism.html (https://www.philosophybasics.com/movements_pragmatism.html) school, a thing is true if it works. And it worked in the previous version.
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.My argument is that if ArchiMate uses the common meaning of instance, it is inappropriate to use the computing science meaning of instance. Using the computing science meaning just confuses matters.
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.Considering that not all switches have the same technology functions, a proper ontology model using a UML class diagram may be required depending, of course, on the modelling problem at hand - if all switches in the modelling scope are POE, this may not be required.
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.
Once upon a time there was a very accurate heliocentric astronomical prediction model that used the concepts of nested spheres and epicycles to predict the movement of celestial bodies. For centuries it was “true”, and it took centuries of observations to find it inaccurate.
So according to the https://www.philosophybasics.com/movements_pragmatism.html (https://www.philosophybasics.com/movements_pragmatism.html) school, a thing is true if it works. And it worked in the previous version.
Because something was “true”, it doesn’t have to be “true” now. Likewise because you could do it in v13 doesn’t mean it was correct, “true”. If we adopt that mindset we will never have progress, in general, and technological progress, in particular; we will still be stuck with punch cards and mechanical computers.
literally hold their code in their hands*twitch* :-X
When you are at the "normal science" part of the Kuhn cycle it is easy to look back at previous paradigms and imagine that this time we have it right. Pragmatism says that there is only true "now". Taken from the frame of reference of v.13, it was true at that moment. v.15 is seeking to establish a new truth that is merely a misguided novelty.What makes the v13 truth valid but the v15 truth become novelty?
<?xml version="1.0" encoding="windows-1252"?>
<xmi:XMI xmi:version="2.1" xmlns:uml="http://schema.omg.org/spec/UML/2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:thecustomprofile="http://www.sparxsystems.com/profiles/thecustomprofile/1.0" xmlns:EAUML="http://www.sparxsystems.com/profiles/EAUML/1.0" xmlns:Profile_Constraints="http://www.sparxsystems.com/profiles/Profile_Constraints/1.0">
<xmi:Documentation exporter="Enterprise Architect" exporterVersion="6.5"/>
<uml:Model xmi:type="uml:Model" name="EA_Model" visibility="public">
<packagedElement xmi:type="uml:Profile" xmi:id="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" name="ArchiMateInstances" visibility="public">
<packagedElement xmi:type="uml:Stereotype" xmi:id="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854" name="ArchiMate3::ArchiMate_Node" visibility="public" isAbstract="true"/>
<packagedElement xmi:type="uml:Stereotype" xmi:id="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" name="Device" visibility="public">
<ownedAttribute xmi:type="uml:Property" xmi:id="EAID_2FF8B6E7_5682_4af3_8220_9BE405A1D256" name="_metatype" visibility="public" isStatic="false" isReadOnly="false" isDerived="false" isOrdered="false" isUnique="true" isDerivedUnion="false">
<lowerValue xmi:type="uml:LiteralInteger" xmi:id="EAID_LI000001_5682_4af3_8220_9BE405A1D256" value="1"/>
<upperValue xmi:type="uml:LiteralInteger" xmi:id="EAID_LI000002_5682_4af3_8220_9BE405A1D256" value="1"/>
</ownedAttribute>
</packagedElement>
<packagedElement xmi:type="uml:Dependency" xmi:id="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3" visibility="public" supplier="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854" client="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F"/>
<packagedElement xmi:type="uml:Dependency" xmi:id="EAID_C575B08F_87E3_4597_9829_1526C14AE85A" visibility="public" supplier="EAID_878F289B_EF83_4034_919D_750B40797FED" client="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F"/>
<packagedElement xmi:type="uml:Class" xmi:id="EAID_878F289B_EF83_4034_919D_750B40797FED" name="Object" visibility="public"/>
</packagedElement>
<Profile_Constraints:metaconstraint base_Dependency="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3" umlRole="classifier"/>
<thecustomprofile:metaclass base_Class="EAID_878F289B_EF83_4034_919D_750B40797FED"/>
<EAUML:profile base_Package="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617"/>
</uml:Model>
<xmi:Extension extender="Enterprise Architect" extenderID="6.5">
<elements>
<element xmi:idref="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" xmi:type="uml:Package" name="ArchiMateInstances" scope="public">
<model package2="EAID_C8A75B7D_1FB3_48a8_9451_F1CB99203617" package="EAPK_9C9D301B_B54D_44fb_898A_0412497D39AA" tpos="0" ea_localid="1248" ea_eleType="package"/>
<properties isSpecification="false" sType="Package" nType="0" scope="public" stereotype="profile"/>
<project author="ebarnes" version="1.0" phase="1.0" created="2019-09-24 11:21:00" modified="2019-09-24 11:21:19" complexity="1" status="Proposed"/>
<code gentype="Java"/>
<style appearance="BackColor=-1;BorderColor=-1;BorderWidth=-1;FontColor=-1;VSwimLanes=1;HSwimLanes=1;BorderStyle=0;"/>
<tags/>
<xrefs value="$XREFPROP=$XID={E61064EC-79C7-4fbb-8F04-125EFFBE046C}$XID;$NAM=Stereotypes$NAM;$TYP=element property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=profile;FQName=EAUML::profile;@ENDSTEREO;$DES;$CLT={C8A75B7D-1FB3-48a8-9451-F1CB99203617}$CLT;$SUP=<none>$SUP;$ENDXREF;"/>
<extendedProperties tagged="0" package_name="Getting Started"/>
<packageproperties version="1.0"/>
<paths/>
<times created="2019-09-24 11:21:00" modified="2019-09-24 11:21:19"/>
<flags iscontrolled="FALSE" isprotected="FALSE" usedtd="FALSE" logxml="FALSE"/>
</element>
<element xmi:idref="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854" xmi:type="uml:Class" name="ArchiMate3::ArchiMate_Node" scope="public">
<model package="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" tpos="0" ea_localid="15000" ea_eleType="element"/>
<properties isSpecification="false" sType="Class" nType="0" scope="public" stereotype="stereotype" isRoot="false" isLeaf="false" isAbstract="true" isActive="false"/>
<project author="ebarnes" version="1.0" phase="1.0" created="2019-09-24 11:22:15" modified="2019-09-24 11:22:15" complexity="1" status="Proposed"/>
<code gentype="Java"/>
<style appearance="BackColor=-1;BorderColor=-1;BorderWidth=-1;FontColor=-1;VSwimLanes=1;HSwimLanes=1;BorderStyle=0;"/>
<tags/>
<xrefs value="$XREFPROP=$XID={0DDE510A-CA27-40f8-A8C3-FC1FA05CC250}$XID;$NAM=Stereotypes$NAM;$TYP=element property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=stereotype;GUID={344B0ADE-B00C-41d8-8A38-73F1F5D8B498};@ENDSTEREO;$DES;$CLT={D05A372F-86E4-4216-8FAF-BE2E7C273854}$CLT;$SUP=<none>$SUP;$ENDXREF;"/>
<extendedProperties tagged="0" package_name="ArchiMateInstances"/>
<links>
<Dependency xmi:id="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3" start="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" end="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854"/>
</links>
</element>
<element xmi:idref="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" xmi:type="uml:Class" name="Device" scope="public">
<model package="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" tpos="0" ea_localid="14999" ea_eleType="element"/>
<properties isSpecification="false" sType="Class" nType="0" scope="public" stereotype="stereotype" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"/>
<project author="ebarnes" version="1.0" phase="1.0" created="2019-09-24 11:21:44" modified="2019-09-24 11:21:47" complexity="1" status="Proposed"/>
<code gentype="Java"/>
<style appearance="BackColor=-1;BorderColor=-1;BorderWidth=-1;FontColor=-1;VSwimLanes=1;HSwimLanes=1;BorderStyle=0;"/>
<tags/>
<xrefs value="$XREFPROP=$XID={4B5FCA42-3409-43db-A921-26437C41CBF2}$XID;$NAM=Stereotypes$NAM;$TYP=element property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=stereotype;GUID={344B0ADE-B00C-41d8-8A38-73F1F5D8B498};@ENDSTEREO;$DES;$CLT={D427A768-E6EC-467a-ACE8-978765E91F3F}$CLT;$SUP=<none>$SUP;$ENDXREF;"/>
<extendedProperties tagged="0" package_name="ArchiMateInstances"/>
<attributes>
<attribute xmi:idref="EAID_2FF8B6E7_5682_4af3_8220_9BE405A1D256" name="_metatype" scope="Public">
<initial body="Device"/>
<documentation/>
<model ea_localid="1849" ea_guid="{2FF8B6E7-5682-4af3-8220-9BE405A1D256}"/>
<properties collection="false" static="0" duplicates="0" changeability="changeable"/>
<coords ordered="0"/>
<containment position="0"/>
<stereotype/>
<bounds lower="1" upper="1"/>
<options/>
<style/>
<styleex/>
<tags/>
<xrefs/>
</attribute>
</attributes>
<links>
<Dependency xmi:id="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3" start="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" end="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854"/>
<Extension xmi:id="EAID_C575B08F_87E3_4597_9829_1526C14AE85A" start="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" end="EAID_878F289B_EF83_4034_919D_750B40797FED"/>
</links>
</element>
<element xmi:idref="EAID_878F289B_EF83_4034_919D_750B40797FED" xmi:type="uml:Class" name="Object" scope="public">
<model package="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" tpos="0" ea_localid="14998" ea_eleType="element"/>
<properties isSpecification="false" sType="Class" nType="0" scope="public" stereotype="metaclass" isRoot="false" isLeaf="false" isAbstract="false" isActive="false"/>
<project author="ebarnes" version="1.0" phase="1.0" created="2019-09-24 11:21:42" modified="2019-09-24 11:21:42" complexity="1" status="Proposed"/>
<code gentype="Java"/>
<style appearance="BackColor=-1;BorderColor=-1;BorderWidth=-1;FontColor=-1;VSwimLanes=1;HSwimLanes=1;BorderStyle=0;"/>
<tags/>
<xrefs value="$XREFPROP=$XID={ABA818E1-3DC1-47e4-8AA3-B528F8E58BB9}$XID;$NAM=Stereotypes$NAM;$TYP=element property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=metaclass;GUID={651D58B8-71E3-483b-9436-5E8A62EAE46D};@ENDSTEREO;$DES;$CLT={878F289B-EF83-4034-919D-750B40797FED}$CLT;$SUP=<none>$SUP;$ENDXREF;"/>
<extendedProperties tagged="0" package_name="ArchiMateInstances"/>
<links>
<Extension xmi:id="EAID_C575B08F_87E3_4597_9829_1526C14AE85A" start="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" end="EAID_878F289B_EF83_4034_919D_750B40797FED"/>
</links>
</element>
</elements>
<connectors>
<connector xmi:idref="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3">
<source xmi:idref="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F">
<model ea_localid="14999" type="Class" name="Device"/>
<role visibility="Public" targetScope="instance"/>
<type aggregation="none" containment="Unspecified"/>
<constraints/>
<modifiers isOrdered="false" changeable="none" isNavigable="false"/>
<style value="Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Non-Navigable;"/>
<documentation/>
<xrefs/>
<tags/>
</source>
<target xmi:idref="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854">
<model ea_localid="15000" type="Class" name="ArchiMate3::ArchiMate_Node"/>
<role visibility="Public" targetScope="instance"/>
<type aggregation="none" containment="Unspecified"/>
<constraints/>
<modifiers isOrdered="false" changeable="none" isNavigable="true"/>
<style value="Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Navigable;"/>
<documentation/>
<xrefs/>
<tags/>
</target>
<model ea_localid="12150"/>
<properties ea_type="Dependency" stereotype="metaconstraint" direction="Source -> Destination"/>
<documentation/>
<appearance linemode="3" linecolor="-1" linewidth="0" seqno="0" headStyle="0" lineStyle="0"/>
<labels mb=" «metaconstraint»"/>
<extendedProperties conditional=" «metaconstraint»" virtualInheritance="0"/>
<style/>
<xrefs value="$XREFPROP=$XID={54CC631D-C336-4d4e-B0A1-F310B2D71A26}$XID;$NAM=Stereotypes$NAM;$TYP=connector property$TYP;$VIS=Public$VIS;$PAR=0$PAR;$DES=@STEREO;Name=metaconstraint;FQName=Profile Constraints::metaconstraint;@ENDSTEREO;$DES;$CLT={39A9C32B-5E11-40e8-AE90-3DEC035964D3}$CLT;$SUP=<none>$SUP;$ENDXREF;"/>
<tags>
<tag xmi:id="EAID_3482D0E0_17FD_8617_867A_055ABD00B4BC" name="umlRole" value="classifier" notes="classifier"/>
</tags>
</connector>
<connector xmi:idref="EAID_C575B08F_87E3_4597_9829_1526C14AE85A">
<source xmi:idref="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F">
<model ea_localid="14999" type="Class" name="Device"/>
<role visibility="Public" targetScope="instance"/>
<type aggregation="none" containment="Unspecified"/>
<constraints/>
<modifiers isOrdered="false" changeable="none" isNavigable="false"/>
<style value="Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Non-Navigable;"/>
<documentation/>
<xrefs/>
<tags/>
</source>
<target xmi:idref="EAID_878F289B_EF83_4034_919D_750B40797FED">
<model ea_localid="14998" type="Class" name="Object"/>
<role visibility="Public" targetScope="instance"/>
<type aggregation="none" containment="Unspecified"/>
<constraints/>
<modifiers isOrdered="false" changeable="none" isNavigable="false"/>
<style value="Union=0;Derived=0;AllowDuplicates=0;Owned=0;Navigable=Navigable;"/>
<documentation/>
<xrefs/>
<tags/>
</target>
<model ea_localid="12149"/>
<properties ea_type="Extension" direction="Source -> Destination"/>
<modifiers isRoot="false" isLeaf="false"/>
<parameterSubstitutions/>
<documentation/>
<appearance linemode="3" linecolor="-1" linewidth="0" seqno="0" headStyle="0" lineStyle="0"/>
<labels/>
<extendedProperties virtualInheritance="0"/>
<style/>
<xrefs/>
<tags/>
</connector>
</connectors>
<primitivetypes>
<packagedElement xmi:type="uml:Package" xmi:id="EAPrimitiveTypesPackage" name="EA_PrimitiveTypes_Package" visibility="public"/>
</primitivetypes>
<diagrams>
<diagram xmi:id="EAID_BB03CB2B_7A35_4c2c_9574_78D00E3DF1BE">
<model package="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617" localID="1219" owner="EAPK_C8A75B7D_1FB3_48a8_9451_F1CB99203617"/>
<properties name="ArchiMateInstances" type="Logical"/>
<project author="ebarnes" version="1.0" created="2019-09-24 11:21:24" modified="2019-09-24 11:22:51"/>
<style1 value="ShowPrivate=1;ShowProtected=1;ShowPublic=1;HideRelationships=0;Locked=0;Border=1;HighlightForeign=1;PackageContents=1;SequenceNotes=0;ScalePrintImage=0;PPgs.cx=0;PPgs.cy=0;DocSize.cx=826;DocSize.cy=1169;ShowDetails=0;Orientation=P;Zoom=100;ShowTags=0;OpParams=1;VisibleAttributeDetail=0;ShowOpRetType=1;ShowIcons=1;CollabNums=0;HideProps=0;ShowReqs=0;ShowCons=0;PaperSize=9;HideParents=0;UseAlias=0;HideAtts=0;HideOps=0;HideStereo=0;HideElemStereo=0;ShowTests=0;ShowMaint=0;ConnectorNotation=UML 2.1;ExplicitNavigability=0;ShowShape=1;AllDockable=0;AdvancedElementProps=1;AdvancedFeatureProps=1;AdvancedConnectorProps=1;m_bElementClassifier=1;SPT=1;ShowNotes=0;SuppressBrackets=0;SuppConnectorLabels=0;PrintPageHeadFoot=0;ShowAsList=0;"/>
<style2 value="ExcludeRTF=0;DocAll=0;HideQuals=0;AttPkg=1;ShowTests=0;ShowMaint=0;SuppressFOC=1;MatrixActive=0;SwimlanesActive=1;KanbanActive=0;MatrixLineWidth=1;MatrixLineClr=0;MatrixLocked=0;TConnectorNotation=UML 2.1;TExplicitNavigability=0;AdvancedElementProps=1;AdvancedFeatureProps=1;AdvancedConnectorProps=1;m_bElementClassifier=1;SPT=1;MDGDgm=;STBLDgm=;ShowNotes=0;VisibleAttributeDetail=0;ShowOpRetType=1;SuppressBrackets=0;SuppConnectorLabels=0;PrintPageHeadFoot=0;ShowAsList=0;SuppressedCompartments=;Theme=:119;SaveTag=22068BE0;"/>
<swimlanes value="locked=false;orientation=0;width=0;inbar=false;names=false;color=-1;bold=false;fcol=0;tcol=-1;ofCol=-1;ufCol=-1;hl=0;ufh=0;hh=0;cls=0;bw=0;hli=0;SwimlaneFont=lfh:-10,lfw:0,lfi:0,lfu:0,lfs:0,lfface:Carlito,lfe:0,lfo:0,lfchar:1,lfop:0,lfcp:0,lfq:0,lfpf=0,lfWidth=0;"/>
<matrixitems value="locked=false;matrixactive=false;swimlanesactive=true;kanbanactive=false;width=1;clrLine=0;"/>
<extendedProperties/>
<elements>
<element geometry="Left=358;Top=202;Right=448;Bottom=272;" subject="EAID_D05A372F_86E4_4216_8FAF_BE2E7C273854" seqno="1" style="DUID=9D55A550;"/>
<element geometry="Left=122;Top=202;Right=229;Bottom=272;" subject="EAID_D427A768_E6EC_467a_ACE8_978765E91F3F" seqno="2" style="DUID=5BAA520C;"/>
<element geometry="Left=130;Top=62;Right=220;Bottom=132;" subject="EAID_878F289B_EF83_4034_919D_750B40797FED" seqno="3" style="DUID=B5D454A2;"/>
<element geometry="SX=0;SY=0;EX=0;EY=0;EDGE=2;$LLB=;LLT=;LMT=;LMB=CX=115:CY=28:OX=-54:OY=2:HDN=0:BLD=0:ITA=0:UND=0:CLR=-1:ALN=1:DIR=0:ROT=0;LRT=;LRB=;IRHS=;ILHS=;Path=;" subject="EAID_39A9C32B_5E11_40e8_AE90_3DEC035964D3" style="Mode=3;EOID=9D55A550;SOID=5BAA520C;Color=-1;LWidth=0;Hidden=0;"/>
<element geometry="SX=0;SY=0;EX=0;EY=0;EDGE=1;$LLB=;LLT=;LMT=;LMB=;LRT=;LRB=;IRHS=;ILHS=;Path=;" subject="EAID_C575B08F_87E3_4597_9829_1526C14AE85A" style="Mode=3;EOID=B5D454A2;SOID=5BAA520C;Color=-1;LWidth=0;Hidden=0;"/>
</elements>
</diagram>
</diagrams>
</xmi:Extension>
</xmi:XMI>
Firstly my reply contained a factual inaccuracy nobody has picked: the said astronomical prediction model was indeed geocentric and not heliocentric. Whether, it was a intentional or accidental mistake, I you decide but I find very interesting that nobody spot it, it seems that it could more important to be “right” than inaccurate.Honestly, I skimmed it and summarized as "old thing was good until it was demonstrated to be bad". Even if I looked at it in detail I wouldn't know without looking it up what geocentric or heliocentric are, let alone what the prediction model you were referring to was.
No worries :), "old thing was good until it was demonstrated to be bad" is a good summary. To which I would add, continuing to do something that was "good" and "demonstrated bad" is a bad habit, a habit which may be better to overcome.Firstly my reply contained a factual inaccuracy nobody has picked: the said astronomical prediction model was indeed geocentric and not heliocentric. Whether, it was a intentional or accidental mistake, I you decide but I find very interesting that nobody spot it, it seems that it could more important to be “right” than inaccurate.Honestly, I skimmed it and summarized as "old thing was good until it was demonstrated to be bad". Even if I looked at it in detail I wouldn't know without looking it up what geocentric or heliocentric are, let alone what the prediction model you were referring to was.
No worries :), "old thing was good until it was demonstrated to be bad" is a good summary. To which I would add, continuing to do something that was "good" and "demonstrated bad" is a bad habit, a habit which may be better to overcome.Firstly my reply contained a factual inaccuracy nobody has picked: the said astronomical prediction model was indeed geocentric and not heliocentric. Whether, it was a intentional or accidental mistake, I you decide but I find very interesting that nobody spot it, it seems that it could more important to be “right” than inaccurate.Honestly, I skimmed it and summarized as "old thing was good until it was demonstrated to be bad". Even if I looked at it in detail I wouldn't know without looking it up what geocentric or heliocentric are, let alone what the prediction model you were referring to was.
[SNIP]Isn't that always the case with metaphors etc?
The deconstructionists would love that. Meaning and language were literally dissociated, and yet everyone was left with the feeling of communication as if it had occurred.
Isn't that always the case with metaphors etc?
The deconstructionists would love that. Meaning and language were literally dissociated, and yet everyone was left with the feeling of communication as if it had occurred.
Paolo
Ah... You're speaking about the specific instance (pun intended) whereas I was talking about the classifier. Agreed! Maybe we could say it was a malpropistic metaphor. ;)The difference is authorial intent. If the intent was to reference geocentrism but the speech act referenced heliocentrism, then it's malapropism, not metaphor.Isn't that always the case with metaphors etc?
The deconstructionists would love that. Meaning and language were literally dissociated, and yet everyone was left with the feeling of communication as if it had occurred.
Paolo
"... but I have to accept that this is bigger than I am."
So.... you have set aside your rhyslewispoalcentric model? Oh I'm sorry, I couldn't resist it!
I've started using "Child (Generalization)" instead of "Instance", and the sky hasn't fallen. I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.While the child inherits stuff from its parent. We often (colloquially) use the concept of parent-child when talking about meronymies. So for me, that's not precise enough. For inheritance I use "inheritor".
I've started using "Child (Generalization)" instead of "Instance", and the sky hasn't fallen. I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.While the child inherits stuff from its parent. We often (colloquially) use the concept of parent-child when talking about meronymies. So for me, that's not precise enough. For inheritance I use "inheritor".
Paolo
[SNIP]and the sky hasn't fallen.The sky rarely falls and the day it does we can all stop worrying ;)
[SNIP]There are 2 fundamental differences between natural languages and artificial languages, such as modelling languages and those used in mathematics and logic, namely:
The deconstructionists would love that. Meaning and language were literally dissociated, and yet everyone was left with the feeling of communication as if it had occurred.
[SNIP]What are you trying to achieve with having easy navigation? Traceability? Navigation? Both? Please note this a genuine question.
I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.
Red, Blue and Green are hyponyms of Colour, with the hyponym specialising the hypernym Colour. A hyponym is a type of the hypernym, in UML the hypernym generalises the hyponym or the hyponym specialises the hypernym.I've started using "Child (Generalization)" instead of "Instance", and the sky hasn't fallen. I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.While the child inherits stuff from its parent. We often (colloquially) use the concept of parent-child when talking about meronymies. So for me, that's not precise enough. For inheritance I use "inheritor".
Paolo
Yes, I am looking for a hyponym, not a meronym.
Now let's jump into the very interesting aspects of this thread.[SNIP]What are you trying to achieve with having easy navigation? Traceability? Navigation? Both? Please note this a genuine question.
I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.
[SNIP]
Yes, I am looking for a hyponym, not a meronym.
Red, Blue and Green are hyponyms of Colour, with the hyponym specialising the hypernym Colour. A hyponym is a type of the hypernym, in UML the hypernym generalises the hyponym or the hyponym specialises the hypernym.Hey Modesto,
A wing is a meronym of a plane, likewise, a port is meronym of a switch or router. This is in UML is depicted by composition (or aggregation).
Typically inheritance is something associated with hyponyms and hypernyms and not with meronym.
The difficulty I always had with Sparx "Child (Generalization)" is what it does with the elements: adds "_child" at the end and ignores the stereotypes (at least in V13). If it did not do that I will be a bit more helpful.
One "trick" I use is to use the indefinite article to determine if I have an inheritance or restriction (IS_WHERE). Thus I can say a spoon is a TYPE_OF cutlery, but it is more difficult to say a green is a TYPE_OF colour.
That's because Green IS a colour WHERE the frequency is x.
So does the "Realized by" arrow point from the logical switch to the technology one, or the other way around?
So does the "Realized by" arrow point from the logical switch to the technology one, or the other way around?
ArchiMate relationships should form a coherent English sentence when read from source to target. They're also generally the opposite direction to UML.
I always thought that too. So the "Realized by" arrow should point from blue (logical) to green (technology). Ie. The switch in the guard room instance of the camera plus switch logical pattern is realised by a IE-4000-4T4P4G-E.
However I have seen a lot of green to blue "Realized by" arrows, including in Gerben Wierda's Mastering Archimate, so I am beginning to doubt my understanding of it.
The more tangible entity (source) realizes (makes real) the more abstract entity (target).
As long as the arrowhead is at the abstract end :)As long as the ArchiMate shapescript arrowhead is at the abstract end. If you lose the stereotype it will be drawn the other way.
I’ll tackle the other post replies when I have a better screen and keyboard. To tackle the issue of duplication we have created a dashboard with a custom SQL statement to list just those elements in the repository with the same name, base class, stereotype and belonging to the same root branch.Now let's jump into the very interesting aspects of this thread.[SNIP]What are you trying to achieve with having easy navigation? Traceability? Navigation? Both? Please note this a genuine question.
I'm going to miss being able to navigate easily between the thing and the parent/classifier, but I have to accept that this is bigger than I am.
Navigation for the author of the model and diagrams, rather than a function of the published artifacts. As the model grows, and as other people add to it, I am often wanting to make sure that it remains coherent. One of the problems I try to avoid is multiple copies of the same element - either because I have forgotten that I created one earlier or because some other person has created it. I try to have as many ways to audit the integrity of the model as possible, including:
- Searching the model for objects of the same name/ip address
- Looking at other objects that should have a relationship to the object in question to see if a relationship leads me to the object with a name I wasn't expecting
- Going to the parent/classifier, then searching for that in all diagrams. For example go from this switch to the platonic switch, and then from there I can find all diagrams that have "a" switch.
The thing that makes EA useful beyond the frustrations of its quirks and transient features is the model, which allows this kind of navigation. If it were not for that I might as well use Visio or crayons.
The use of the indefinite article may be of assistance to establish if something is a type of something else but it is not bullet proof. "Spoon" is a type of cutlery irrespective of the article preceding, likewise "POE Switch" is a type of Switch irrespective of the article preceding it. I'll get into colours shortly.[SNIP]
Yes, I am looking for a hyponym, not a meronym.QuoteRed, Blue and Green are hyponyms of Colour, with the hyponym specialising the hypernym Colour. A hyponym is a type of the hypernym, in UML the hypernym generalises the hyponym or the hyponym specialises the hypernym.Hey Modesto,
A wing is a meronym of a plane, likewise, a port is meronym of a switch or router. This is in UML is depicted by composition (or aggregation).
Typically inheritance is something associated with hyponyms and hypernyms and not with meronym.
The difficulty I always had with Sparx "Child (Generalization)" is what it does with the elements: adds "_child" at the end and ignores the stereotypes (at least in V13). If it did not do that I will be a bit more helpful.
reading your post triggered a thought in my head (dangerous, I know)
Looking at your colour example, I would have said that "Red, Blue and Green are instances of Colour". I thought (and you agreed) hyponyms were a TYPE_OF.
One "trick" I use is to use the indefinite article to determine if I have an inheritance or restriction (IS_WHERE). Thus I can say a spoon is a TYPE_OF cutlery, but it is more difficult to say a green is a TYPE_OF colour.
That's because Green IS a colour WHERE the frequency is x.
In our modelling technology (as I've said before) we have Inheritance, Restriction and unspecified Specialization (not sure yet whether it's an inheritance or restriction).
As I said, just a thought.
Paolo
ServiceNow is some SAP spawn (IIRC). Just google for the name.
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”.
The name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., “travel insurance”).
ArchiMate modelers may represent generic organizational entities that perform behavior as either business actors or business roles.
In ArchiMate, much of the items that we deal with are specific instances, the Business Process "XYZ", the Actor "Fred", the Business Role "Bank Manager". In these cases, is the classifier "Business Process", "Actor" and "Business Role" respectively? If not, then what is the classifier? Do ArchiMate items have classifiers anyway? Searching the ArchiMate 3.0 specification for Classifier yields NO results!
[SNIP]I agree that "BMW X1 with Vin#12345" appears to be a series of hierarchical specialisations, at least in a UML sense of the term. However, I look at it from a slightly different angle as Paolo, insofar as "BMW X1 with Vin#12345" is a physical car, a car/motor vehicle on the road or inside a showroom or in storage.
I agree that down to "BMW X1 with Vin#12345" appear to be specializations. Hence my use in the past of the term specific vs placeholder (rather than specific vs generic, since - to me - generic is not the correct concept to apply)
[SNIP]From a UML point of view, assuming we are using a Class element, a couple of questions arise:
In UML, "A classifier is a category of elements that have some common features, such as attributes or methods". Further, "A classifier describes a set of instances that have common behavioural and structural features (operations and attributes, respectively)". And... "A classifier is a type and can own generalizations, thereby making it possible to define generalization relationships to other classifiers." NOTE: How the definitions do NOT say that the Classifier is, itself, an Element. They DO say that it is a categorisation mechanism.
[SNIP]Modern Linnaean classifications use the concept of taxonomic ranks of which there are many types - e.g., Domain, Kingdom, Phylum, Class, Order, Family, Genus and Species. Are these types classifiers or elements? Before answering please consider that taxonomic ranks are organised into a ragged parent/child hierarchy where levels can be skipped.
As an aside, we use the term Classification in the Linnaean sense "Screw, Whitworth, 3/4 inch"
[SNIP]I agree with Eve’s comments and interpretation. Furthermore, if I take Paolo’s example below, I am likely to end up with something like the table after the quote.
ArchiMate uses the words generic and specific for effectively the same concept.QuoteBusiness actors may be specific individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic; e.g., “Customer” or “Supplier”.QuoteThe name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun (e.g., “travel insurance”).
From my reading of the spec, if you want to use both and explicitly specify the relationship between specific and generic you would have to use the Specialization relationship. (Well you could use Association. That's the equivalent of Dependency in UML. It can mean anything)
[SNIP]
So, let's investigate an ontology with specializations. Vehicle::Motor Vehicle::Motor Car::BMW::BMW X1:BMW X1 with VIN# 12345
In normal usage, we might say that the "BMW X1 with VIN# 12345" specific instance of a BMW X1 (since we can specifically identify the item). We can also say: THE BMW X1 with VIN# 12345 IS a BMW X1 which IS a BMW, which IS a Motor Car which IS a Motor Vehicle which IS a Vehicle. Notice I'm not (directly) saying BMW IS A TYPE OF Motor Vehicle.
| Element name | Relationship (with comments) Comment | Possible UML Type | Possible ArchiMate Element |
| Vehicle | Root (cannot be further generalised) | Class | Business Object, Representation or Data Object |
| Motor Vehicle | An specialisation of Vehicle | Class | Business Object, Representation or Data Object |
| Motor Car | An specialisation of Motor Vehicle | Class | Business Object, Representation or Data Object |
| BMW X1 | A instance of a Motor Car Model | Object (instantiating a Motor Car Model) a missing element in this puzzle | Not sure, possibly an instance of “Motor Car Model” Business Object (or Representation or Data Object) |
| BMW X1 with VIN# 12345 | Not sure because we have transition the physical realm | Possibly a Node or a Device (which is a specialised type of node) | Equipment |
[SNIP]I don’t think an instance of a Business Process “Assess a Mortgage Application” is a business process. The same way I don’t think an instance of an the actor carrying the process out is an actor. Furthermore, I think it is semantically incorrect to state that the instantiated and the result of the instantiation have the same metatype.
"Business Process", "Actor" and "Business Role" are the metatypes. Any elements of those types are instances of those types, but from an ArchiMate perspective, they aren't meant to be thought of as instances.
Did you mean that an instance of the metatype Actor is NOT an instance (of Actor)? If so, seems strange!
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
Interestingly, I view ArchiMate Roles as specific instances also. Each one is uniquely identifiable and definable. Similarly with Busines Processes, as with Actors. Note: I make specific distinction between the Role Specification and the Agent - the actor playing the role (at run-time so to speak). So Roles don't DO anything, but constrain what can be done, Actors don't, of themselves, do anything, but only exhibit behaviour when enacting the role (that is, acting as an Agent).I'm not sure how a role can be a specific instance. It is a way of describing what can be one by one or more Actors. In your terminology those actors then become Agents when instantiated, but the Role itself can't be directly instantiated. Which is why I'd say Bank Manager is an Actor not a Role. (Distinguishing between the ArchiMate concept of Role from Role as a synonym for Position) Bank Manager may be assigned roles of Loan Approver, Hirer etc. Having said that, you could of course treat Bank Manager as a Role Aggregating and Composing the Roles that it is made up of.
Did you mean that an instance of the metatype Actor is NOT an instance (of Actor)? If so, seems strange!I mean in an "ArchiMatey" way, don't look behind the curtain at the person manipulating a (meta)model.
I don’t think an instance of a Business Process “Assess a Mortgage Application” is a business process.My comments around that based on interpreting ArchiMate through a UML lense. ie. ArchiMate Process is like a UML Activity. Any UML Behavior is a specialization of a class. It starts running when it is instantiated, and is usually destroyed when completed. I haven't seen many situations where modeling an instance of a UML Behavior was needed and don't think you could do that in ArchiMate. But conceptually the instance of a Business Process would be a "Business Process execution". An instance of "Assess a Mortgage Application" would be something like "Assess Mortgage Application no. 42".
[SNIP]Agree with one exception, your last bullet ("Technology layer: X1 #12345 Implementation") does not belong to the technology layer. It belongs to the physical, to use an ArchiMate term, layer or to the deployment layer, to use a UML term.
So filling that out, with simplifications and omissions for clarity:
Business Layer - Driver Role carries out the Driving Function as part of the Transportation Process
Application Layer - Motor Vehicle Component realizes the Driving Function, and the Pathway Component is used by the Motor Vehicle Component
Technology layer: Off-Road Pattern - Offroad vehicle device realizes Motor Vehicle Component and uses Muddy Road Node that realises the Pathway Component
Technology layer: On-Road Pattern - On-road vehicle device realizes Motor Vehicle Component and uses Asphalt Road Node that realises the Pathway Component
Technology layer: Off-Road Implementation Pattern - BMW X1 device is a specialization of On-road vehicle device and uses Muddy Road with < 200mm puddles Node that is a specialization of the Muddy Road Node
Technology layer: X1 #12345 Implementation - BMW X1 VIN #12345 device is a realization of BMW X1 device and uses Woodhill Forest Road #2 Node that is a realization of the Muddy Road with < 200mm puddles Node
[SNIP]Aren’t we mixing 3 terms with different meanings: implementation, instantiation and generalisation (or specialisation if you prefer)? You can only classify using the latter (or classifiers).
Perhaps the confusion here is the problem of types of implementation.
I'm not sure how a role can be a specific instance. It is a way of describing what can be one by one or more Actors.Could I confuse things by suggesting that an instance of a Role is a runtime permission or set of permissions to do something?
In the IT world, the yellow diagrams are for sales people and the project sponsors. The blue diagrams are the ones that you draw on the whiteboard at the beginning of each argument. The green ones are what the vendor was supposed to build, and they grow in number and detail as you iterate through the delivery mistakes.Lastly, sometimes I have the feeling that architecture is going the yellow way instead of the green way. At times I see a trend, almost a paradigm shift, whereupon things are architected through yellow or blue diagrams with green diagrams almost confined to oblivion.
Nuance 4 - From green to yellowIn the IT world, the yellow diagrams are for sales people and the project sponsors. The blue diagrams are the ones that you draw on the whiteboard at the beginning of each argument. The green ones are what the vendor was supposed to build, and they grow in number and detail as you iterate through the delivery mistakes.Lastly, sometimes I have the feeling that architecture is going the yellow way instead of the green way. At times I see a trend, almost a paradigm shift, whereupon things are architected through yellow or blue diagrams with green diagrams almost confined to oblivion.
Nuance 1 - Technology and physical equipment are not the same thing
I've just learned an embarrassingly large thing via this thread:Well, my understanding was that Physical Elements were those things in the real world other than those already handled by the Technology Layer.
Nuance 1 - Technology and physical equipment are not the same things
Up until now, I have conflated the Archimate Technology and Physical layers into one by assuming that they map to the TOGAF D: Technology Architecture domain. In the words of Job, I will place my hand over my mouth at this point.
Well, my understanding was that Physical Elements were those things in the real world other than those already handled by the Technology Layer.I note the use of the past tense, instead of the present tense. If your understanding was correct, why would there be a need for the physical layer, after all both contain physical items?
(from ArchiMate v3.0)
Technology: Device A physical IT resource upon which system software and artifacts may be stored or deployed for execution.
Physical: Equipment One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
ArchiMate "creaks" quite badly in places.
[SNIP]Except for the part highlighted in red, this is how I always understood instance. However, I am not sure that we are dealing is this thread with persistent (or persistable) instances. However, you are touching an interesting issue underlying this discussion: hopefully we agree that something persisted is a row/record on a data entity/data store, please take both pairs of terms loosely and find the appropriate ArchiMate equivalents.
Instance
An example or single occurrence (specific and identifiable) of something more abstract. We should distinguish between persistent instances (that have a lifetime extending beyond the duration of a single process) and ephemeral instances (run-time only - existing only for the duration of a process).
For the purposes of this discussion, it seems to me that we are dealing only with persistent instances.
You seem to be confusing architecture and engineering. Generally architects are shit engineers and engineers are shit architects. I've spent a lot of time over the last two years producing local network views for customers where they would have previously received a visio diagram which looked like a cross between noodles and fruit salad.I am not sure if I am confusing architecture and engineering but you do have a point. Architecting and engineering are separate things. In my simple mind, the engineers ‘world’ is the deployment layer (UML), and the technology and physical layers (ArchiMate).
Before somebody makes this point, I don’t think architects, engineers and developers are always required for anything we build in IT. But considering the complexity of some if the systems and ecosystems we developed, the frequent absence of building without engineering and engineering without architecting is staggering. The fact that this systems and ecosystems work and interact with each other may be proof that chaos theory applies to information systems and that somehow they are self organising.
Past tense: If you mean "my understanding was that", then that was just a "turn of phrase". My understanding still is that. As I suggested, though, I came to the same question you did; "why do you need both?" But I don't write the ArchiMate Standard. ;) Was your question there, rhetorical? (Just asking) If not, what is your understanding of the difference in the two layers (it's too hard right now on the bus to go back through the posts to see if you expressed a view)?Nuance 1 - Technology and physical equipment are not the same thing
Well, my understanding was that Physical Elements were those things in the real world other than those already handled by the Technology Layer.I note the use of the past tense, instead of the present tense. If your understanding was correct, why would there be a need for the physical layer, after all both contain physical items?
(from ArchiMate v3.0)
Technology: Device A physical IT resource upon which system software and artifacts may be stored or deployed for execution.
Physical: Equipment One or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
ArchiMate "creaks" quite badly in places.
The minute you enter the physical realm, the realm of serial or VIN numbers (even asset identifiers), you are in the physical layer. But there is a complication, please see paragraph below regarding architecture vs engineering.
By the way, I have never seen the UML concept to Node as a direct representation of something physical, please note the emphasis.
[SNIP]Well unsurprisingly, the standard does not help, it indeed creaks badly, having re-read the relevant sections, this is what I found:
But I don't write the ArchiMate Standard. ;) Was your question there, rhetorical? (Just asking) If not, what is your understanding of the difference in the two layers (it's too hard right now on the bus to go back through the posts to see if you expressed a view)?
The Technology Layer is typically used to model the technology architecture of the enterprise, defined by the TOGAF framework [4] as: “the structure and interaction of the platform services, and logical and physical technology components”.
A node represents a computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources.
A device is a physical IT resource upon which system software and artifacts may be stored or deployed for execution.
Equipment represents one or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
I can only hazard to guess that a future version of the standard will elaborate the technology layer and physical elements in such a way that physical things will be represented just with physical elements.
Floppy disks!? 'Twert Lookshoory!I can only hazard to guess that a future version of the standard will elaborate the technology layer and physical elements in such a way that physical things will be represented just with physical elements.
I wouldn't hold my breath. My take on the people who work on ArchiMate is they still think floppy discs are a thing.
LOOKsherie! Kedz theeze dehzz...Them thar's RP06's (that was the month after). My colleague took mine out the drive and put it on top of the "washing machine" and put his in. He didn't put mine away and as he was booting up the RSTS operating system, it wobbled off the drive and smashed to the floor! "Not happy, Jan!"
MAH fust storadge were a disk pak 30 centemeeters rehdioos an' 20 centemeeters deep, whut we put in drahve laike woshin' masheene. Ahh. Then we got pit pony t' roon in' cer-cle to mek disk spin t' reed it.
RK05...pfft!
What is matter anyhow? Do we exist at all? Did(/will) all philosophers die in vain?
What is matter anyhow? Do we exist at all? Did(/will) all philosophers die in vain?
I think what Paolo is saying is that there is the real you (probably only known to yourself) and then there is the mythic you - the story you tell the rest of the world.
Now you do need to exercise some caution in using this feature. It would not be very helpful, for example, to define your own relationship if something very close is already offered natively by the standard.We wouldn't want that to happen now, would we?
In a rather dramatic development it appears that the Open Group has published a new version of the Archimate standard and has included the new Directed Association relationship https://blog.opengroup.org/2019/11/05/archimate-3-1-specification-the-new-version-of-the-standard/amp/ (https://blog.opengroup.org/2019/11/05/archimate-3-1-specification-the-new-version-of-the-standard/amp/).
Depth, an agreed definition and good humour. What else can you ask for on this forum? ;)(my emphasis) We aim to please! Yesterday, I must have got up on the right side of the bed as I was feeling quite playful...
Hopefully, we have not gone “Full Circle”, as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database, and the physical item on a comms room is not an instance of a Node or Device.
P.S.: Glassboy - As I may have before nothing wrong with floppy disks.
... as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database ...
You are essentially describing an architecting (in blue), engineering (in green) and building approach (the 2nd green diagrams) process. In this case I have no objection if the word engineering is used to describe the work behind producing the 2 green diagrams.... as a Cisco SGE2000P 24-Port Gigabit Switch - PoE with serial number 123456789-0986 is only persisted on something like the ServiceNow database ...
Not necessarily. At a large site it is important to plan these things ahead of time so that when the deployment team goes out they put the right thing in the right place. The first round of planning is "what do we need?", which is the yellow and blue diagrams. Then there is the "what technical solution are we going to roll out to solve that need?", which is the technology layer (1st green diagrams). And finally there is the "what is the field technician going to deploy at site #3?" plan which is the equipment/device layer (2nd green diagrams).
Speaking of full circle, it's the 1st to 2nd layer green diagrams where the instance functionality was useful. I have started using the Child Generalisation option in EA, which may not be canonical Archimate but produces readable diagrams.
Just to get this clear in my head out of curiosity:
- Do you have a Node element for the Cisco SGE2000P 24-Port Gigabit Switch without a serial number in the blue or 1st green diagram?
- Do you then create (or want to create) green diagrams where the Cisco SGE2000P 24-Port Gigabit Switch without the serial number is replaced by an instance of it and add the serial number to it?
- What object type does Sparx EA use (or would you Like Sparx EA to use) for the instance?
I'll bite. What's a "Child Generalization"? In normal modelling usage, that would be an oxymoron. Generalization is a directed relationship from the origin (so-called child) to the destination (so-called parent). Specialization is the antonym of Generalization and therefore directed from the more general to the more specific.
many pedants here would say I'm an absolute pedant
Would you accept Both? ;)many pedants here would say I'm an absolute pedant
"Absolute" in the sense of undiminished, independent of other things, or a pedant for things that are themselves absolutes?
Why do Actors "get a guernsey" as an Element, but Motor Vehicles don't?
As I said to Modesto, "We aim to please". ;)Why do Actors "get a guernsey" as an Element, but Motor Vehicles don't?
I love that you mix pedantry with a colloquialism that even I, as someone who is fluent in 'straln, had to look up :-)
Of course, being a Kiwi, you'd mispronounce 'Strine. :-X But you're forgiven...
[haughty tone]indeed! As one, as mentioned, for whom English is not one's first language, one attended the type of school that taught one how to pronounce Cholmondeley.[/haughty tone] ;)Of course, being a Kiwi, you'd mispronounce 'Strine. :-X But you're forgiven...
There's a class differentiation. A person who says 'Strun probably went to a better school than a person who says 'Stroine
Of course, being a Kiwi, you'd mispronounce 'Strine. :-X But you're forgiven...
I don't know where Modesto or Rhys are located (I suspect the UK), but they and I (as examples) have never met and need to be able to communicate unambiguously using only the written word.
So, let us accept that the things we are modelling can be characterised by their features.
...
Some things are specializations of other things.
I agree with his statement (about ArchiMate) however, it seems to me that the concept of a "name only modelling language" is a non-sequitur!
for the representation of Architecture Descriptions.
P.S. (3): Somehow, this reminds of W.V. Quine concept of radical translation, whereupon a linguist encounters a community whose language is completely unrelated to any language familiar to the linguist and the linguist has to attempt to fully translate the unfamiliar language. We are linguists attempting to translate a technical language to plain English and discussing how different technical languages are to be translated into each other. I think the later is a good exercise. I always have some resistance to the former because technical languages are there to express something non-technical languages cannot express.
I think Glassboy has "hit the nail on the head". It's what prompted my post last week. To say that business-level items don't have properties of features is a non-sense to me. It's a simplistic (NOT simple, TOO simple) view.P.S. (3): Somehow, this reminds of W.V. Quine concept of radical translation, whereupon a linguist encounters a community whose language is completely unrelated to any language familiar to the linguist and the linguist has to attempt to fully translate the unfamiliar language. We are linguists attempting to translate a technical language to plain English and discussing how different technical languages are to be translated into each other. I think the later is a good exercise. I always have some resistance to the former because technical languages are there to express something non-technical languages cannot express.
I couldn't disagree with this point more. One of the goals of ArchiMate was to render technical descriptions in plain language (I'm unsure if this was meant to be English or Dutch). The translation problem isn't because ArchiMate is an unknown or alien language, it's because it's the equivalent of operating with the understanding of vocabulary and grammar of a three-year-old.
Despite Glassboy’s disagreement, I still think that we are doing in this thread is a ‘radical translation’ exercise insofar AFIK the ArchiMate specification does not explain how to translate a featurefull instance into a featureless instance.