ArchiMate 3.0: The Good, The Bad, and The Ugly

On June 14, the 3.0 version of the ArchiMate standard was unveiled during the Enterprise Architecture Conference Europe 2016. Time for a review.

I’ve divided it up in The Good, The Bad, and The Ugly, with The Good standing for changes I like (even if I might also have critical remarks later on), The Bad standing for fundamental issues I have with the language or the direction it is going, and The Ugly for a list of small issues, inconsistencies, etc.

It’s taken me a while, but, hey, it’s over 6000 words and there is a reward at the end (don’t peek!). Warning: this article is meant for enterprise architecture modelling / ArchiMate geeks, and the insatiably curious.

Enjoy.

The Good

ArchiMate is still very useful to model Business-IT landscapes in a holistic way. Much of this post will be about things I don’t like, or issues I have found, but let me state this beforehand: the usability of ArchiMate is still fine, though that does not mean you need to use every bit of it.

One should read this review by and large as ‘no news is good news’: if I don’t pay attention to something, I don’t have any problems with it. And this is true for most of the language. Even the stuff I don’t like, generally doesn’t get in the way. And if something has been implemented in a different way than what I would have done, choices are often well made and thus often it is a matter of taste, nothing else.

Having said that, here are some explicit ‘good’ points I’d like to mention (leaving the sub-criticisms out for now):

• Not of too much relevance to the average user of the language, but the fact that a meta-metamodel has been put in place makes the language much more robust.
• The separation of structural and dependency relations, though adding another distinction creates additional complexity in the language, is a good thing. It also opens up a better way to define derivations in the future (Marc Lankhorst suggested during his presentation that a change of the derivation mechanism would probably be part of the ArchiMate 3.1 discussions).
• Also good is the extension of the use of junctions for more than just the dynamic relations as I’ve been suggesting since 2012. This opens up the possibility to be a lot more clear about the structure and dependencies of your modelled landscape.
• Nesting has been extended as a visualisation mechanism to be allowed for all structural relations. I have been suggesting this also since 2012 (Edition I of the book), but the designers decided to exclude the new subset of ‘dependency’ relations. I think this is a wise restriction and in improvement on my original proposal.
• ArchiMate now allows the ‘informal collaboration’ I’ve proposed in the book and on this blog. It is called (4.2 p15) ‘implicit collaboration’. This is a good change because almost all real processes in enterprises are collaborations as they are performed by multiple roles working together. Collaboration and Interaction are now reserved for the case that you really want to stress the concurrence of both roles and their behaviour. With the Junctions on Assignment you can even be precise. Very nice (but I still have some issues with it, see below).
• And, also as I have been proposing since Edition I of my book, Grouping is now a real element (4.6 p19).
• The idea behind more cross-layer relations in Chapter 12 is good. It should not be the case that one always have to go via an application layer to go from technology to the business layer.
• And of course, the addition of Capability, modelling the physical side of enterprises are good things.

Good things.

The Bad

Specification Sickness, Definition Disease, Formulation Fever

Let’s start with the simple observation that ArchiMate has now grown from the original 32 elements in ArchiMate 1 to 56 different element types in ArchiMate 3. The majority of this growth was between ArchiMate 1 and ArchiMate 2 when the Motivation (for modelling the intentions of an enterprise) and Implementation & Migration (for modelling the projects and programs of the enterprise) extensions were added. But this time too, we get new things. Long-wished-for additions such as Capability (as part of a set of Strategy elements) and the ability to model the more physical side of enterprises as well.

• ArchMate 1: 32 elements
• ArchiMate 2: 49 elements (Motivation & Implementation extensions inspired by TOGAF added)
• ArchiMate 3: 56 elements (Physical, Grouping, Capability, etc.)

Is this bad? Well, in part yes and in part no. Often, the additions are useful. But on the other hand all the different areas in ArchiMate are still not well integrated and that leads to too many element types and incoherent/fragmented modelling.

There is a common theme behind all of this. Even with 56 elements, ArchiMate is still a small subset of concepts when compared to what we have as concepts about world as we experience it. So, every concept in ArchiMate is not a perfect representation of what goes on in reality of the enterprise. The designers have an unfortunate tendency to react to that fact with ever more ‘improved’, more ‘precise’ definitions, specifications and so forth, which all leads to more complexity in the language. It’s still not an as detailed and unwieldy set of definitions as in TOGAF, but it seems we are slowly drifting towards such a situation with ArchiMate.

In part, these approaches are founded upon utopian/idealistic  philosophical views about signs and meaning, especially logical positivism (1920’s-1950’s), which builds upon the assumption that in the end we can (logically) define things precisely in a meaningful way (and verify these definitions). Some even dreamed about removing all misunderstanding (and thus war) from the world. Behind ArchiMate too lies the goal of removing misunderstanding by improving the structure of the language we use in talking about our enterprises. Most strongly we see this in the attempt to define a structure for modelling stuff related to our intentions (Motivation Extension). Yes, I can make a model about these, but one can wonder if this can lead to actual use and thus meaning. Will the model actually be used to decide things? Can it be complete and rich enough to be a reliable tool? Or is it just a nice but too simplistic illustration of a more complex reality? Note, such nice illustrations can be useful (and thus meaningful) of course.

But, the language is confronted all the time with the imperfections of the real world, imperfections which create the friction that makes movement possible, Uncle Ludwig would say. Perfect logic is like a perfect, frictionless sheet of ice, in the end it gets you nowhere. And the reaction of becoming ever more precise, to make ever more distinctions, is as valiant as it is doomed. This is an unsolvable problem and each constructed language will have to find its own sweet spot between leaving it to the speakers (use) and leaving it to the grammar (design).

Anyway, I’m convinced the number of element types could be brought down without decreasing the clarity or the power of expression of the language. Many elements are very close to each other. E.g. Principle, Requirement, and Constraint (all Requirements), or Goal, Outcome, and Value. Even Actor and Role have overlap, illustrated for instance when the standard says: “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”.”. (Hmm, and weren’t we told earlier that we should model implementation-independent abstractions? Oh well, better late than never…). And don’t forget that the Collaborations in the Application and Technology layer are unhelpful anthropomorphisms anyway, which require quite far fetched technical scenarios (quorum decisions between fully independent software agents) to be true representations of reality. So that we get at least one picture in this post, here is example 26 on page 73 (redone in Master ArchiMate style):

Now ask yourself: the Website system uses ‘the other two systems’, but how? In reality, the web site, depending on what the user does, either calls the Quotation web service provided by the Quotation system or the Purchase web service provided by the Purchase system. Or both. There is no other system, it is one or the other that is called. So this is reality:

And this makes clear it is the web site that decides which system is used/called. The Quotation system and the Purchases system are completely independent from each other. The Collaboration suggests something that is not really there. This imaginary state of affairs is repeated in 9.3.6 p76 where the behaviour is called ‘cooperative’, but that cooperation just exists in the mind of the modeller. Adding this abstraction in my view doesn’t help understanding a bit (on the contrary, even), its just a bit of a knee-jerk reaction of those that are addicted to abstraction for abstraction’s sake; because of their inherent belief that ‘abstraction’ is the name of the game.

One thing that would improve matters is a better integration between all the extensions and the core language. Take these examples:

• A Stakeholder and a Role are closely related. Why have two different elements for these, especially without any Specialisation relation between them?
• A Work Package is almost indistinguishable from a Process. Why have two completely separate elements?
• An Assessment (or even a Requirement) is not only important from a motivation perspective. It is also something that is created, e.g. by a Business Process. But in ArchiMate, Assessment is not a Business Object.
• Location is a Specialisation of the abstract Composite Element next to its sibling Grouping. Location does not really differ from Grouping and I can express any Location easily as a Grouping. Why have that separate Location element? Is it really necessary? And what exactly is the real difference between Facility and Location? Yes, I know, the Facility contains stuff that makes running Equipment possible, but why could that not be a potential aspect of Location?

Behind the first two of these examples is a common theme: Enterprise Architecture itself is also part of the Enterprise and so is running Programs and Projects. They are not separate. Just as the HR-activites of the HR department are part of the Enterprise’s HR, and the financial activities of the Finance department are part of the Enterprise’s finance. ArchiMate thus takes the stance that EA itself is not ‘of the enterprise’ (4.4 p17). Telling, perhaps, if one thinks about how badly accepted/integrated the whole idea of enterprise architecture is in many organisations.

10.4.2 p88 says: “[…] the two typical ways to use the artifact element are as an execution component or as a data file. In fact, these could be defined as specializations of the artifact element.” This suggestion of specialisation is a good example of ‘specification sickness’. It is also an example of a deeper problem because that single Artifact is a Data Object from the perspective of the developer of the application and an Application Component from the perspective of the users. See Secondary, Tertiary architecture on this blog (the first post ever from the ArchiMate 1 days) and in the book (Section 12).

Anyway, there are 13 different element types in Motivation and Strategy. They also represent the unfortunate spawning of ever more elements in a valiant but doomed attempt at precision-through-logic. Simplification would be a great idea, but is the standardisation process capable of this?

TOGA(F)! TOGA(F)! TOGA(F)!

With respect to the influence from TOGAF, there is a subtle change visible:

• References to TOGAF definitions in ArchiMate 1 definitions: 0
• References to TOGAF definitions in ArchiMate 2 definitions: 1
• References to TOGAF definitions in ArchiMate 3 definitions: 10

Here is another example of TOGAF-induced ‘specification sickness’. Take the definition of Application Component:

• ArchiMate 1: An application component is defined as a modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces.
• ArchiMate 2.1: An application component is defined as a modular, deployable, and replaceable part of a software system that encapsulates its behavior and data and exposes these through a set of interfaces.
• ArchiMate 3.0: An application component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces.

I don’t know about you, but with phrases like “aligned to implementation structure”  I’m definitely getting the feeling we’re in Sokal-country (actually, we’re in TOGAF-country, it seems, where we read (TOGAF 34.2.1) “Application Component: An encapsulation of application functionality that is aligned to implementation structuring.”). I’m experiencing difficulty actually understanding what is being said here in this almost Heideggerian lingo (note: I think it is too simple to cast Heidegger’s lingo aside as simple nonsense). Even the ‘encapsulation’ itself is a bit unclear, because (taking the ArchiMate 2 version), what is the difference between ‘encapsulating behaviour’ and ‘being assigned to behaviour’? And what data are we talking about, since in ArchiMate we also model it separate from the application component? Did the definition actually get clearer over time, and, more importantly, for who? Which ArchiMate user actually understands the finer nuances of this and do these nuances end up having actual consequences for use (and thus meaning)? Answering myself: nobody and no. The meaning of an element like Application Component lies (Uncle Ludwig) ‘hidden in correct use’. We can use it just fine in many ways without bothering too much with the finer points of the definition, and our use defines it far more than a textual definition will.

Also, the term ‘Technology’ for what used to be ‘Infrastructure’ suggests TOGAF-influence. But there are deep divides that cannot be crossed by just using the same words. E.g. in ArchiMate 2 the physical/logical separation is generally positioned as technology/application layer separation, but in TOGAF both physical and logical are available in both the application and the technology domain. Any attempt at reconciliation using the same terms is akin to ‘bewitchment by language‘ and is thus doomed.

What does this mean? Well, it does make me worry about the independence of ArchiMate and the direction of ArchiMate. Really reconciling TOGAF and ArchiMate, as TOG seems to want, would mean you have to either rewrite TOGAF in ArchiMate terms (which is not going to happen, I think) or you have to transmogrify ArchiMate into the TOGAF structure (which cannot be done without destroying (the beauty of) ArchiMate). TOGAF is still strong, but go to a random Enterprise Architecture conference these days and you’ll hear nothing but bad things about all those old frameworks and their broken assumptions. Is ArchiMate getting tied to a sinking ship?

Abstraction, abstraction

The ArchiMate 3 designers have a very specific (but mixed) ideas about what abstractions are. For instance (3.6 p9), the difference between external and internal behaviour. For the ArchiMate designers, a Service and an Interface are separate abstractions of what is going on ‘inside’. They present a clear separation between external and internal. E.g., when Business Service is described (8.3 p59), we read: “A business service represents a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized internally.” (italics and underline mine). In the reality of an enterprise, this is not an independent separation at all, it is more a partitioning. The behaviour that makes up the service as offered to the user/customer is also part of the process that realises the service. It means that in ArchiMate Service becomes an abstraction that is more like a combination of Requirement, Value and Interaction than a concrete and recognisable service offering.

The difference between conceptual, logical and physical is also part of the meme. The ArchiMate Layers are linked to these distinctions (3.6 p6). This would make the Business Layer purely conceptual, the application layer purely logical (implementation-independent) and the technology layer physical. A bit lower on that same page the story becomes different: the application and technology functions suddenly are “implementation-independent encapsulations”. This is a deep contradiction. To make matters even more complex (3.6 p6-7), in every layer, we may have types or instances (it is a choice of the modeller). Also, the confusion between Specialisation in the metamodel and Specialisation in a model has not been fixed. Note in this respect example 22 on page 59. Suppose all three roles are needed in the Collaboration, the model doesn’t make that impossible, but it is unclear that this can be the case. The use of Specialisation in real models is fraught with risk, anyway, which is why I generally stay away from it.

And besides, the idea of the functions being ‘encapsulations’ makes them sound more like TOGAF’s GOFBF, functions as being active elements (performing behaviour that they encapsulate) instead of being purely the behaviour of the active elements as ArchiMate has been from its start. This fuzziness is all over the standard. E.g. (3.6 p9) “physical artefacts and software that realize an application component” uses the term software for the passive element (the term ‘software distribution’ would have been better).

Pride and Prejudice

The idea of architecture being by definition ‘high-level’ also permeates ArchiMate. When application behaviour is described (9.3 p73), we read “Note that the internal behavior of a component should in most cases not be modeled in too much detail in an architectural description, because for the description of this behavior we may soon be confronted with detailed design issues.” Why this statement? The fact that it includes “in most cases” already makes it superfluous (I’m reminded about the toxicity of ‘comply or explain’), but it unnecessarily mixes architecture style and what the language can and cannot do. Sometimes details are relevant, and the language can be used both high level and in detail, why then make this statement? Or take for instance the definition of Goal: “A goal represents a high-level statement of intent, direction, or desired end state for an organization and its stakeholders.”. Again, what does the focus on high-level add? What does it add to the language (other than a prejudice for the way we should do architecture, something which has nothing to do with the language at all)? It is all like a grammar book telling you what kind of stories you should write. As explained in Chess and the Art of Enterprise Architecture, architecture is not by definition high-level and sometimes relevant details are of the utmost importance. Ignore them at your peril. As far as I’m concerned, a good Enterprise Architecture language should be level-of-detail independent. ArchiMate here and there agrees: “The application component element is used to model entire applications […] and individual parts of such applications, at all relevant levels of detail.” (9.2.1 p71, italics mine). Exactly.

Then (9.3.1 p74) we read “An application function abstracts from the way it is implemented. Only the necessary behavior is specified.” The second sentence is problematic. The application function element in the model doesn’t ‘specify’ anything. It only names it. Architects love abstractions, but that love may blind them sometimes.

And (9.4.1 p77) “A data object should be a self-contained piece of information with a clear meaning to the business, not just to the application level.” Hmm, we are being told here we should not model in the application layer anything that is only important for the application layer, but it must be important for the business. But what if this ‘technical’ detail is important for the question if this whole enterprise architecture will function or not? Who says that in application layer architecture only business concepts are important?

It’s Pride and Prejudice, this. And blind love.

Parallel relationships

An improvement with respect to previous versions was (as mentioned above) that it is no longer assumed that there should be a one-to-one relation between behavioural elements and the active elements that perform them. That assumption was quite idealistic/utopian (naive, silly, if I’m unkind) and it does not fit really well with the real world of complex enterprises. But the designers did take an unfortunate side in the discussion about what it means that multiple active elements are Assigned to the same behaviour or multiple internal behaviour elements realise the same service.

• Assignment: when two active elements are assigned to the same behaviour it is said that “The usual interpretation of an assignment relationship is that whole or part of the source element is assigned the whole of the target element.”. This means that (the whole of) each of the active elements can perform the whole of the target behaviour element. This is not only in contradiction to what was said earlier (4.2 p15: “the collective nature of a behavior can be made either implicit (several active structure elements assigned to the same internal behavior) or explicit through the use of a collective internal behavior (interaction) that is performed by (a collaboration of) multiple active structure elements”), is is also a less practical/real-world choice when modelling actual enterprises. (Note, there is an escape: if ‘collaborative’ means that all performers of collective behaviour all individually do exactly the same, there is no contradiction. I don’t think that is what collaborative is, though.).
• Realisation: Here too the standard says (it’s worthwhile to quote this in full here): “The usual interpretation of a realization relationship is that the whole or part of the source element realizes the whole of the target element. This means that if, for example, two internal behavior elements have a realization relationship to the same service, either of them can realize the complete service. If both internal behavior elements are needed to realize, the grouping element or a junction (see Section 5.4.3) can be used. For weaker types of contribution to the realization of an element, the influence relationship (Section 5.2.3) should be used.”. Now, Grouping Aggregates its children, and Grouping the two internal behavioural elements doesn’t give you the meaning of ‘both are needed”, both from the derivation perspective and from the working of Aggregation.
• Serving (formerly Used-By): Here the standard says: “The usual interpretation of a serving relationship is that the whole of the source element serves (is used by) the target element. This means that if, for example, two services serve the same internal behavior element, both of these services are needed. If two services are alternative solutions and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.” Two problems here: ’Serving’ is changed to ‘need’. But I can have ‘serving’ relations that deliver optional stuff, ‘to need’ is not required. And: while this solution might be linguistically identical to the previous ones, suddenly the meaning is not ‘either suffices’, it is ‘both are needed’. The pattern is not the same.
• Access: “The usual interpretation of an access relationship is that the whole of the target element is accessed by the source element. This means that if, for example, the same internal behavior element accesses two passive structure elements, both of these passive structure elements are needed. If two passive structure elements are, for example, alternative information sources and only one of them is needed by the internal behavior element, an or junction (see Section 5.4.3) can be used.” Here, the funny thing is that the ‘both are needed’ run in the opposite direction of the relation. What if we would have two behaviour elements accessing a single passive element? And what if one passive element is optional? How do I model that? I can’t.

Personally, I think it would be simpler and better to have the following:

We have:

• BOTH (both, logical AND)
• ONE (either, logical XOR)
• ONE OR BOTH (any, logical OR).

If not explicitly defined with a Junction, the meaning of parallelism is OR (the least explicitly defined). For AND and XOR we can use explicit AND and XOR Junctions.

Other Relationship Issues

We read (5.2.2 p28) about Access: “The relationship can also be used to indicate that the object is just associated with the behavior”. So, we use Access to mean Association? Maybe we should turn this around and when we want to show the payload of a Flow (5.4.2 p33) we should use Access? Actually, Flow and Access hide a very difficult set of relations that probably merit a deeper analysis (using the concepts or behaviour, source, target and payload) which I’m not giving here. But think of this: who is making the Flow happen? Isn’t a Flow actually a hidden process or function? In fact, isn’t this true for Triggers as well?

The Influence relation is a dependency relation (in the new structural vs. dependency distinction for relations). But we also read that Realisation and Influence are similar and Realisation is a more certain and positive version of Influence: “The realization relationship should be used to represent relationships that are critical to the existence or realization of the target, while the influence relationship should be used to represent relationships that are not critical to the target object’s existence or realization. For example, a business actor representing a construction crew might realize the goal of constructing a building, and a requirement to add additional skilled construction workers to an already adequate crew might influence the goal of constructing the building, but also realize an additional goal of opening the building by a particular date.” I think this mix of ‘abstraction’, ‘influence’ and ‘necessity’ make Realisation quite difficult to understand. I suspect a better solution in possible, but I must admit that I haven’t got one worked out. It also shows the effects of ‘specification sickness’, the valiant but doomed effect to be precise in a reality that is not: Not everywhere where a Realisation is possible can one use Influence. So what about those non-critical Realisations that really exist?

By the way: Should we not have the possibility for an Influence relation to influence another relation, while we’re at it? Maybe. Or maybe not.

It is said (5.3.2 p31): “A flow relationship does not imply a causal relationship.” but I think that is wrong. It does not imply a Trigger, but it can cause things, specifically a change in behaviour. A different list of allowed counterparties does not start a trade, but it will causally influence any new trade. And there is a timing effect in Flow, because the target cannot use the payload before the source has sent it.

The OR-Junction is defined as (5.4.3 p33) “A junction is used to explicitly express that several elements together participate in the relationship (and junction) or that one of the elements participates in the relationship (or junction).” I think we should call that the XOR or ‘exclusive’ junction, which would also nicely align the ArchiMate Junctions with BPMN Gateways. As stated above: logical OR for one or both, logical AND for both, and logical XOR for one. The standard says: “Junctions used on triggering relationships are similar to gateways in BPMN and forks and joins in UML activity diagrams. They can be used to model high-level process flow. A label may be added to outgoing triggering relationships of a junction to indicate a choice, condition, or guard that applies to that relationship. Such a label is only an informal indication (link mine). No formal, operational semantics has been defined for these relationships, because implementation-level languages such as BPMN and UML differ in their execution semantics and the ArchiMate language does not want to unduly constrain mappings to such languages.”. This is a bit of name-calling. “Implementation-level” relegates BPMN to the less abstract, more detailed models, but like in ArchiMate, BPMN (and UML) are detail-level independent and stating this about the other languages isn’t really helpful. E.g. from a BPMN perspective, we could have high-level process descriptions with ArchiMate for the finer details of IT, see the Section on linking ArchiMate and BPMN in the book.

The changed cross-layer relations in Chapter 12 are interesting and address the problem that ArchiMate originally is very application-focused. We could argue that originally the business and infrastructure layers were more or less ‘contexts for the application layer’. The way layers are now interrelated tries to improve this. However, it seems two rather different approaches are being mixed.

• Serving is the relation that doesn’t imply abstraction. It is clear in that one ‘real’ thing is being used by another ‘real’ thing. This can now go both ways, so an application can be used by a human, but also the other way around.
• Realisation is the relation that implies abstraction, that is, one element realising the other means that they both depict the same ‘real’ thing, but in a different layer.

As a result, the whole (cross-)layer setup is still rather confused. ArchiMate is a complicated mix of layers using each other and layers being different representation of each other.

Derivation was one of the promises that got me interested in ArchiMate years ago, but the whole issue has taught me that I should have recognised the fallacy of ‘reliably getting meaning from syntactical procedures’ in the first place. I’ve written about problems with derivation elsewhere on several occasions (e.g. here). It could still be useful, I guess, but with changed rules. With the addition of all kinds of relationship that weren’t there before (e.g. the relations described in 12.1 and 12.2) derivation produces even more results that will be hard for users to recognise. What I mean is this; all these derivations are ‘allowed’ but that doesn’t mean everyone easily understands what they can mean and understanding a model becomes more difficult.

Technology and The Physical

ArchiMate finally has support for modelling the physical side of entreprises. TOG has decided to add the physical to the — slightly generalised — original ‘IT infrastructure’ setup. This is new, and I don’t have any experience with it yet. But it does seem to me that it could be cleaner and clearer. For instance (10.1 fig 77, p79) shows that any Node can be Assigned to any technology layer behaviour. This Assignment is not replicated when the physical is shown (11.1 fig 91 p91), but as it is there in the metamodel, any Node can access Material by performing (physical) behaviour, including, say, a Linux server. As a result, most of the definition of Equipment is true of Node in general.

Node, by the way, remains an odd character. Maybe it should have been relegated to the abstract elements in the meta-metamodel. With better derivation rules Grouping could play that role. And so could each child type of Node, e.g. Equipment could compose Device and System Software just as well as a Node could. Or Device could compose System Software. Do we really still need Node as a real element in our models?

In 11.2.2 p92 we read: “A facility represents a physical structure or environment.” (definition) and “A facility is a specialization of a node. It represents a physical resource that has the capability of facilitating (e.g., housing or locating) the use of equipment.” (explanation). I would say that the explanation would make a far better definition that makes clear what Facility is for. However, even if that would be true, there are issues. For one, given that Facility and Equipment inherit from Node, they can do everything a Node can.

With respect to what Node can, it can Realise any (other type of) Nodes. There is no explanation what that means. I can of course let a Node Realise System Software, for instance, but that is a derivation of e.g. “Node Composes System Software Assigned to Artifact Realises System Software”. But a Node Realising a Node? How? What am I missing?

[Update 30/Jun/2016: I know what is was: TOGA(F)! Marc Lankhorst today explained (during the Netherlands Architecture Forum Insight on ArchiMate 3) that people wanted to be able to model TOGAF’s physical/logical split within a layer. So, they added Application Component Realises Application Component so one could model a logical Application being Realised by a physical one. And they did the same in the technology layer. This is indeed explained nowhere explicitly in the text, it has only been added as an allowed relation in the relationships table. Actually, in 3.6 p9 it is said that ArchiMate has 3 ways of modelling such abstractions: (1) using functions for logical and active structure for physical, (2) using realisation, and (3) using specialisation. So, (2) is apparently what I missed, but then again, that suggestion there is followed by the example of physical elements from the technology layer Realising logical elements in the application layer, so I may be forgiven. 3 suggesting fundamentally different ways to model the physical/logical separation doesn’t make things simpler.]

And a Facility can be Assigned to a Business Actor. This is also explained nowhere as far as I can see, and I’m at a loss trying to imagine what the designers mean here.

Material is defined as purely tangible. So, we can either transport physical stuff (Material) or data (Artifact), but we cannot transport energy. I would say that we should have matter and energy interchangeable. That also fits current knowledge of the world of physics best (which as a former physicist I like, of course). Additionally: physical in the Technology layer has a different meaning than physical in the ‘tangible’ extension of the technology layer. It might be a good idea to clean that up. By the way, current physics teaches us that we cannot transport information without transporting mass/energy (many things, such as phase could go faster than light, but it cannot transport information faster than light).

11.5 p94: Why is the ‘Vehicle Telematics Appliance’ modelled as (passive) Material? Because it is a passive product in that context, it is being produced and shipped. However, that same appliance is also Equipment, clearly. We could do here with a Realisation from Material to Equipment, just as we have from Artifact to System Software for instance. Or we could do something far more radical…

The Ugly

Small Change: inconsistencies, ambiguities, etc.

• 3.3 p6: “The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.” This definition wrongly suggests that users of business services are always external to the organisation.
• 3.3 p6: “In the next chapter, the structure of the generic metamodel is presented. In Chapter 6, Chapter 9, and Chapter 10, these elements are specialized to obtain elements specific to a particular layer.” Thus, the elements in the layers (e.g. Business Process, Application Function, etc.) are said to be specialisations of the generic metamodel element (4.1, Fig 5, p13). If this is the case, then the relations in Fig 5 are valid between all layers (Business Process triggers Technology Function, Node Composes Business Interface), but this is not what is intended, I think.
• 3.4 p7: “It is impossible to define a strict boundary between the aspects and layers, because elements that link the different aspects and layers play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, (business) functions and (business) roles serve as intermediary elements between “purely behavioral” elements and “purely structural” elements”. While this is true for Role which indeed is somewhat between actor and behaviour as it is quite nicely defined as ‘responsibility for behaviour’, it is not true for function in ArchiMate, which in the rest of the standard is behavioural.
• 3.4 p8: “The Behavior Aspect, which represents the behavior (processes, functions, events, and services) performed by the actors”. It is nowhere explicitly made clear what ‘performing’ means in the context of ArchiMate. In 8.2.2 (p57) we read: “A business actor that is assigned to a business role is responsible that the corresponding behavior is carried out, either by performing it or by delegating and managing its performance.” This suddenly expands the idea of ‘active element performs behaviour’ (4.1.1) to much more. There is a relation with 15.2.19 (specialisation of relations — informative). It makes the models less clear if the meaning is up for grabs. Yes, I’m asking for more specification here :-), I must be ill.
• 5.1.3 p25: “The assignment relationship links active structure elements with units of behavior that are performed by them, business actors with business roles that are fulfilled by them, and nodes with technology objects.” Missing here at the end of the sentence is: “that […]”. I think “that reside on/in them”.
• 6.1 p39: The direct Associations between Stakeholder and Meaning/Value are superfluous as they follow (derived) from the Association between Motivation Element and Stakeholder. (They’re even more superfluous, as Association is allowed between all elements, but here Association is explicit, however it is not explained why).
• 8.2.3 p57: “A business process or function may be interpreted as the internal behavior of a single business role.”. But this ‘single’ business role requirement has been dropped in ArchiMate 3, see 4.2 p15.
• 8.2.4 p58 (and elsewhere where interface is described): “A business interface may be part of a business role or actor through a composition relationship, which is not shown in the standard notation”. The lollipop is the ‘standard’ notation? Somebody should tell the tool providers who do not support this notation at all.
• The story about the ‘client to client process’ that starts in 8.3 on page 59 tells the opposite story compared to example 23 in 8.3.6 (which I like better, anyway). This idea of a process that is a ‘chain of functions’ is not a pattern that one should explicitly promote anyway. See also this blog post from a while back about process versus function.
• 9.3.6 p76: Same problem as with Example 26: what ‘cooperation’? Also: the interaction doesn’t Compose the functions, it Aggregates them.
• 10.2 p80 and 10.2.3 p81: The generic description at the start of the section still has the old idea that ‘System Software’ more or less is a synonym of ‘operating system’: “System software is an infrastructural software component running on a device”. This limits running to ‘on a Device’, but elsewhere this problem has been fixed and System Software itself is now seen as a platform (much better, though the name should then probably best change to Execution Platform). I have suggested that in my book (where this problem made me model virtual machines as Device) and on my blog. However, TOG hasn’t made the logical next step: if System Software is a platform, it should be able to run both other System Software but also Application Components, and this is missing. Besides, when defining Node, suddenly we are being told “For instance, nodes are used to model application platforms, defined by the TOGAF framework [4] as: “a collection of technology components of hardware and software that provide the services used to support applications”.” So, System Software is a platform, but so is Node? Fine, but if the Node is a ‘platform’, how do I signal deploying anything on it? That probably should be Assignment, just like deploying other software, right? It’s not there, though.
• 10.2.2 p81: isn’t it time to drop System z mainframe and PC as the examples for Device? That is so previous century…
• Communication Path and Network have become Path and Communication Network, because Distribution Network has been added to signify material transport and both can Realise a Path. Here you see the somewhat ad hoc choice of fragmentation. Why can Path be both but Network not? The whole Technology & Physical layer becomes a bit of a tangle this way.
• 10.3.2 p84. “Database replication” is a good example for a function (as it runs permanently, no start and end with definite result, it just keeps two databases in sync), not a process. A “database backup” might be a good example of a process here (unless the ‘sort-of-backup’ is done by replication of course…)
• 10.4.3 p88: This whole description only describes the picture. It is completely superfluous, I can completely create one from the other. The text doesn’t explain anything about the picture. For instance, what does that Association signify? Such a  ‘description that explains nothing’ happens more often in the standard. An ‘explanation’ that is a description of the ‘what’ instead of a description of the ‘why’.

Conclusion

In the beginning of this year, I was asked as an ‘external expert’ to join in the ‘Company Review’ phase of ArchiMate 3. There was very little time for me to do my proofreading of the then draft (a couple of days, and I do have a real job and a family that both demand my attention). Much of what I brought into that discussion could not be discussed because it was too fundamental. Real new changes weren’t allowed in that phase, only existing change proposals could be discussed. Much of the above I might have been able to bring into the process, had there been more time. Some of it was brought up by me and some by others and some in cooperation. I just can’t say what and who, as this process is all under non-disclosure. But for the record: the fact that I now have more to say now should not be interpreted as that I was holding back then. I just have had more time and freedom to look into it since. Note: Marc Lankhorst hinted during the introduction of ArchiMate 3.0 at EAC Europe 2016 that for instance the fundamental discussion on derivation might be part of an ArchiMate 3.1 release later on.

Having said that, if I must use a single word for the ArchiMate now, it is: ‘overcrowded’. It still has all the things that I like, but it’s getting more and more filled up with more and more ‘specifics’. Take another final simple example: System Software can be Assigned to System Software to signal deployment of one on the other (e.g. JEE on Linux), but System Software can also Realise System Software (Linux Assigned to JEE distribution Artifact which Realises JEE System Software). It is this kind of diversity that doesn’t help to keep the language’s use as simple as possible. (In this case, changing derivation rules may lead to both ways ending up the same, though). All  the different kinds of elements that could be simplified into a smaller set doesn’t help either. I think the language could use some janitorial attention, but this also requires a change of heart, where the designers find a different balance between the responsibility of the modeller (the use of the language) and the responsibility of the language (the logic or grammar of the language).

And of course, the language is still not really ‘open’ even with changes to license and web site wording. If anything, matters seem to have gotten worse. But I’ll write that up elsewhere, though just for fun a snippet here: according to TOG you can use ArchiMate non-commercially freely. However TOG says that if you have downloaded the standard “for evaluation purposes”, you must take out a license in any case, either the commercial or the non-commercial one. And if you’re not taking out a license, their web site says you must send them an email confirming that you have removed the documentation from your machine. Open? Actually, this removal clause might hold water, legally, because the downloaded documentation is in another format than the physical book so has a separate copyright. I still need to investigate, though. Luckily, I have the physical book, which means the copyright has already been paid for, the (copy)rights of the copyright holder are exhausted, and I can legally use that book in any way I want.

The Reward

I promised a reward at the start of this blog. Here it is: if you have read everything up to this you’re a certifiable enterprise architecture modelling / ArchiMate geek. Or insatiably curious. I can’t officially certify you, but nonetheless: Congratulations…