My Comments on ArchiMate Next Snapshot 1

Referring to: ArchiMate Next Snapshot 1

Reacting to: Aleksander Wyka’s Comment

Background: I was involved in the development of ArchiMate 3.0 and 3.1, since then I have not been a member of The Open Group and so have not been involved in 3.2 or ArchiMate Next. I was the one that re-wrote the exchange standard for 3.1 among other things (you will find my name in the acknowledgements, G. Edward Roberts, Elparazim)

Plug: I provide training and consulting in Architecture and Languages…. SysML, UML, BPMN, UAF, OCL right now… and can provide courses in TOGAF and ArchiMate if I get enough interest (to pay the fees to do this)… as well as providing Tool courses on these languages with Cameo and Sparx EA… Also have a SysML v2 and KerML course about to be released

So I have read and commented (during The Open Group comment time) on ArchiMate Next. In General, I asked myself:

1. What does it not allow you to do that you could do before?
2. What does it allow you to do that you could not do before?
3. What are still my issues with ArchiMate?

As with anything, when you allow more flexibility, you have a greater capability to screw up… so not denying that… so some of these things will be good to advanced users and cause badness to those just starting out

I put in links to some of Nicolas Figay’s articles below… in general, very good arguments and points… some of which I argue against, but want you to have the argument from the other side… I will not be looking at the wider context but only what is and isn’t allowed for someone to do in ArchiMate as a Language and not Enterprise Architecture as a profession

What does it not allow you to do that you could do before

1. Serving Relationship between an Interface and an InternalActiveStructureElement – this needs to be put back in, how I use it in my semantics: if a Service (with multiple Interfaces Assigned to it) serves an InternalActiveStructureElement then the semantics I apply is that the InternalActiveStructureElement can get to that Service through any of the assigned Interfaces… but, if an Interterface is serving an InternalActiveStructureElement then that InternalActiveStructureElement can only connect to that Service through that Interface… this is not perfect (I can give you pathological cases) but works mostly… and is an important relationship… I would like it back in
   
2. Composition – this could be rectified with multiplicities… I could go either way on this
   
3. Constaints Concept – so you can model these as a Requirement (and possibly stereotype them from a profile) but I don’t see any harm is retaining them, they are different than regular Requirements (I would agree with Nicolas on this)… could be a standard library stereotype on a Requirement… Nicolas Figay’s article
   
4. Representations – There is no way I know of to replicate this unless everything becomes an Artifact (like a paper ticket representing a ticket, the paper ticket, without a representation concept becomes an Artifact, that is the only way I can think that I would do it)… I think this should be added back in.. or allow realization between things of the same type… which I like… so another BusinessObject (more concrete) “PaperTicket” can realize the BusinessObject (more abstract) “Ticket”… this is a general mechanism that I would like to see (see below)… Nicolas Figay’s article
   
5. Contracts – so this could be a stereotyped BusinessObject… perhaps some of these could be added back in by having a Standard Stereotype Library… Nicolas Figay’s article
   
6. Gaps – So this is what we are after as Enterprise Architects… I think this needs to be added back in… we need to be able to define these… Nicolas Figay’s article
   
7. Realization between layer relationships – THIS IS MY BIGGEST ISSUE
   • Missing Realization between InternalBehaviorElements, Events, Services, Interfaces between same kinds among the different layers (this can be solved with my suggestion below item 12)
     
8. Being able to Layer concepts of Behavior, Collaboration – see discussion below… Nicolas Figay’s article
   
9. Interaction – I know this has been talked about for a while… while I appreciate the Orchestration vs Choreography discussion… I think Interaction can be modeled as a process with multiple assignments… I have no problem with this going… again possibly Standard Library Stereotype… Nicolas Figay’s article

What does it allow you to do that you could not do before

1. Multiplicities – first change the name, Cardinality is when you have something specific, e.g. 3, it is an instance concept, Multiplicity is a description of what is possible 1..5, it is a type concept… what is in the standard is mainly Multiplicities (with some mixtures of Carnalities, because we don’t make distinctions between types and instances), so I don’t like the name… I do like Multiplicities, but not sure they work on everything (e.g. specialization)… Nicolas Figay’s article
   
2. No Constraint in Layers – I like several things not being constrained in Layers… however having said that, because Layering is one standard method of defining an architecture… we need to retain that ability… I think an emphasis that for any concept in the common area, one can apply a layering letter to its left upper corner to specify that the particular concept is in that layer
   
   • I like Behaviors not being in Layers – because sometimes the various layers work together, e.g., on a process… later on one might want to define the various breakouts of the layers
   • I like Collaboration not being in Layers – because Collaborations can have concepts from multiple layers together (e.g. Like an accountant needs himself and his software to get something done)
   • I like the Role Concept not being in Layers – I like this, one can assign a Role at any level
   • I like the Path Concept not being in Layers – I like this because Paths can be in any level and even between levels
     
3. The Technology Layer’s metamodel was regularized which I like

What are still my issues with ArchiMate

1. Model Management – It needs a model management structure that is serialized with the model… a simple package concept would do (but requires you to put each concept in at most one package)… it needs to be standardized… would also accept a Tag concept which would allow you to organize the concepts under several tags
   
2. Stereotypes – Stereotypes are great in the standard but they need to be standardized… first stereotype must be on the model concept somewhere (this is not in the standard and e.g. Archi does not show them in diagrams)… and the handling of the stereotype needs to be standardized (like what it can extend, using UML terminology, from the metamodel)… perhaps have a Boolean that allows you show/noshow in general on a stereotype (e.g. if all it has is attributes and it is not meant to be shown on the concepts)… there should be a mechanism in tools to show/noshow a stereotype on individual concepts
   
3. Profiles – so there is nothing standardized here… there seems to be many thoughts in the standard… first, in other languages, profiles have stereotypes… so I think that is important… stereotypes can have attributes.. in the standard there is a vague reference to attributes but not specifically how it is done… this needs to be standardized… and be serializable with the model… needs to be standardized and not every vendor for themselves
   
4. Real Derived Relationship – Needs a real notion of derived relationship… here is the issue (and I put it in the exchange format so it was ready for this concept)… I love the notion of derived relationships in ArchiMate… I think it is one of its hallmarks… but there is a part of it that I advocated for but could never get any traction on… I think because it meant vendors would have to change their tools… but there is a missing part of ArchiMate (and other modeling languages in general)… suppose you had a complicated diagram in ArchiMate and then wanted to create a simplified diagram for a less technical stakeholder… great, we have derived relationships for that and as Enterprise Architects that is a common problem for us (more and less technical stakeholders and how to produce models at their respective levels)… here is the problem when you create a derived relationship in this situation, it is a new relationship… but it is not really, it is a simplified relationship built from other relationships that you already have in the model… currently in ArchiMate you get a new relationship… what should you get… a derived relationship that tells you the other relationships (in order) that it is derived from… I would suggest that the derived relationship has a ‘/’ in front of it (like UML)… this has always been a problem in the ArchiMate language and leads to problems
   
5. Viewpoint Creation – there is no standardized way to define your own Viewpoint in the language… this requires some getting into the M2 layer of the language… but this would be nice to have… not as important as some of the other issues
   
6. MOF Metamodel – Most other modeling languages use MOF as their M3… once Model Management is put into ArchiMate Next this might be needful to define “ownership”… but we need a real M3 in this standard… so redo the metamodels in MOF
   
7. Comment – add a comment element into ArchiMate Next… this just seems to be basic… I know tools all do it,,, but it needs to be standardized
   
8. (OCL) Constraints – ArchiMate Next needs the ability to define constraints in the model (i.e. I am not talking about the Constraint concept in Motivation)… if we had a MOF model then one could add the ability to use OCL… I am not suggesting that Tools need to treat it specially (it could just be text to it)… tools that want market share could provide ability to use those constraints in validation, simulations etc.
   
9. Enforce Things in Tools – The tool certification program is basically you fill out a spreadsheet in which you can say “no we don’t do that” and still get certified… so one can not have in a tool the mechanism for M, S, B, A etc in the upper left corner to specify Layer/Aspect and still get certified… I think this is wrong there are some basic things that tool must do and they should not get certified unless they do them… put stereotypes in this
   
10. Generalizing the layer – I thought when I first started reading that they put a generic layering concept in… which I have always wanted… but they didn’t… I would suggest they do… Make InternalActiveStructureElement, ExternalActiveStructureElement, and PassiveElement non-abstract so you can stereotype them for your own layer… also allow you to pick a String to put in the upper left hand corner to name your layer
    
11. Behavior triggers and flows (and serves) … I would like to just have at the BehaviorElement, that any BehaviorElement can trigger and flow (and serves) to any other BehaviorElement… it would greatly simplify the metamodel and we have this mostly anyway through derived relationships
    
12. Realization – Add in that every kind of thing in addition to aggregation and specialization, can also realize… so you can specify different layers of things… e.g. more concrete DataObjects can realize more abstract DataObjects… realization was stripped out in this version
    
13. KerML and SysMLv2 – Start the process of deploying ArchiMate on top of KerML… I believe this is the future path to modeling… tools are not quite at the point of being able to mix KerML-based Language together (hopefully soon in the future)… so probably need to build on top of SysMLv2 as well… the Competition here is UAF which is already being deploy in this environment… the reality is that all my Enterprise Architecture work now has to seamlessly meld with SysML models… and this is a big demographic of users who are not captured by ArchiMate
    
14. Full and Partial Realization – so I think that every modeling language needs the separate concepts of Full Realization of something and Partial Realization of something… in ArchiMate we have the Realize relationship which takes care of the Full Realization concept… but for the Partial Realization, we seem to have two relationships, influence and serves… neither of which really gets to the Partial Realization issue… influence is partial realization (but only in the Motivation Aspect) and then the name does not really help… one could influence something without Partial Realizing it… so I think it falls short… everywhere else serves has to stand in for Partial Realization… and the semantics comes through but again something in the back of my mind is bothered… now some will say, you can use Junctions to show multiple things coming together to do a Full Realization (therefore each of those things do then Partially Realize) but that falls short of me being able to not show Full Realization with a Junction and only describe Partial Realization… this is still a problem and I think we probably need to rename influence to PartialRealization… and then to expand PartialRealization everywhere Realization is (see item 12 above)